jdk 7 hashmap扩容时因头插法并发操作导致环形链表而死循环；jdk 8改用尾插法避免该问题，但仍非线程安全；多线程应首选concurrenthashmap。
HashMap 在多线程环境下扩容时可能引发死循环，根本原因是其 非线程安全的扩容机制 —— 特别是 JDK 7 中采用头插法（header insertion）迁移链表节点，在并发扩容时可能形成环形链表，导致 get() 或 put() 操作无限遍历而 CPU 占用飙升。
为什么 JDK 7 的 HashMap 扩容会死循环？
JDK 7 的 resize() 过程中，对每个桶（bucket）中的链表节点，使用头插方式插入到新数组对应位置。若两个线程同时触发扩容，且操作同一桶的链表，就可能因执行顺序交错，使节点 A → B → C 变成 A → B → C → A，构成环形链表。
后续调用 get(key) 时，遍历该链表会陷入无限循环（while (e != null) { ... e = e.next }），无法终止。
JDK 8 已修复该问题，但不等于线程安全
JDK 8 改为尾插法（tail insertion），并引入红黑树优化，从根源上避免了环形链表的产生。即使并发扩容，也不会出现死循环。
但注意：HashMap 在 JDK 8 中依然不是线程安全的 —— 并发 put 可能导致数据覆盖、丢失或 size 不准确，只是不会死循环而已。
多线程场景下正确的替代方案
- 优先使用 ConcurrentHashMap：JDK 7 使用分段锁（Segment），JDK 8 改为 CAS + synchronized 细粒度锁，支持高并发读写，语义与 HashMap 兼容，是标准答案。
- 读多写少时可考虑 Collections.synchronizedMap()：底层加了全局锁，简单但吞吐量低，适合低并发或仅需简单同步的场景。
- 若必须用 HashMap，确保单线程初始化 + 只读访问：例如用 static final + 构造后不再修改，配合 Collections.unmodifiableMap() 封装。
- 避免在多线程中手动触发扩容：如提前预估容量（initialCapacity = (int)(expectedSize / 0.75f) + 1），减少 resize 次数，降低并发风险。
如何快速识别是否已发生死循环？
应用出现以下现象时应高度怀疑：
- CPU 占用持续 100%，线程堆栈中大量线程卡在 HashMap.getEntry() 或 getNode() 的 while 循环内；
- jstack 输出中看到多个线程停留在类似 at java.util.HashMap.getEntry(HashMap.java:464) 且 next 字段循环引用；
- 应用无响应，但 GC 正常，内存未溢出。
