为什么HashMap 头插法会造成死锁

为什么HashMap 头插法会造成死锁？

本文参考

在该文章基础上，进行了进一步的扩容和迭代

死循环执行步骤1

死循环是因为并发 HashMap 扩容导致的，并发扩容的第一步，线程 T1 和线程 T2 要对 HashMap 进行扩容操作，此时 T1 和 T2 指向的是链表的头结点元素 A，而 T1 和 T2 的下一个节点，也就是 T1.next 和 T2.next 指向的是 B 节点，如下图所示：

死循环执行步骤2

死循环的第二步操作是，线程 T2 时间片用完进入休眠状态，而线程 T1 开始执行扩容操作，一直到线程 T1 扩容完成后，线程 T2 才被唤醒，扩容之后的场景如下图所示： 从上图可知线程 T1 执行之后，因为是头插法，所以 HashMap 的顺序已经发生了改变，但线程 T2 对于发生的一切是不可知的，所以它的指向元素依然没变，如上图展示的那样，T2 指向的是 A 元素，T2.next 指向的节点是 B 元素。

死循环执行步骤3

当线程 T1 执行完，而线程 T2 恢复执行时，死循环就建立了，如下图所示： 因为 T1 执行完扩容之后 B 节点的下一个节点是 A，而 T2 线程指向的首节点是 A，第二个节点是 B，这个顺序刚好和 T1 扩完容完之后的节点顺序是相反的。 T1 执行完之后的顺序是 B 到 A，而 T2 的顺序是 A 到 B，这样 A 节点和 B 节点就形成死循环了 ，这就是 HashMap 死循环导致的原因。

继续进行扩容后会变成以下：（1 –c ; 2 – b ; a – 3 ） ; 根据源码 C 永远进入不了table； 扩容后会一直陷入一个BA 的死循环

底层源码

/**
 * 将所有Entry从当前表转移到newTable。
 */
void transfer(Entry[] newTable, boolean rehash) {
    int newCapacity = newTable.length; //容量
    for (Entry<K,V> e : table) { //遍历table[1,2,3,4,5]
        while(null != e) { //遍历table中的链表table[i]

            Entry<K,V> next = e.next; // 1线程在跑，2线程没有跑
            if (rehash) { //如果是重新Hash，则需要重新计算hash值
                e.hash = null == e.key ? 0 : hash(e.key);
            }

            int i = indexFor(e.hash, newCapacity); //定位Hash桶
            //元素连接到桶中，这里相当于单链表的插入，总是插入在最前面，指针指向他下面的一个元素
            e.next = newTable[i];
            //newTable[i]的值总是最新插入的值
            newTable[i] = e;
            //继续下一个元素
            e = next;
        }
    }
}

解决方案

HashMap 死循环的常用解决方案有以下几个：

1. 升级到高版本 JDK（JDK 1.8 以上），高版本 JDK 使用的是尾插法插入新元素的，所以不会产生死循环的问题；
2. 使用线程安全容器 ConcurrentHashMap 替代（推荐使用此方案）；
3. 使用线程安全容器 Hashtable 替代（性能低，不建议使用）；
4. 使用 synchronized 或 Lock 加锁 HashMap 之后，再进行操作，相当于多线程排队执行（比较麻烦，也不建议使用）。