转载自微信公众号 #程序员小灰#
众所周知，HashMap是一个用于存储Key-Value键值对的集合，每一个键值对也叫做Entry。这些个键值对（Entry）分散存储在一个数组当中，这个数组就是HashMap的主干。
HashMap数组每一个元素的初始值都是Null。
image
对于HashMap，我们最常使用的是两个方法：Get 和 Put。
1.Put方法的原理
调用Put方法的时候发生了什么呢？
比如调用 hashMap.put("apple", 0) ，插入一个Key为“apple"的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置（index）：
index = Hash（“apple”）
假定最后计算出的index是2，那么结果如下：
image
但是，因为HashMap的长度是有限的，当插入的Entry越来越多时，再完美的Hash函数也难免会出现index冲突的情况。比如下面这样：
image.gif
这时候该怎么办呢？我们可以利用链表来解决。
HashMap数组的每一个元素不止是一个Entry对象，也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时，只需要插入到对应的链表即可：
image.gif
需要注意的是，新来的Entry节点插入链表时，使用的是“头插法”。至于为什么不插入链表尾部，后面会有解释。
2.Get方法的原理
使用Get方法根据Key来查找Value的时候，发生了什么呢？
首先会把输入的Key做一次Hash映射，得到对应的index：
index = Hash（“apple”）
由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。假设我们要查找的Key是“
apple
”：
image
第一步，我们查看的是头节点Entry6，Entry6的Key是banana，显然不是我们要找的结果。
第二步，我们查看的是Next节点Entry1，Entry1的Key是apple，正是我们要找的结果。
之所以把Entry6放在头节点，是因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。
之前说过，从Key映射到HashMap数组的对应位置，会用到一个Hash函数：
index = Hash（“apple”）
如何实现一个尽量均匀分布的Hash函数呢？我们通过利用Key的HashCode值来做某种运算。
image
index = HashCode（ Key ） % Length ?
image
如何进行位运算呢？有如下的公式（Length是HashMap的长度）：
index = HashCode（Key） & （ Length - 1）
下面我们以值为“
book
”的Key来演示整个过程：
1.计算book的hashcode，结果为十进制的3029737，二进制的
101110001110101110 1001。
2.假定HashMap长度是默认的16，计算Length-1的结果为十进制的15，二进制的1111。
3.把以上两个结果做与运算，
101110001110101110 1001 &
1111 = 1001，十进制是9，所以 index=9。
可以说，Hash算法最终得到的index结果，完全取决于Key的Hashcode值的最后几位。
image
image
假设HashMap的长度是10，重复刚才的运算步骤：
image
单独看这个结果，表面上并没有问题。我们再来尝试一个新的HashCode
101110001110101110
1011 ：
image
让我们再换一个HashCode
101110001110101110
**1111 **试试 ：
image
是的，虽然HashCode的倒数第二第三位从0变成了1，但是运算的结果都是1001。也就是说，当HashMap长度为10的时候，有些index结果的出现几率会更大，而有些index结果永远不会出现（比如0111）！
这样，显然不符合Hash算法均匀分布的原则。
反观长度16或者其他2的幂，Length-1的值是所有二进制位全为1，这种情况下，index的结果等同于HashCode后几位的值。
只要输入的HashCode本身分布均匀，Hash算法的
结果就是均匀的。
image
高并发下的HashMap
HashMap的容量是有限的。当经过多次元素插入，使得HashMap达到一定饱和度时，Key映射位置发生冲突的几率会逐渐提高。
这时候，HashMap需要扩展它的长度，也就是进行Resize。
image
影响发生Resize的因素有两个：
1.Capacity
HashMap的当前长度。上一期曾经说过，
HashMap的
长度是2的幂。
2.LoadFactor
HashMap负载因子，默认值为0.75f。
衡量HashMap是否进行Resize的条件如下：
HashMap.Size >= Capacity * L****oadFactor
image
image
final Node<K,V>[] resize() {
Node<K,V>[] oldTab = table;
int oldCap = (oldTab == null) ? 0 : oldTab.length;
int oldThr = threshold;
int newCap, newThr = 0;
···
newThr = oldThr << 1; // double threshold
newCap = oldThr;
···
if (newThr == 0) {
float ft = (float)newCap * loadFactor;
newThr = (newCap < MAXIMUM_CAPACITY && ft < (float)MAXIMUM_CAPACITY ?
(int)ft : Integer.MAX_VALUE);
}
threshold = newThr;
Node<K,V>[] newTab = (Node<K,V>[])new Node[newCap];
···
return newTab;
}
1.扩容
创建一个新的Entry空数组，长度是原数组的2倍。
2.ReHash
遍历原Entry数组，把所有的Entry重新Hash到新数组。为什么要重新Hash呢？因为长度扩大以后，Hash的规则也随之改变。
让我们回顾一下Hash公式：
index = HashCode(Key) & (Length - 1)
static final int hash(Object key) {
int h;
return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);
}
当原数组长度为8时，Hash运算是和111B做与运算；新数组长度为16，Hash运算是和1111B做与运算。Hash结果显然不同。
Resize前的HashMap：
image
Resize后的HashMap：
image
ReHash的Java代码如下：
image.png
//这部分是我的源码1.8
if ((e = oldTab[j]) != null) {
newTab[e.hash & (newCap - 1)] = e;
···
// preserve order
Node<K,V> loHead = null, loTail = null;
Node<K,V> hiHead = null, hiTail = null;
Node<K,V> next;
do {
next = e.next;
if ((e.hash & oldCap) == 0) {
if (loTail == null)
loHead = e;
else
loTail.next = e;
loTail = e;
}
else {
if (hiTail == null)
hiHead = e;
else
hiTail.next = e;
hiTail = e;
}
} while ((e = next) != null);
if (loTail != null) {
loTail.next = null;
newTab[j] = loHead;
}
if (hiTail != null) {
hiTail.next = null;
newTab[j + oldCap] = hiHead;
}
}
image
image
image
注意：下面的内容十分烧脑，请小伙伴们坐稳扶好。
假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B，在同一时刻对HashMap进行Put操作：
image
image
此时达到Resize条件，两个线程各自进行Rezie的第一步，也就是扩容：
image
这时候，两个线程都走到了ReHash的步骤。让我们回顾一下ReHash的代码：
image
假如此时线程B遍历到Entry3对象，刚执行完红框里的这行代码，线程就被挂起。对于线程B来说：
e = Entry3
next = Entry2
这时候线程A畅通无阻地进行着Rehash，当ReHash完成后，结果如下（图中的e和next，代表线程B的两个引用）：
image
直到这一步，看起来没什么毛病。接下来线程B恢复，继续执行属于它自己的ReHash。线程B刚才的状态是：
e = Entry3
next = Entry2
image
当执行到上面这一行时，显然 i = 3，因为刚才线程A对于Entry3的hash结果也是3。
image
我们继续执行到这两行，Entry3放入了线程B的数组下标为3的位置，并且e指向了Entry2。此时e和next的指向如下：
e = Entry2
next = Entry2
整体情况如图所示：
image
接着是新一轮循环，又执行到红框内的代码行：
image
e = Entry2
next = Entry3
整体情况如图所示：
image
接下来执行下面的三行，用头插法把Entry2插入到了线程B的数组的头结点：
image
整体情况如图所示：
image
第三次循环开始，又执行到红框的代码：
image
e = Entry3
next = Entry3.next = null
最后一步，当我们执行下面这一行的时候，
见证奇迹的时刻来临了：
image
**newTable[i] = **Entry2****
e = Entry3
******Entry2.next = Entry3******
Entry3.next = Entry2
链表出现了环形！
整体情况如图所示：
image
此时，问题还没有直接产生。当调用Get查找一个不存在的Key，而这个Key的Hash结果恰好等于3的时候，由于位置3带有环形链表，所以程序将会进入死循环！
这种情况，不禁让人联想到一道经典的面试题：
image
image
image
image
image
1.Hashmap在插入元素过多的时候需要进行Resize，Resize的条件是
****HashMap.Size >= Capacity * L****oadFactor。****
****2. Hashmap的 Resize包含扩容和ReHash两个步骤，ReHash在并发的情况下可能会形成链表环。****
—————END—————
以上内容转载自 程序员小灰
网友评论