高并发下的HashMap
这些讨论是在1.8之前的java下作的分析,1.8的HashMap做了很大的变化,可以保证高并发下的安全性(多线程)。
HashMap的容量是有限的。当经过多次元素插入,使得HashMap达到一定饱和度时,Key映射位置发生冲突的几率会逐渐提高。
这时候,HashMap需要扩展它的长度,也就是进行Resize。
影响发生Resize的因素有两个:
1.Capacity
HashMap的当前长度。HashMap的长度是2的幂。2.LoadFactor
HashMap负载因子,默认值为0.75f。
衡量HashMap是否进行Resize的条件如下:
HashMap.Size >= Capacity * LoadFactor
Resize经过了两个步骤:
1.扩容
创建一个新的Entry空数组,长度是原数组的2倍。
2.ReHash
遍历原Entry数组,把所有的Entry重新Hash到新数组。为什么要重新Hash呢?因为长度扩大以后,Hash的规则也随之改变。
可以理解为我们10口之家从50平的筒子楼搬到了500平的豪华别墅,我们再也不需要6个人挤一个房间了 ,我们可以有自己的独立空间了(人口下一次增加之前)
ReSize的过程
ReHash的Java代码如下:
/**
* Transfers all entries from current table to newTable.
*/
void transfer(Entry[] newTable, boolean rehash) {
int newCapacity = newTable.length;
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);
/*
*头插法,新的节点插在旧的队列前面
*/
e.next = newTable[i];
newTable[i] = e;
e = next;
}
}
}
刚才发生的一切都是在单线程下发生的,但是在多线程的情况下,事情就发生了很大的变化:
假设一个HashMap已经到了Resize的临界点。此时有两个线程A和B,在同一时刻对HashMap进行Put操作:
此时达到Resize条件,两个线程各自进行Rezie的第一步,也就是扩容:
这时候,两个线程都走到了ReHash的步骤。让我们回顾一下ReHash的代码:
假如此时线程B遍历到Entry3对象,刚执行完红框里的这行代码,线程就被挂起。对于线程B来说:
e = Entry3 //第一次循环
next = Entry2 //第一次循环
这时候线程A畅通无阻地进行着Rehash,当ReHash完成后,结果如下(图中的e和next,代表线程B的两个引用):
直到这一步,看起来没什么毛病。接下来线程B恢复,继续执行属于它自己的ReHash。线程B刚才的状态是:
e = Entry3 //第一次循环
next = Entry2 //第一次循环
当执行到上面这一行时,显然 i = 3,因为刚才线程A对于Entry3的hash结果也是3。
我们继续执行到这两行,Entry3放入了线程B的数组下标为3的位置,并且e指向了Entry2。此时e和next的指向如下:
e = Entry2 //代码结尾指向
next = Entry2 //代码开头指向
整体情况如图所示:
接着是新一轮循环,又执行到红框内的代码行:
e = Entry2 //上一循环中指向
next = Entry3 //本次循环开头指向
然后执行头插法,变成:
第三次循环开始,又执行到红框的代码:
此时:
e = Entry3 //上一轮结尾指向
next = Entry3.next = null //线程A的指向为null
这个时候,由于是头插法,这里产生了环
newTable[i] = Entry2
e = Entry3
Entry2.next = Entry3
Entry3.next = Entry2
此时,问题还没有直接产生。当调用Get查找一个不存在的Key,而这个Key的Hash结果恰好等于3的时候,由于位置3带有环形链表,所以程序将会进入死循环!
总结:
1.Hashmap在插入元素过多的时候需要进行Resize,Resize的条件是
HashMap.Size >= Capacity * LoadFactor。
2.Hashmap的Resize包含扩容和ReHash两个步骤,ReHash在并发的情况下可能会形成链表环。
总结原因是由于,一个线程使用头插法想一个桶的链表的顺序倒置,另一个线程在挂起后先按照一开始的顺序遍历,一次后又按照新的顺序遍历。便形成了环
。但是这种线程不安全并不是每一次都会出现,只有存在概率。
这个问题在1.8版本上有了很大的修改,当一个桶的链表达到8个时,会自动转变为红黑树,避免了这个问题。
JDK1.8后,除了对hashmap增加红黑树结果外,对原有造成死锁的关键原因点(新table复制采用头插法)改进为依次在末端添加新的元素。虽然JDK1.8后添加红黑树改进了链表过长查询遍历慢问题和resize时出现导致put死循环的bug,但还是非线性安全的,比如数据丢失等等。因此多线程情况下还是建议使用concurrenthashmap。
文章绝大部分内容来自公众号《程序员小灰》,学习中加入了自己的一些理解,舔着脸标为原创,不喜可揍,痛揍。