Java 7 HashMap多线程扩容死循环是确定性逻辑错误，由头插法、竞态条件和内存可见性缺失共同导致链表成环；复现需同时满足：全局共享未同步实例、并发put触发resize、且被迁移桶中链表长度≥2。
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 拉满再排查，直接在调试中卡住关键路径：
- 在 transfer() 方法内 while 循环开头设断点：观察 e 和 next 的实时值变化
- 重点关注 e.next = newTable[i] 这一行执行前后：newTable[i] 原来是谁？e.next 被改成了谁？
- 当 T1 挂起在 Entry<K,V> next = e.next 后，T2 完成整条链迁移，此时 newTable[i] 已是 B→A→null；T1 恢复后继续用旧 next（仍是 B），再执行 e.next = newTable[i]，就把 A 的 next 指向了 B，而 B 的 next 原本就指向 A
如何稳定复现（非压测碰运气）
靠调度干预，绕过“看天吃饭”的时序依赖：
立即学习“Java免费学习笔记（深入）”；
- 用 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<K,V> e = map.get("anyKeyInLoopBucket");Set<Entry> seen = new HashSet<>();
while (e != null && seen.add(e)) {
e = e.next;
}
System.out.println("Detected cycle: " + (e != null));
只要输出 true，说明 next 字段已构成闭环——这是 JVM 堆内存里真实存在的指针环，不是假象。
