HashMap和线程安全

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：

Resize后的HashMap：