HashMap 扩容死循环：深度复现 Java 7 中多线程并发扩容导致的变量指针环路-java教程-PHP中文网

java 7 hashmap多线程扩容死循环是确定性逻辑错误，由头插法、竞态条件和内存可见性缺失共同导致链表成环；复现需同时满足：全局共享未同步实例、并发put触发resize、且被迁移桶中链表长度≥2。

hashmap 扩容死循环：深度复现 java 7 中多线程并发扩容导致的变量指针环路

Java 7 中 HashMap 多线程扩容死循环，本质是头插法 + 竞态条件 + 内存可见性缺失共同触发的链表成环，不是随机卡顿，而是确定性逻辑错误在特定时序下暴露。复现它不靠运气，而在于精准控制三个关键变量：共享 map 实例、强制并发 resize、以及链表长度 ≥2 的桶。

必须满足的复现前提

缺一不可，否则永远看不到环：

全局共享未同步的 HashMap 实例：不能是局部变量或每次 new，必须是静态字段、Spring 单例 Bean 或线程间显式传递的同一个引用
触发扩容的写操作并发执行：至少两个线程同时调用 put()，且当前 size ≥ threshold（如默认容量 16 × 0.75 = 12，第 13 次 put 就可能触发）
被迁移的旧桶中存在长度 ≥2 的链表：例如 key 哈希冲突集中于同一 slot，形成 A→B→null 结构；单节点桶不会成环

核心代码断点位置与观察点

不要等 CPU 拉满再排查，直接在调试中卡住关键路径：

java-enterprise

Java企业开发专家，专注于Spring Boot、微服务架构和JVM优化。适用于：Java语言掌握、

下载

在 transfer() 方法内 while 循环开头设断点：观察 e 和 next 的实时值变化
重点关注 e.next = newTable[i] 这一行执行前后：newTable[i] 原来是谁？e.next 被改成了谁？
当 T1 挂起在 Entry next = e.next 后，T2 完成整条链迁移，此时 newTable[i] 已是 B→A→null；T1 恢复后继续用旧 next（仍是 B），再执行 e.next = newTable[i]，就把 A 的 next 指向了 B，而 B 的 next 原本就指向 A

如何稳定复现（非压测碰运气）

靠调度干预，绕过“看天吃饭”的时序依赖：

用 CountDownLatch 让两个线程精确同步到 transfer 开始前
在第一个线程进入 while 循环、执行完 next = e.next 后，立即 Thread.sleep(100) 挂起它
第二个线程完成整个链表迁移并退出 transfer
唤醒第一个线程，它将用已失效的 next 继续操作，几轮后必现 A↔B 环
验证环：打印 e.key 和 e.next.key，出现重复输出（如 A→B→A→B…）即确认

验证环存在的最简方式

无需 jstack 或 dump，一段代码直击本质：

Entry e = map.get("anyKeyInLoopBucket");
Set seen = new HashSet();
while (e != null && seen.add(e)) {
e = e.next;
}
System.out.println("Detected cycle: " + (e != null));

只要输出 true，说明 next 字段已构成闭环——这是 JVM 堆内存里真实存在的指针环，不是假象。