从HashMap到ConcurrentHashMap

一： 什么是HashMap

众所周知，HashMap是一个用于存储Key-Value键值对的集合，每一个键值对也叫做Entry。这些个键值对（Entry）分散存储在一个数组当中，这个数组就是HashMap的主干。

HashMap数组每一个元素的初始值都是Null。

对于HashMap，我们最常使用的是两个方法：Get 和 Put。

1.Put方法的原理

调用Put方法的时候发生了什么呢？

比如调用 hashMap.put("apple", 0) ，插入一个Key为“apple"的元素。这时候我们需要利用一个哈希函数来确定Entry的插入位置（index）：

index = Hash（“apple”）

假定最后计算出的index是2，那么结果如下：

但是，因为HashMap的长度是有限的，当插入的Entry越来越多时，再完美的Hash函数也难免会出现index冲突的情况。比如下面这样：

这时候该怎么办呢？我们可以利用链表来解决。

HashMap数组的每一个元素不止是一个Entry对象，也是一个链表的头节点。每一个Entry对象通过Next指针指向它的下一个Entry节点。当新来的Entry映射到冲突的数组位置时，只需要插入到对应的链表即可：

需要注意的是，新来的Entry节点插入链表时，使用的是“头插法”。至于为什么不插入链表尾部，后面会有解释。

2.Get方法的原理

使用Get方法根据Key来查找Value的时候，发生了什么呢？

首先会把输入的Key做一次Hash映射，得到对应的index：

index = Hash（“apple”）

由于刚才所说的Hash冲突，同一个位置有可能匹配到多个Entry，这时候就需要顺着对应链表的头节点，一个一个向下来查找。假设我们要查找的Key是“apple”：

第一步，我们查看的是头节点Entry6，Entry6的Key是banana，显然不是我们要找的结果。

第二步，我们查看的是Next节点Entry1，Entry1的Key是apple，正是我们要找的结果。

之所以把Entry6放在头节点，是因为HashMap的发明者认为，后插入的Entry被查找的可能性更大。（这个说不好）

到了这里只是对HashMap有一个浅层的理解，下面需要知道，1HashMap的默认长度是多少2高并发状态下，为什么HashMap会出现死锁。

先回答第一个问题，HashMap的默认长度是多少

之前说过，从Key映射到HashMap数组的对应位置，会用到一个Hash函数：

index = Hash（“apple”）

如何实现一个尽量均匀分布的Hash函数呢？我们通过利用Key的HashCode值来做位运算。

如何进行位运算呢？有如下的公式（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值的最后几位。

至于为啥用16，是因为发明者经过反复论证和实践，得出：

长度16或者其他2的幂，Length-1的值是所有二进制位全为1，这种情况下，index的结果等同于HashCode后几位的值。 只要输入的HashCode本身分布均匀，Hash算法的 结果就是均匀的。

二：高并发的HashMap会发生死锁

在讲解高并发的HashMap问题前，先要搞清楚，rehash问题

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的规则也随之改变。

让我们回顾一下Hash公式：

index = HashCode（Key） & （Length - 1）

当原数组长度为8时，Hash运算是和111B做与运算；新数组长度为16，Hash运算是和1111B做与运算。Hash结果显然不同。

Resize前的HashMap：

Resize后的HashMap：

上述方法在单线程下是没有问题的，但是在多线程下就会有问题。

注意：下面的内容十分烧脑，不能完全看懂也没有关系，只要记住最后的结论就行了。

假设一个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

整体情况如图所示：

接下来执行下面的三行，用头插法把Entry2插入到了线程B的数组的头结点：

整体情况如图所示：

第三次循环开始，又执行到红框的代码：

e = Entry3

next = Entry3.next = null

最后一步，当我们执行下面这一行的时候，见证奇迹的时刻来临了：

newTable[i] = Entry2

e = Entry3

Entry2.next = Entry3

Entry3.next = Entry2

链表出现了环形！

整体情况如图所示：

此时，问题还没有直接产生。当调用Get查找一个不存在的Key，而这个Key的Hash结果恰好等于3的时候，由于位置3带有环形链表，所以程序将会进入死循环！

所以为了解决这个链表死循环的问题，出现了ConcurrentHashMap

三：什么是ConcurrentHashMap？

关于ConcurrentHashMap，只要理解 Segment概念就行了

Segment是什么呢？Segment本身就相当于一个HashMap对象。

同HashMap一样，Segment包含一个HashEntry数组，数组中的每一个HashEntry既是一个键值对，也是一个链表的头节点。

单一的Segment结构如下：

像这样的Segment对象，在ConcurrentHashMap集合中有多少个呢？有2的N次方个，共同保存在一个名为segments的数组当中。

因此整个ConcurrentHashMap的结构如下：

可以说，ConcurrentHashMap是一个二级哈希表。在一个总的哈希表下面，有若干个子哈希表。

Case1：不同Segment的并发写入

不同Segment的写入是可以并发执行的。

Case2：同一Segment的一写一读

同一Segment的写和读是可以并发执行的。

Case3：同一Segment的并发写入

Segment的写入是需要上锁的，因此对同一Segment的并发写入会被阻塞。

由此可见，ConcurrentHashMap当中每个Segment各自持有一把锁。在保证线程安全的同时降低了锁的粒度，让并发操作效率更高。

说了这么多废话，其实就要大家记住一点，单线程用HashMap，多线程，高并发用ConcurrentHashMap，不管内部实现，二者对外的接口是一样的。记那么多原理狠累的