HashMap是Java当中很常用的数据结构。
那么HashMap是线程安全的吗?高并发情况下HashMap会出现什么问题?为什么HashMap在高并发情况下会出现死锁?
Java8中,HashMap的结构有什么样的优化呢?
下面我们一起来看一下高并发情况下,HashMap可能出现的致命问题。
在分析高并发场景之前,我们需要先搞清楚[rehash]这个概念。
Rehash是HashMap在扩容时候的一个步骤。
HashMap的容量是有限的。当经过多次元素插入,使得HashMap达到一定饱和度时,Key映射位置发生冲突的几率会逐渐提高。
这时候,HashMap需要扩展它的长度,也就是进行Resize。
影响发生Resize的因素有两个:
1.Capacity
HashMap的当前长度。HashMap的默认初始长度是16 ,每次自动扩展或手动初始化时,长度必须是2的幂。
2.LoadFactor
HashMap负载因子,默认值为0.75f。
衡量HashMap是否进行Resize的条件如下:HashMap.Size >= Capacity * LoadFactor。
就是当HashMap中已经使用的长度大于HashMap的总长度乘以负载因子时就需要扩容了。
如上图,HashMap.Capacity = 8,HashMap.Size = 6,Capacity * LoadFactor = 8*0.75 = 6,
满足HashMap.Size >= Capacity * LoadFactor的条件,这个时候就需要扩容了,扩容需要调用HashMap的Resize( )方法。
HashMap的Resize( )方法,具体做了什么事情呢?
HashMap的Resize( )方法不是简单的把长度扩大,而是经过下面两个步骤。
1.扩容
创建一个新的Entry空数组,长度是原数组的2倍。
2.ReHash
遍历原Entry数组,把所有的Entry重新Hash到新数组。为什么要重新Hash呢?因为长度扩大以后,Hash的规则也随之改变。
让我们回顾一下Hash公式:
index = HashCode(Key) & (Length - 1)
当原数组长度为8时,Hash运算是和111B做与运算;新数组长度为16,Hash运算是和1111B做与运算。Hash结果显然不同。
Resize前的HashMap:
<