先来看看HashMap在Map这个大家族中的位置。
这四种比较常见:HashMap , Hashtable , LinkedHashMap,TreeMap
HashMap存取速度快,它根据键的hashcode值存储数据,线程不安全,只有一个键允许为null,对值没有限制,对数据进行遍历的话读取的随机的。如果想要同步,可以用Collections的synchronizedMap方法使HashMap线程安全或者使用ConcurrentHashMap。
Hashtable和HashMap相似,但是线程安全,存取速度相对于Hashmap较慢,键和值都不能为null。Hashtable不建议在新代码中使用,不需要线程安全的场合可以用HashMap替换,需要线程安全的场合可以用ConcurrentHashMap替换。
LinkedHashMap是HashMap的子类,保存了数据存入的先后顺序,当用Iterator遍历的时候按照存入的先后顺序进行遍历。
TreeMap对键进行排列,当用Iterator遍历的时候默认按照键的升序进行。
HashMap是使用哈希表来存储的。当我们要新增或查找某个元素,就把当前元素的关键字通过哈希函数映射到数组中的某个位置,通过数组下标一次定位就可完成操作。而哈希冲突就是两个不同的元素,通过哈希函数计算后得出的实际存储地址相同。或者说,当我们对某个元素进行哈希运算后得到一个存储地址,然而要进行插入的时候,发现已经被其他元素占用了,其实这就是所谓的哈希冲突。为解决冲突问题,可以采用开放地址法和链地址法等,在Java中HashMap采用了链地址法。链地址法,简单来说,就是数组加链表的结合。在每个数组中都一个链表结构,当数据被哈希函数计算后,就得到数组下标,把数据放在对应下标元素的数组中,如果数组中已经有元素,就转变为链表存在已存在的数据后面。哈希函数十分重要,好的哈希函数要把不同的键计算出来的结果十分分散的分布,分散的越均匀,发生Hash碰撞的概率就越小,map的存取效率就会越高,存储空间的利用率越好。
HashMap的主干是一个Entry数组。Entry是HashMap的基本组成单元,每一个Entry包含一个key-value键值对。数组的长度一定是2的次幂。
//HashMap的主干数组,可以看到就是一个Entry数组,初始值为空数组{},主干数组的长度一定是2的次幂。
transient Entry<K,V>[] table = (Entry<K,V>[]) EMPTY_TABLE;
Entry是HashMap中的一个静态内部类。代码如下:
static class Entry<K,V> implements Map.Entry<K,V> {
final K key;
V value;
Entry<K,V> next;//存储指向下一个Entry的引用,单链表结构
int hash;//对key的hashcode值进行hash运算后得到的值,存储在Entry,避免重复计算
/**
* Creates new entry.
*/
Entry(int h, K k, V v, Entry<K,V> n) {
value = v;
next = n;
key = k;
hash = h;
}
所以,HashMap的总体结构如下:
也就是说,HashMap = 数组(位桶) + 链表 , 数组是HashMap的主体,链表则是主要为了解决哈希冲突而存在的。当添加一个元素(key-value)时,就首先计算元素key的hash值,以此确定插入数组中的位置,但是可能存在同一hash值的元素已经被放在数组同一位置了,这时就添加到这个hash值对应的数组后面,但是形成了链表。同一各链表上的Hash值是相同的,所以说数组存放的是链表。在JDK1.8之后,当链表长度太长时(阈值为8),链表就转换为红黑树,这样大大提高了查找的效率,也就是HashMap = 数组(位桶) + 链表 + 红黑树。
执行构造函数,当我们看到这个new,第一反应应该是这货又在堆内存里开辟了一块空间。
Map<String,String> map = new HashMap<>();
空参构造函数:
public HashMap() {
this.loadFactor = DEFAULT_LOAD_FACTOR;
}
里面初始化了一个负载因子,值为0.75,负载因子乘上当前的容量等于阈值。HashMap有4个构造器,其他构造器如果用户没有传入initialCapacity 和loadFactor这两个参数,会使用默认值,以下是默认值:
////默认的桶数组大小
static final int DEFAULT_INITIAL_CAPACITY = 1 << 4; // aka 16
//极限值(超过这个值就将threshold修改为Integer.MAX_VALUE(此时桶大小已经是2的31次方了),表明不进行扩容了)
static final int MAXIMUM_CAPACITY = 1 << 30;
//负载因子
static final float DEFAULT_LOAD_FACTOR = 0.75f;
// 从JDK1.8,当链表长度超过8就变为红黑树(并且hashmap中数据总数小于64)
static final int TREEIFY_THRESHOLD = 8;
// 在哈希表扩容时,如果发现链表长度小于 6,则会由树重新退化为链表
static final int UNTREEIFY_THRESHOLD = 6;
//在转变成树之前,还会有一次判断,只有键值对数量大于 64 才会发生转换。这是为了避免在哈希表建立初期,多个键值对恰好被放入了同一个链表中而导致不必要的转化
static final int MIN_TREEIFY_CAPACITY = 64;
这些参数对应的变量:
/**实际存储的key-value键值对的个数*/
transient int size;
/**阈值,当table == {}时,该值为初始容量(初始容量默认为16);当table被填充了,也就是为table分配内存空间后,
threshold一般为 capacity*loadFactory。HashMap在进行扩容时需要参考threshold,后面会详细谈到*/
int threshold;
/**负载因子,代表了table的填充度有多少,默认是0.75
加载因子存在的原因,还是因为减缓哈希冲突,如果初始桶为16,等到满16个元素才扩容,某些桶里可能就有不止一个元素了。
所以加载因子默认为0.75,也就是说大小为16的HashMap,到了第13个元素,就会扩容成32。
*/
final float loadFactor;
/**HashMap被改变的次数,由于HashMap非线程安全,在对HashMap进行迭代时,
如果期间其他线程的参与导致HashMap的结构发生变化了(比如put,remove等操作),
需要抛出异常ConcurrentModificationException*/
transient int modCount;
其中一个构造方法:
public HashMap(int initialCapacity, float loadFactor) {
//此处对传入的初始容量进行校验,最大不能超过MAXIMUM_CAPACITY = 1<<30(230)
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal initial capacity: " +
initialCapacity);
if (initialCapacity > MAXIMUM_CAPACITY)
initialCapacity = MAXIMUM_CAPACITY;
if (loadFactor <= 0 || Float.isNaN(loadFactor))
throw new IllegalArgumentException("Illegal load factor: " +
loadFactor);
this.loadFactor = loadFactor;
threshold = initialCapacity;
init();//init方法在HashMap中没有实际实现,不过在其子类如 linkedHashMap中就会有对应实现
}
从上面这段代码我们可以看出,在常规构造器中,没有为数组table分配内存空间(有一个入参为指定Map的构造器例外),而是在执行put操作的时候才真正构建table数组。
jdk1.7中的put方法:
public V put(K key, V value) {
//如果table数组为空数组{},进行数组填充(为table分配实际内存空间),入参为threshold,
//此时threshold为initialCapacity 默认是1<<4(24=16)
if (table == EMPTY_TABLE) {
inflateTable(threshold);
}
//如果key为null,存储位置为table[0]或table[0]的冲突链上
if (key == null)
return putForNullKey(value);
int hash = hash(key);//对key的hashcode进一步计算,确保散列均匀
int i = indexFor(hash, table.length);//获取在table中的实际位置
for (Entry<K,V> e = table[i]; e != null; e = e.next) {
//如果该对应数据已存在,执行覆盖操作。用新value替换旧value,并返回旧value
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
V oldValue = e.value;
e.value = value;
e.recordAccess(this);
return oldValue;
}
}
modCount++;//保证并发访问时,若HashMap内部结构发生变化,快速响应失败
//如果该对应数据为空,就在次数添加元素
addEntry(hash, key, value, i);//新增一个entry
return null;
}
inflateTable()这个方法为主干数组table分配存储空间,通过roundUpToPowerOf2(toSize)可以确保capacity为大于等于toSize的最接近toSize的二次幂,比如如果输入的toSize=13,那么capacity=16就是大于等于13的最接近的2的整数次幂;如果to_size=16,那么capacity就是16;如果to_size=17,那么capacity就是32。
jdk1.8中的put方法
1 public V put(K key, V value) {
2 // 对key的hashCode()做hash
3 return putVal(hash(key), key, value, false, true);
4 }
5
6 final V putVal(int hash, K key, V value, boolean onlyIfAbsent,
7 boolean evict) {
8 Node<K,V>[] tab; Node<K,V> p; int n, i;
9 // 步骤①:table为空则创建,触发resize方法
10 if ((tab = table) == null || (n = tab.length) == 0)
11 n = (tab = resize()).length;
12 // 步骤②:计算index,并对null做处理
13 if ((p = tab[i = (n - 1) & hash]) == null)
14 tab[i] = newNode(hash, key, value, null);
15 else {
16 Node<K,V> e; K k;
17 // 步骤③:节点key存在,直接覆盖value
18 if (p.hash == hash &&
19 ((k = p.key) == key || (key != null && key.equals(k))))
20 e = p;
21 // 步骤④:判断该链为红黑树
22 else if (p instanceof TreeNode)
23 e = ((TreeNode<K,V>)p).putTreeVal(this, tab, hash, key, value);
24 // 步骤⑤:该链为链表
25 else {
26 for (int binCount = 0; ; ++binCount) {
27 if ((e = p.next) == null) {
//对于计算出的存储位置下标已经有数据,也就是冲突,转成链表存到下一位
28 p.next = newNode(hash, key,value,null);
//链表长度大于8转换为红黑树进行处理
29 if (binCount >= TREEIFY_THRESHOLD - 1) // -1 for 1st
30 treeifyBin(tab, hash);
31 break;
32 }
// key已经存在直接覆盖value
33 if (e.hash == hash &&
34 ((k = e.key) == key || (key != null && key.equals(k))))
35 break;
36 p = e;
37 }
38 }
39
40 if (e != null) { // existing mapping for key
41 V oldValue = e.value;
42 if (!onlyIfAbsent || oldValue == null)
43 e.value = value;
44 afterNodeAccess(e);
45 return oldValue;
46 }
47 }
48 ++modCount;
49 // 步骤⑥:超过最大容量就扩容,门限原本是初始容量*0.75
50 if (++size > threshold)
51 resize(); //扩原来的2倍
52 afterNodeInsertion(evict);
53 return null;
54 }
①.判断键值对数组table[i]是否为空或为null,如果为空,则执行resize()进行扩容,初始容量为16,扩展后是原来的2倍;
②.根据键值key计算hash值得到插入的数组索引i,如果table[i]==null,直接新建节点添加,转向⑥,如果table[i]不为空,转向③;
③.判断table[i]的首个元素是否和key一样,如果相同直接覆盖value,否则转向④,这里的相同指的是hashCode以及equals;
④.判断table[i] 是否为treeNode,即table[i] 是否是红黑树,如果是红黑树,则直接在树中插入键值对,否则转向⑤;
⑤.遍历table[i],判断链表长度是否大于8,大于8的话把链表转换为红黑树,在红黑树中执行插入操作,否则进行链表的插入操作;遍历过程中若发现key已经存在直接覆盖value即可;
⑥.插入成功后,判断实际存在的键值对数量size是否超多了最大容量threshold,如果超过,进行扩容。
使用hash函数对输出的键进行计算,得出一个值:
/**这是一个神奇的函数,用了很多的异或,移位等运算
对key的hashcode进一步进行计算以及二进制位的调整等来保证最终获取的存储位置尽量分布均匀*/
final int hash(Object k) {
int h = hashSeed;
if (0 != h && k instanceof String) {
return sun.misc.Hashing.stringHash32((String) k);
}
h ^= k.hashCode();
h ^= (h >>> 20) ^ (h >>> 12);
return h ^ (h >>> 7) ^ (h >>> 4);
}
hash函数计算出的值,要再通过indexFor进一步处理来获取实际的存储位置:
//返回数组下标,实际的存储位置
static int indexFor(int h, int length) {
return h & (length-1); //取模运算
}
对于任意给定的对象,只要它的hashCode()返回值相同,那么程序调用方法一所计算得到的Hash码值总是相同的。我们首先想到的就是把hash值对数组长度取模运算,这样一来,元素的分布相对来说是比较均匀的。但是,模运算的消耗还是比较大的,在HashMap中是这样做的:调用indexFor计算该对象应该保存在table数组的哪个索引处。
这个方法非常巧妙,它通过h & (table.length -1)来得到该对象的保存位,而HashMap底层数组的长度总是2的n次方,这是HashMap在速度上的优化。当length总是2的n次方时,h& (length-1)运算等价于对length取模,也就是h%length,但是&比%具有更高的效率。
JDK1.7与JDK1.8的扩容机制有所不同。
先看JDK1.7的代码,看什么时候需要扩容:
扩容必须满足两个条件:
1、 存放新值的时候当前已有元素的个数必须大于等于阈值
2、 存放新值的时候当前存放数据发生hash碰撞(当前key计算的hash值换算出来的数组下标位置已经存在值)
在JDK1.7中,先判断是否需要扩容,然后再存放新元素。
从JDK1.7的put方法中,当将要存储的数据经过计算存入的位置目前为空,就使用addEntry将数据存入:
//添加新的元素
void addEntry(int hash, K key, V value, int bucketIndex) {
if ((size >= threshold) && (null != table[bucketIndex])) { //threshold为当前容量乘负载因子
resize(2 * table.length);//当size超过临界阈值threshold,并且即将发生哈希冲突时进行扩容
hash = (null != key) ? hash(key) : 0;
bucketIndex = indexFor(hash, table.length);
}
createEntry(hash, key, value, bucketIndex);
}
**1.7中扩容条件有两个:
//扩容方法
1 void resize(int newCapacity) { //传入新的容量
2 Entry[] oldTable = table; //引用扩容前的Entry数组
3 int oldCapacity = oldTable.length;
4 if (oldCapacity == MAXIMUM_CAPACITY) { //扩容前的数组大小如果已经达到最大(2^30)了
5 threshold = Integer.MAX_VALUE; //修改阈值为int的最大值(2^31-1),这样以后就不会扩容了
6 return;
7 }
8
9 Entry[] newTable = new Entry[newCapacity]; //初始化一个新的Entry数组
10 transfer(newTable); //!!将数据转移到新的Entry数组里,数据迁移!!
11 table = newTable; //HashMap的table属性引用新的Entry数组
12 threshold = (int)(newCapacity * loadFactor);//修改阈值
13 }
resize()方法还调用了transfer()方法进行数据迁移,用来把原来的数据复制到新扩展的HashMap中,而这个函数也导致了HashMap的线程不安全:
//数据迁移的方法,头插法
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
//for循环中的代码,逐个遍历链表,重新计算索引位置,将老数组数据复制到新数组中去(数组不存储实际数据,所以仅仅是拷贝引用而已)
for (Entry<K,V> e : table) {
while(null != e) {
Entry<K,V> next = e.next;
if (rehash) {
e.hash = null == e.key ? 0 : hash(e.key);
}
int i = indexFor(e.hash, newCapacity);
//将当前entry的next链指向新的索引位置,newTable[i]有可能为空,有可能也是个entry链,如果是entry链,直接在链表头部插入。
//以下三行代码多线程造成环
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
transfer()方法将老数组中的数据逐个链表地遍历,扔到新的扩容后的数组中,我们的数组索引位置的计算是通过 对key值的hashcode进行hash扰乱运算后,再通过和 length-1进行位运算得到最终数组索引位置。
Java8不再像Java7中那样需要满足两个条件,Java8中扩容只需要满足一个条件:当前存放新值(注意不是替换已有元素位置时)的时候已有元素的个数大于等于阈值(已有元素等于阈值,下一个存放后必然触发扩容机制)
注:在JDK1.8 中的put方法中,是先添加元素,添加元素之后再判断数组的容量超过阈值就直接扩容,和jdk1.7的顺序不同。(JDK1.8添加完完素之后判断是否进行扩容)
JDK8的rehash过程很有趣,相比JDK7做了不少优化,我们来看下这里的rehash过程。
// 数组扩容为之前2倍大小的代码省略,这里主要分析rehash过程。
if (oldTab != null) {
// 遍历旧数组
for (int j = 0; j < oldCap; ++j) {
Node<K,V> e;
if ((e = oldTab[j]) != null) {
oldTab[j] = null;
// 1. 如果旧数组中不存在碰撞,则直接移动到新数组的位置
if (e.next == null)
newTab[e.hash & (newCap - 1)] = e;
else if (e instanceof TreeNode)
// 2. 如果存在碰撞,且节点类型是树节点,则进行树节点拆分(挂载到扩容后的数组中或者转为链表)
((TreeNode<K,V>)e).split(this, newTab, j, oldCap);
else { // preserve order
// 3. 处理冲突是链表的情况,会保留原有节点的顺序
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
// 4. 判断扩容后元素是否在原有的位置(这里非常巧妙,下面会分析)
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
// 5. 元素不是在原有位置
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
// 6. 将扩容后未改变index的元素复制到新数组
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
// 7. 将扩容后改变了index位置的元素复制到新数组
if (hiTail != null) {
hiTail.next = null;
// 8. index改变后,新的下标是j+oldCap,这里也很巧妙,下面会分析
//扩容后的新位置只有两个,要么新位置的下标和原来位置一样,要么就是在原来下标的基础上加上扩容大小。
newTab[j + oldCap] = hiHead;
}
}
}
}
}
上面的代码中展现了整个rehash(扩容后,将原来数据迁移旧数据中药重新计算下标)的过程,先遍历旧数组中的元素,接着做下面的事情
如果旧数组中不存在数据碰撞(未挂载链表或者红黑树),那么直接将元素赋值到新数组中,其中index=e.hash & (newCap - 1)。
如果存在碰撞,且节点类型是树节点,则进行树节点拆分(挂载到扩容后的数组中或者转为链表)
如果存在碰撞,且节点是链表,则处理链表的情况,rehash过程会保留节点原始顺序(JDK7中不会保留,这也是导致jdk7中多线程出现死循环的原因)
判断元素在扩容后是否还处于原有的位置,这里通过(e.hash & oldCap) == 0判断,oldCap表示扩容前数组的大小。
发现元素不是在原有位置,更新hiTail和hiHead的指向关系
将扩容后未改变index的元素复制到新数组
将扩容后改变了index位置的元素复制到新数组,新数组的下标是 j + oldCap。
其中第4点和第5点中将链表的元素分为两部分(do…while部分),一部分是rehash后index未改变的元素,一部分是index被改变的元素。分别用两个指针来指向头尾节点。
比如当oldCap=8时,1–>9–>17都挂载在tab[1]上,而扩容后,1–>17挂载在tab[1]上,9挂载在tab[9]上。
那么是如何确定rehash后index是否被改变呢?改变之后的index又变成了多少呢?
这里的设计很是巧妙,还记得HashMap中数组大小是2的n次幂吗?当我们计算索引位置的时候,使用的是 e.hash & (table.length -1)。
这里我们讨论数组大小从8扩容到16的过程。
tab.length -1 = 7 0 0 1 1 1
e.hashCode = x 0 x x x x
==============================
0 0 y y y
扩容后,index的位置由低四位来决定,而低三位和扩容前一致。也就是说扩容后index的位置是否改变是由高字节来决定的,也就是说我们只需要将hashCode和高位进行运算即可得到index是否改变。
如果初始化中传入的长度不是2的整数次幂,会初始化成距离传入数字最近的整数次幂。
还是看HashMap中put方法的部分源码:
// 步骤②:计算index,并对null做处理
if ((p = tab[i = (n - 1) & hash]) == null)
tab[i] = newNode(hash, key, value, null);
以及indexFor()方法获取要存入数据的实际位置:
//返回数组下标,实际的存储位置
static int indexFor(int h, int length) {
return h & (length-1); //取模运算
}
可以看出,向集合中添加元素时,会使用(n - 1) & hash的计算方法来得出该元素在集合中的位置;在HashMap扩容时调用resize()方法中的部分源码,可以看出会新建一个table,然后遍历旧的table,将旧的元素进过e.hash & (newCap - 1)的计算添加进新的tab中,也是(n - 1) & hash的计算方法,其中n是集合的容量,hash是添加的元素进过hash函数计算出来的hash值。
这个 h & (length-1) 至关重要 ,假如算出h的值是50,这个数组的容量目前是16,如果计算出来待存储数据的下标大于16怎么办,如何保证计算出的下标不会越界呢?最简单的问题就是用50除以16然后取余数(也叫取模。用%进行)作为下标,这个余数一定不会越界。但是在计算机中,取余的运算是十分的缓慢的。但是符号&是按位与的计算,这是位运算,计算机能直接运算,特别高效。当数组的长度 length 是2的n次幂时,其2进制表示为第一位是1,后面所有位都是0,length-1就是前面位是0,后面所有位都是1,类似于 00011***11这样的形式,这样与添加元素的hash值进行位运算时,与length-1也就是00011***11对应0的部分与的话是0,对应1的部分与的结果是它本身,与的结果最大一定是00011***11,最小结果都是0,正好是0到length-1,与数组的下标一一对应。计算出来正好是与数组的下标一一对应,这就是原因一。
再者,假设数组长度不取2的整数幂,而是一个奇数的话,那么length-1的最后一位是0,h与之相与后最后一位永远是0,导致数组下标是奇数的一直存不了数。假设数组的长度是一个偶数,但是不是2的整数幂,例如长度是10,那么length-1是9,对应2进制是1001,那么任意的数和它与的结果中,倒数第二位和第三位永远是0,这样还是有很多数组的角标被浪费。不会有空间的浪费,这就是原因二。
最后,当HashMap进行扩容时,容量扩展到原来的2倍,原来数组中的内容要迁移到扩展后的数组当中,那么迁移时就要计算每个值的新下标,假如扩容前的容量是8,对应length-1的2进制是0111,扩容后的容量是16,对应length-1的2进制是1111,那么在重新计算数组下标时:在扩容的数组中下标的后3位于原来数组相同,只有第一位可能不同。那么就只有两种情况:如果第一位也相同的话,那么迁移前后下标不变,如果第一位不同,那么迁移后下标加上扩容长度即可。扩容后数据迁移时,不需要重新计算hash,只判断其中一位即可,效率大大提高。
HashMap的线程不安全主要体现在下面两个方面:
1.在JDK1.7中,当并发执行扩容操作时会造成环形链和数据丢失的情况。
2.在JDK1.8中,在并发执行put操作时会发生数据覆盖的情况。
详细图解见:
图解HashMap为什么线程不安全?
桶中元素个数和概率的对照表:
0: 0.60653066
1: 0.30326533
2: 0.07581633
3: 0.01263606
4: 0.00157952
5: 0.00015795
6: 0.00001316
7: 0.00000094
8: 0.00000006
more: less than 1 in ten million
泊松分布
从上面的表中可以看到当桶中元素到达8个的时候,概率已经变得非常小,也就是说用0.75作为加载因子,每个碰撞位置的链表长度超过8个是几乎不可能的。
加载因子过高,例如为1,虽然减少了空间开销,提高了空间利用率,但同时也增加了查询时间成本;
加载因子过低,例如0.5,虽然可以减少查询时间成本,但是空间利用率很低,同时提高了rehash操作的次数。
选择0.75作为默认的加载因子,完全是时间和空间成本上寻求的一种折衷选择。
找到bucket位置之后,会调用keys.equals()方法去找到链表中正确的节点,最终找到要找的值对象。
String, Interger这样的wrapper类作为HashMap的键很常见,而且String最为常用。因为String是不可变的,也是final的,而且已经重写了equals()和hashCode()方法了。其他的wrapper类也有这个特点。不可变性是必要的,因为为了要计算hashCode(),就要防止键值改变,如果键值在放入时和获取时返回不同的hashcode的话,那么就不能从HashMap中找到你想要的对象。不可变性还有其他的优点如线程安全。如果你可以仅仅通过将某个field声明成final就能保证hashCode是不变的,那么请这么做吧。因为获取对象的时候要用到equals()和hashCode()方法,那么键对象正确的重写这两个方法是非常重要的。如果两个不相等的对象返回不同的hashcode的话,那么碰撞的几率就会小些,这样就能提高HashMap的性能。
JDK 1.8 中,是通过 hashCode() 的高 16 位异或低 16 位实现的:(h = k.hashCode()) ^ (h >>> 16),主要是从速度,功效和质量来考虑的,减少系统的开销,也不会造成因为高位没有参与下标的计算,从而引起的碰撞。
保证了对象的 hashCode 的 32 位值只要有一位发生改变,整个 hash() 返回值就会改变。尽可能的减少碰撞。
①、table 数组大小是由 capacity 这个参数确定的,默认是16,也可以构造时传入,最大限制是1<<30;
②、loadFactor 是装载因子,主要目的是用来确认table 数组是否需要动态扩展,默认值是0.75,比如table 数组大小为 16,装载因子为 0.75 时,threshold 就是12,当 table 的实际大小超过 12 时,table就需要动态扩容;
③、扩容时,调用 resize() 方法,将 table 长度变为原来的两倍(注意是 table 长度,而不是 threshold)
④、如果数据很大的情况下,扩展时将会带来性能的损失,在性能要求很高的地方,这种损失很可能很致命。
之所以选择红黑树是为了解决二叉查找树的缺陷,二叉查找树在特殊情况下会变成一条线性结构(这就跟原来使用链表结构一样了,造成很深的问题),遍历查找会非常慢。
而红黑树在插入新数据后可能需要通过左旋,右旋、变色这些操作来保持平衡,引入红黑树就是为了查找数据快,解决链表查询深度的问题,我们知道红黑树属于平衡二叉树,但是为了保持“平衡”是需要付出代价的,但是该代价所损耗的资源要比遍历线性链表要少,所以当长度大于8的时候,会使用红黑树,如果链表长度很短的话,根本不需要引入红黑树,引入反而会慢。
LinkedHashMap 保存了记录的插入顺序,在用 Iterator 遍历时,先取到的记录肯定是先插入的;遍历比 HashMap 慢;通常用在需要输出的顺序和输入的顺序相同的情况下。
TreeMap 实现 SortMap 接口,能够把它保存的记录根据键排序(默认按键值升序排序,也可以指定排序的比较器),通常用在需要按自然顺序或自定义顺序遍历键的情况下;
(1)多线程扩容,引起的死循环问题
(2)多线程put的时候可能导致元素丢失
(3)put非null元素后get出来的却是null
在jdk1.8中,死循环问题已经解决。其他两个问题还是存在。
可以,key为null的时候,hash算法最后的值以0来计算,也就是放在数组的第一个位置。
不是,懒加载机制,是在put第一个数据的时候map才会初始化。
不是的,是在得到hashcode的基础上经过了二次加工,使用 hashCode() 的高 16 位异或低 16 位实现呢((h = k.hashCode()) ^ (h >>> 16))
主要是为了保留高位和低位的信息,能够表现目标值的特征,均匀分布, 减少碰撞。
因为和(len - 1)进行&操作的时候,(len - 1)这个数不会特别大,高位都是0,hashCode的高位与0与之后都是0,相当于高位信息遗失,只有低位进行与运算,这样更容易产生哈希冲突。为了解决这个问题,将hashcode的高半区和低半区异或,加大低位的随机性。
hashcode % 2^n 其结果就是将 hashcode 右移n位后得到的,当len是2^n,那么len-1的二进制表示低位n个1,高位都是0,进行与运算后将前面置0,和取模结果一致。
JDK7中,HashMap的内部数据保存的都是链表。因此迁移逻辑相对简单:在准备好新的数组后,map会遍历数组的每个“桶”,然后遍历桶中的每个Entity,重新计算其hash值,找到新数组中的对应位置,以头插法插入新的链表。
JDK8则因为巧妙的设计,性能有了大大的提升:由于数组的容量是以2的幂次方扩容的,那么一个Entity在扩容时,新的位置要么在原位置,要么在原长度+原位置的位置。
数据迁移的时候也是分四种情况,第一种是桶内没有数据,第二种是只有一个值,第三种是链表,第四种是红黑树。
当是第二个情况,也就是发现还没有链化,直接迁移就好。
当是第三个情况,也就是发现已经链化,进行rehash操作的时候,会将链表差分成两个链表,一个链表放在高位(高位连),一个链表放在低位(低位连),通过位运算来决定放在原索引处或者原索引加原数组长度的偏移量处。
当时第四种情况,也就是红黑树如何迁移,原来的红黑树里依然保存了next字段,也就是还维护者一个链表,只不过在查询的时候没有根据这个链表查询,进行迁移的时候也是差分成两个链表,一个高位链一个低位链,判断有没有差分后链表长度小于6的情况,有的话就是链表存储,如果还是大于6就会进行红黑树的重建。
Hashtable是线程安全的,适合在多线程的情况下使用,但是效率可不太乐观。HashMap 线程不安全。Hashtable 是不允许键或值为 null 的,HashMap 的键值则都可以为 null。
因为Hashtable在我们put 空值的时候会直接抛空指针异常,但是HashMap却做了特殊处理。Hashtable使用的是安全失败机制,这种机制会使你此次读到的数据不一定是最新的数据。
如果你使用null值,就会使得其无法判断对应的key是不存在还是为空,因为你无法再调用一次contain(key)来对key是否存在进行判断,ConcurrentHashMap同理。
**快速失败(fail—fast)**是java集合中的一种机制, 在用迭代器遍历一个集合对象时,如果遍历过程中对集合对象的内容进行了修改(增加、删除、修改),则会抛出Concurrent Modification Exception。
两个条件:链表的长度大于8,数组的长度大于64。
如果只满足第一个条件只会进行扩容。