解析JDK1.7 HashMap 头插法生成的环形链表死循环问题

背景

在JDK1.7中HashMap使用头插法来添加同一位置上的节点,但是在并发的情况下使用HashMap，在进行resize()扩容的过程中，链表可能会形成环状，当在读取HashMap元素的时候会出现死循环，CPU占用飙高，服务器崩溃的问题。

扩容前

正常 resize() 后

并发 resize() 形成环状

在下面我会说明是如何生成该环状

正常扩容resize()的过程

以下执行的过程是在同一链表元素的key值rehash后落到同一坐标上为基础

我们需要关注的是HashMap的resize()方法,真正rehash的过程是在transfer()中

首先就是创建一个新的数组newTable，然后把旧table中的数据搬运到newTable中，最后使用newTable覆盖原本的table

这里首先会遍历table数组，比如第一个元素e就是对应table中索引为0的元素，e是一个链表的头节点，while里面的逻辑就是循环遍历e指向的整一条链表，把这条链表的每一个节点进行rehash并使用头插法放入到新table中

当前HashMap的结构

假设再添加一个元素触发扩容，扩容为原本数组table长度的2倍

遍历table取到第一个元素e

取到元素e的下一个节点next

e的next指向newTable中的i坐标，即当前坐标i

当前newTable[i]=NULL，指向了一个NULL值

将e放入到newTable[i]

执行e=next，while循环会重复执行上述流程，直到链表遍历完毕

下图可以看到resize之后，链表的元素由于头插法的原因，顺序翻转了

并发resize()导致链表环的过程

注意以下执行的过程是在同一链表元素的key值rehash后落到同一坐标上为基础

假设同时有两个线程同时执行触发了同一个HashMap对象的resize()过程，他们同时进入到了transfer()方法中，并且同时进入到while(null!=e)方法中，都执行了步骤(1)，但是由于线程2的CPU时间片执行完了，进入就绪状态，此时线程1继续执行。

执行流程看下面

线程1

线程1在执行完步骤(3)后，CPU分配的时间片已经执行完，线程1进入到就绪状态

当前线程1执行的流程定格在下图

线程2

线程2执行(1)之后进入就绪状态

现在线程(1)进入就绪状态之后，线程2被CPU唤醒进入运行状态，线程2接下来执行步骤(2)，现在newTable[i]的值已经被线程1赋值为e，即e->1->null，线程2这里执行e.next=newTable[i]，相当于，e自己指向自己，变为e.next=e，即e->1->1，形成了环状。

最后resize()完成形成了环状

总结

• HashMap是线程不安全的类，本该不应该用在并发的场景，在并发场景下应该使用ConcurrentHashMap
• 使用头插法的原因，我听过是因为HashMap的编写人员认为新加入的数据更常用，在取数据的时候，能够更快的取到该数据
• 在JDK1.8中HashMap已经采用了尾插法防止了环形链表的产生