jdk7 hashmap多线程扩容时因头插法导致链表成环，引发get/put无限遍历、cpu 100%；jdk8改用尾插法避免成环，但仍非线程安全。
因为 JDK7 的 HashMap 在多线程并发扩容时，用头插法迁移链表节点，可能形成环形链表；后续 get 或 containsKey 等遍历操作会陷入无限循环，纯 CPU 计算不停歇，导致单核 100% 占用。
头插法 + 多线程竞态 = 链表成环
JDK7 的 transfer() 方法把旧桶中链表逐个“头插”到新数组对应位置。例如原链表是 A → B → null，头插后变成 B → A → null —— 顺序被反转。
当两个线程 T1 和 T2 同时处理同一桶的链表时，若 T1 执行一半被挂起，T2 完成整个迁移并修改了 next 指针，T1 恢复后继续用已失效的局部变量操作，就可能让 A 的 next 指向 B、B 的 next 又指回 A，构成 A ↔ B 环。
- 环一旦形成，
while (e != null) { e = e.next }永远无法退出 - 没有异常、不阻塞、不等待 I/O，纯指针跳转，指令极轻但永不终止
- jstack 中线程状态为 RUNNABLE，堆栈停留在
getEntry或transfer
典型触发条件很具体
不是只要多线程 put 就一定出问题，必须同时满足：
- 多个线程共享同一个 HashMap 实例（如 Spring 单例 Bean）
- 该 Map 初始容量小（如默认 16）、负载因子 0.75 → 插入第 13 个元素就触发首次扩容
- 多个线程几乎同时达到扩容阈值，各自进入
resize() - 被扩容的桶中链表长度 ≥2（否则无节点可“错位链接”）
CPU 满载但系统不报错
这不是内存溢出或锁死，而是计算型死循环：
- 一个线程就能占满一个 CPU 核心；多线程各自成环，整机 CPU 可飙至 100%
- GC 线程照常运行，
jstat -gc显示正常，容易误判为其他问题 - 应用无响应、日志静默、接口超时，重启后暂时恢复，过段时间又复现
JDK8 改了但没完全解决
JDK8 改用尾插法，从机制上避免了环形链表，所以不会死循环。但要注意：
- HashMap 在 JDK8 中仍非线程安全：并发 put 可能丢失数据、覆盖值、size 不准
- 真正高并发场景，必须用
ConcurrentHashMap（JDK8 用 CAS + synchronized 细粒度锁） - 只读多写少可用
Collections.synchronizedMap()，但迭代时仍需手动同步
