JDK7 HashMap多线程扩容死循环是确定性逻辑错误：头插法+竞态条件+内存可见性缺失导致A→B→A环形链表，使get()无限遍历、CPU 100%且线程状态始终RUNNABLE。
这是因为 JDK7 的 HashMap 扩容采用头插法，在多线程同时触发 resize() 时，因竞态条件和内存可见性缺失，导致链表节点指针错乱、形成闭环——后续任何 get() 或 containsKey() 都会陷入无限遍历，纯计算型循环不抛异常、不阻塞、不等待，单个线程就能把一个 CPU 核心占满。
死循环不是“卡顿”，而是确定性的指针成环
它不是随机性能抖动，而是在特定时序下必然发生的逻辑错误：
- 两个线程 T1、T2 同时对同一个桶（bucket）中长度 ≥2 的链表（如 A→B→null）执行迁移
- T1 执行
Entry<K,V> next = e.next（拿到 B）后被挂起 - T2 完成整个迁移：因头插法，新表中该桶变成 B→A→null
- T1 恢复，用旧的
next（仍是 B）继续执行e.next = newTable[i]，把 A 的 next 指向 B；而 B 的 next 原本就指向 A → 形成 A↔B 环
为什么 jstack 能一眼识别？
线程状态始终为 RUNNABLE，栈帧反复出现在：
-
java.util.HashMap.getEntry(HashMap.java:...)中的for (Entry<K,V> e = table[i]; e != null; e = e.next) -
java.util.HashMap.transfer(HashMap.java:...)中的while (e != null) { ... e = e.next }
若多个线程长时间停留在同一行、且调用链中持续出现 e = e.next，基本可断定已入环。
复现关键不在“并发数量”，而在三个硬条件
缺一不可，否则永远看不到环：
- 共享未同步的 HashMap 实例（如 static 字段、Spring 单例 Bean）
- 至少两个线程几乎同时触发扩容（例如默认容量 16 × 0.75 = 12，第 13 次 put 就可能触发）
- 被迁移的旧桶中存在 ≥2 节点的链表（哈希冲突集中，不能是单节点桶）
验证环存在的最简方式
无需 dump 或 jstack，一段代码直击本质：
Entry<K,V> e = map.get("任意一个落在环内桶的 key");
Set<Entry> seen = new HashSet<>();
while (e != null && seen.add(e)) {
e = e.next;
}
System.out.println("Detected cycle: " + (e != null)); // 输出 true 即确认成环
只要输出 true，说明 JVM 堆里真实存在 next 字段闭环——这不是假象，是内存中实实在在的指针环。
