根本原因是JDK 1.7中transfer()方法采用无同步保护的头插法重排链表，多线程并发扩容时可能使节点A、B互指形成环（如A→B→A），导致get()无限遍历；该问题在JDK 1.8中通过尾插法和红黑树优化消除环形链表风险，但HashMap本身仍非线程安全。
为什么HashMap在JDK 1.7中会死循环
根本原因在于 transfer() 方法里用头插法重排链表，且整个过程没有同步保护。当两个线程同时触发扩容，各自遍历同一条链表（比如 A → B → null），又各自往新数组同一位置头插节点，就可能把 A 和 B 的 next 指针互相指向，形成 A → B → A 的环。
常见错误现象：get() 卡住、CPU 100%、jstack 显示线程长期停留在 getEntry() 或 get() 的 while 循环里；日志里看不到异常，只有无响应。
- 仅在 JDK 1.7 及更早版本复现，JDK 1.8 改为尾插 + 红黑树，
resize()过程不再破坏链表结构，但HashMap本身仍非线程安全，不能用于并发写 - 触发条件苛刻：必须是多线程同时
put触发扩容，且哈希冲突集中在同一桶；测试时需高并发+小初始容量（如new HashMap(2)）才容易复现 - 不是每次都会死循环，但一旦形成环形链表，后续所有对该桶的
get、containsKey都会无限遍历
怎么快速定位是不是HashMap死循环
别等线上爆炸——用工具抓现场最直接。重点看线程堆栈是否卡在 getEntry() 的链表遍历逻辑里，且调用链深度异常大或停滞不动。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 用
jstack <pid></pid>查看线程状态，搜索HashMap.get或getEntry，若多个线程都停在e = e.next这行附近，高度可疑 - 用 Arthas 的
thread -n 5查看最忙线程，再用thread <id></id>看其完整堆栈；配合watch java.util.HashMap get returnObj监控返回行为 - 加 JVM 参数
-XX:+UnlockDiagnosticVMOptions -XX:+PrintConcurrentLocks辅助判断锁竞争，但死循环本身不涉及锁，所以该参数更多用于排除其他问题
替换方案选 ConcurrentHashMap 还是加锁
ConcurrentHashMap 是唯一兼顾安全性与性能的合理选择；Collections.synchronizedMap() 和手动 synchronized 都会让所有操作串行化，吞吐量断崖下跌，只适合读远多于写的极低并发场景。
立即学习“Java免费学习笔记（深入）”；
- JDK 1.8 的
ConcurrentHashMap使用 CAS + synchronized 分段锁（实际是基于Node的 volatile + CAS + 细粒度锁），写操作只锁单个桶，读操作完全无锁 - 注意迁移成本：
ConcurrentHashMap不允许null作为 key 或 value，原有代码若依赖null值，必须提前判空或改用其他策略 - 不要混用：不能把
ConcurrentHashMap当作HashMap直接强转，也不能在已有HashMap引用上“悄悄换实现”，必须从声明、初始化到所有调用点统一替换
为什么JDK 1.8没彻底“修复”死循环问题
它只是让死循环**极难发生**，而非从语义上保证线程安全。扩容逻辑虽改用尾插、避免环形链表，但并发 put 仍可能导致数据覆盖、丢失或 size 不准——这些不是死循环，但仍是严重并发 bug。
-
HashMap的 Javadoc 明确写着 “should not be used in multithreaded environments”，这个立场从 1.2 到 17 都没变 - 即使你用的是 JDK 1.8+，只要存在多个线程对同一个
HashMap实例做put、remove或clear，就属于未定义行为（undefined behavior） - 最容易被忽略的一点：有些框架（如早期 Spring）内部会缓存
HashMap实例供多线程共享，你以为自己没并发写，其实底层已经踩坑
