jstack排查HashMap并发扩容CPU高问题

本文深入剖析了JDK7中HashMap因并发扩容引发的CPU 100%死循环问题，揭示其根源在于头插法与竞态条件共同导致的链表环（如A↔B互指），并通过jstack精准定位RUNNABLE线程中反复出现的getEntry/transfer栈帧、结合MAT分析heap.hprof确认next字段环形引用，提供了一套从现象识别、线索排查到根因验证的完整诊断路径——既实用又深刻，是Java高并发调优与线上故障排查不可多得的实战指南。

看线程状态，锁定可疑栈帧

死循环发生时，JVM 进程不崩溃、无异常、无日志，但 CPU 持续 100%。此时用 jstack 抓取线程快照，重点筛查处于 RUNNABLE 状态的线程——它们不是在等锁或 I/O，而是在持续执行某段逻辑。

重点关注以下两类栈帧：

• java.util.HashMap.getEntry(...)：说明线程正在遍历链表查找 key，若反复出现 e = e.next 且栈深度异常增长（如几十层甚至上百层），极可能陷入环形链表无限跳转；
• java.util.HashMap.transfer(...)：说明线程正处在扩容迁移阶段，若多个线程同时卡在此处，尤其指向同一 HashMap 实例，说明并发 resize 已触发竞态窗口。

确认是否真为环形链表，而非其他高 CPU 原因

不能仅凭 CPU 高就断定是 HashMap 死循环。需排除 GC 频繁、外部服务阻塞、synchronized 锁竞争等干扰项。

判断环形链表的关键特征有：

• 多个线程堆栈中，e = e.next 出现在连续多帧，且 e 和 e.next 地址反复交替（例如 A→B→A→B…）；
• 相同 HashMap 实例被多个线程同时访问，且调用链集中在 get() 或 put() 的链表遍历路径上；
• 线程长时间停留在同一个方法内，堆栈无明显变化，CPU 时间片持续消耗。

结合堆快照，验证 next 字段互指

jstack 只能提示线索，最终确认需依赖堆内存分析。

执行 jmap -dump:live,format=b,file=heap.hprof 获取堆快照，用 MAT（Eclipse Memory Analyzer）打开后：

• 搜索类 java.util.HashMap$Entry（JDK7）或 java.util.HashMap$Node（JDK8）；
• 按 next 字段值排序，查找是否存在两个 Entry 对象，其 next 字段互指（A.next == B，B.next == A）；
• 进一步检查这两个 Entry 所属的 HashMap 实例是否为同一对象，确认环发生在该 map 的某个桶中。

理解环路成因：头插法 + 竞态时序缺一不可

JDK7 中的环不是随机产生，而是特定执行顺序下的必然结果：

• 旧链表为 A→B→null，T1、T2 同时进入 transfer()，初始都持有 e=A、next=B；
• T1 完成迁移：头插法使新表中变为 B→A→null；
• T2 被挂起后恢复，仍用旧局部变量 e=A、next=B，将 A 插入新表头，再将 B 插入新表头 → A.next = B，B.next = A；
• 环形成后，任何对这个桶的 get() 都会陷入 A↔B 的无限循环。

这个过程依赖精确的线程调度时机和内存可见性缺失，所以压测中常需数百次尝试才能复现一次。

本篇关于《jstack排查HashMap并发扩容CPU高问题》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！