JDK1.7HashMap多线程扩容为什么会死循环示例详解

一、前言

说到 Ja va 里的 HashMap，几乎每个开发者都打过交道。作为最常用的数据结构之一，它的底层实现其实并不复杂——早期版本的 HashMap 主要依赖数组加链表来组织数据：

数组 + 链表

到了 JDK 1.8，又多了一个红黑树结构：

数组 + 链表 + 红黑树

但提起老版本（JDK 1.7）的 HashMap，就绕不开一个经典的坑——多线程环境下同时扩容，可能导致链表形成环，进而引发死循环。

这个问题的根源其实很清晰：

JDK 1.7 HashMap 扩容时使用头插法；
头插法会修改节点的 next 指针；
多个线程同时扩容时，会操作同一批节点对象；
最终可能导致 A.next = B，B.next = A，形成环。

看上去有点抽象？别急，我们一步步拆开来看。

二、HashMap 扩容是不是在原数组上改？

当然不是。Ja va 数组一旦创建，长度就固定了，没法原地“变大”。比如你声明一个长度为 16 的数组，不可能让它直接变成 32。

所以 HashMap 扩容的流程是这样的：

1. 创建一个更大的新数组
2. 遍历旧数组中的节点
3. 把旧节点重新挂到新数组中
4. 最后让 table 指向新数组

换句话说，就是：

oldTable 长度 16
扩容后创建 newTable 长度 32
最后 table = newTable

但这里有一个关键点——数组是新的，但节点对象不是新的。

什么意思呢？扩容时并不会复制节点本身，而是把旧数组里的节点对象“搬”到新数组里。例如旧数组中有：

oldTable[3] -> 节点1 -> 节点2 -> null

扩容后，并不是在 newTable 里创建新的节点1和节点2，而是直接复用原来的节点对象：

newTable[3] -> 原来的节点1 / 原来的节点2

节点对象是复用的，这一点非常重要。

三、为什么放到新数组里还要修改 next？

因为数组每个位置只能放一个头节点。如果多个元素命中了同一个桶，就必须通过链表连接起来。比如：

newTable[5] -> 节点1 -> 节点2 -> null

真正维护链表关系的是 next 指针：

节点1.next = 节点2
节点2.next = null

所以扩容迁移时，必然要重新整理节点之间的 next 指针——这也是问题滋生的土壤。

四、JDK 1.7 的头插法是什么？

JDK 1.7 的扩容迁移用的是头插法。核心逻辑简化一下就是：

Entry next = e.next;                // 先保存旧链表中的下一个节点
int i = indexFor(e.hash, newCapacity);   // 计算新数组下标
e.next = newTable[i];                    // 当前节点指向新桶原来的头节点
newTable[i] = e;                         // 当前节点成为新桶的新头节点
e = next;                                // 继续处理下一个旧节点

最核心的一步就是 e.next = newTable[i]——这句话会修改当前节点的 next 指针。

五、单线程下头插法为什么没问题？

假设旧链表是：

节点1 -> 节点2 -> null

扩容时，一开始新数组桶为空：newTable[i] = null

先迁移节点1：

节点1.next = newTable[i];   // 即 null
newTable[i] = 节点1;

新链表变成：newTable[i] -> 节点1 -> null

再迁移节点2：

节点2.next = newTable[i];   // 此时 newTable[i] 是节点1
newTable[i] = 节点2;

新链表变成：newTable[i] -> 节点2 -> 节点1 -> null

看到了吗？原来的链表顺序被反转了：

原链表：节点1 -> 节点2 -> null
新链表：节点2 -> 节点1 -> null

单线程下这没问题——只是顺序反了，但链表最终仍然指向 null，一切正常。

六、多线程扩容为什么会出问题？

问题就出在：两个线程同时扩容同一个 HashMap。

假设旧数组某个桶中挂了两个节点：

oldTable[3] -> 节点1 -> 节点2 -> null

现在两个线程同时触发了扩容：线程A创建了 newTableA，线程B创建了 newTableB，这两个新数组彼此独立。但注意——

节点1和节点2是同一批旧节点对象。

也就是说，两个线程操作的是同一个节点1和同一个节点2。这就埋下了冲突的种子。

七、详细模拟多线程扩容过程

第一步：线程A开始扩容

线程A准备迁移节点1。它先执行了：

e = 节点1;
next = e.next;

此时：e = 节点1，next = 节点2——线程A已经记住了节点1后面是节点2。

但就在这个时候，线程A被 CPU 暂停了。当前旧链表还是完好的：

节点1 -> 节点2 -> null

第二步：线程B开始并完成扩容

线程B也开始处理同一条旧链表。注意，此时节点1和节点2的 next 还是原始状态。

线程B先迁移节点1。它自己的新桶为空：newTableB[i] = null。执行头插法：

节点1.next = newTableB[i];   // 即 null
newTableB[i] = 节点1;

新链表：newTableB[i] -> 节点1 -> null

然后迁移节点2。此时 newTableB[i] = 节点1：

节点2.next = newTableB[i];   // 即 节点1
newTableB[i] = 节点2;

新链表：newTableB[i] -> 节点2 -> 节点1 -> null

此时，真实世界中节点对象的关系已经变成：

节点2.next = 节点1
节点1.next = null

也就是：节点2 -> 节点1 -> null

注意——线程B修改的是节点对象自己的 next 字段，而不是只修改它自己的数组。

八、线程A恢复执行，问题出现

线程A之前暂停时保存了 e = 节点1，next = 节点2。现在它恢复执行，继续迁移节点1。

线程A自己的新桶为空：newTableA[i] = null。执行头插法：

节点1.next = newTableA[i];   // 即 null
newTableA[i] = 节点1;

线程A的新链表变成：newTableA[i] -> 节点1 -> null

然后线程A执行 e = next，因为之前保存的 next 是节点2，所以 e = 节点2。

九、线程A处理节点2

线程A处理节点2时，先取 next = 节点2.next。

但是！节点2的 next 已经被线程B改过了（线程B之前执行过 节点2.next = 节点1）。所以线程A拿到的 next = 节点1。

然后线程A把节点2头插到自己的新数组中：

节点2.next = newTableA[i];   // 此时 newTableA[i] = 节点1
newTableA[i] = 节点2;

等价于 节点2.next = 节点1。线程A的新链表变成：newTableA[i] -> 节点2 -> 节点1 -> null

接着，线程A执行 e = next，而 next = 节点1——所以线程A又回到了节点1。

十、线程A再次处理节点1，形成环

此时线程A的新桶头节点是节点2：newTableA[i] = 节点2。线程A再次处理节点1，执行头插法：

节点1.next = newTableA[i];   // 即 节点2
newTableA[i] = 节点1;

等价于 节点1.next = 节点2。

但前面已经有 节点2.next = 节点1。于是链表变成了：

节点1 -> 节点2 -> 节点1 -> 节点2 -> ...

环形链表，形成了。

十一、为什么形成环后会死循环？

HashMap 查询元素时，会沿着链表一直往后找。核心逻辑类似：

while (e != null) {
    if (e.key.equals(key)) {
        return e.value;
    }
    e = e.next;
}

正常链表最终会走到 null，比如 节点1 -> 节点2 -> null。

但如果链表形成了环，比如 节点1 -> 节点2 -> 节点1 -> 节点2 -> ...，那么 e 永远不会变成 null。程序就会陷入无限循环，CPU 占用飙升，看起来就是“卡死了”。

这就是 JDK 1.7 HashMap 多线程扩容死循环问题的完整链条。

十二、关键问题：为什么各自扩容还会互相影响？

核心原因在于：数组是各线程自己的，但节点对象是共享的。

线程A有自己的 newTableA，线程B有自己的 newTableB，但里面存放的地址指向同一批旧节点对象——并不是复制节点。

所以，虽然数组不同，但两个线程修改的是同一个节点对象里的 next 字段。可以把节点理解成这样一个类：

class Entry {
    K key;
    V value;
    Entry next;
}

数组只是保存节点地址：Entry[] table;

扩容时那句 e.next = newTable[i]，直接修改了节点对象内部的 next。所以即使没有动旧数组 oldTable[i]，也会改变旧节点之间的链表关系。

十三、JDK 1.8 是怎么改进的？

JDK 1.8 对 HashMap 做了几个重要优化，一劳永逸地解决了这个问题。

1. 扩容时不再使用头插法

JDK 1.8 扩容时，会把原桶中的链表拆成两条：

lo 链表：留在原位置
hi 链表：移动到 原位置 + oldCap

判断条件很简单：

if ((e.hash & oldCap) == 0) {
    // 留在原位置
} else {
    // 移动到 原位置 + oldCap
}

2. 使用尾插法，保持链表顺序

JDK 1.7 的头插法会反转链表，而 JDK 1.8 改用尾插法，尽量保持原来的顺序。这就避免了头插法带来的典型成环问题。

3. 引入红黑树

当某个桶里的链表过长，并且数组长度达到一定条件时，链表会转成红黑树，避免查询效率下降。

所以结构变成了：

JDK 1.7：数组 + 链表
JDK 1.8：数组 + 链表 + 红黑树

十四、但是 JDK 1.8 的 HashMap 线程安全吗？

不安全。

虽然 JDK 1.8 优化了扩容逻辑，避免了头插法导致的死循环，但 HashMap 本身仍然不是线程安全的。在多线程环境下，多个线程同时读写仍可能出现：

数据覆盖
数据丢失
size 不准确
结构异常

所以，多线程环境下别用普通的 HashMap，老老实实用 ConcurrentHashMap。

十五、面试总结版

如果面试官问起这个问题，可以这样回答：

JDK 1.7 的 HashMap 在扩容时会创建新数组，并把旧数组中的节点迁移过去。数组是新的，但节点对象是复用的，迁移时会修改节点的 next 指针。JDK 1.7 使用头插法迁移链表，这会把链表顺序反转。单线程下没问题，但多线程同时扩容时，多个线程会操作同一批节点对象。如果线程A暂停，线程B完成扩容并反转了链表，线程A恢复后继续使用之前保存的节点引用，就可能出现 节点1.next = 节点2，节点2.next = 节点1，形成环。之后执行 get() 操作时，HashMap 会沿着链表一直查找，永远走不到 null，导致死循环，CPU 飙高。

JDK 1.8 改用尾插法和高低位链表拆分，避免了头插法导致的成环问题。但 HashMap 仍然不是线程安全的，多线程环境下应使用 ConcurrentHashMap。

十六、一句话总结

JDK 1.7 HashMap 多线程扩容死循环的本质是：新数组是各线程自己的，但节点对象是共享的；头插法迁移会修改节点的 next 指针，多个线程交叉修改后可能形成环形链表，导致查询时永远走不到 null。