JDK 8 通过将扩容时的头插法改为尾插法，并引入高低位拆分与红黑树，从机制上消除了多线程扩容导致的环形链表和死循环；但 HashMap 仍非线程安全，并发 put 可能丢失数据或 size 不准。
因为jdk7的hashmap在多线程同时触发扩容时，用头插法迁移链表节点，可能让两个线程交错操作同一段链表，造成a→b→a这样的环形结构；后续get或containskey遍历该链表时，e = e.next永远不为null，陷入纯计算型无限循环，单个线程就能把一个cpu核心跑满。
头插法是成环的直接原因
JDK7的resize()中，transfer()方法对每个桶的链表采用头插方式迁移到新数组：原链表A→B→null，头插后变成B→A→null——顺序被反转。这种“倒着插”的逻辑，在单线程下完全正常；但多线程并发时，它让指针重写变得高度依赖执行时序。
- 线程T1读取e=A、next=B，插入B到新桶，再准备插A
- T1中途被挂起，T2完成整个链表迁移，新桶中已是B→A→null
- T1恢复后，仍用旧的next（B）继续操作，把A的next设为B；而B的next此时已指向A
- 结果：A.next == B 且 B.next == A，环形成
死循环不报错、不阻塞，只吃CPU
环一旦存在，任何对该桶的get()调用都会执行类似这段代码：
for (Entry<K,V> e = table[i]; e != null; e = e.next)由于e永远不为null，循环体持续执行指针跳转和条件判断——没有I/O、没有锁等待、没有异常抛出，指令极轻但永不退出。
- jstack中线程状态始终是RUNNABLE，堆栈反复停留在getEntry或transfer里的e = e.next行
- GC照常运行，jstat -gc无异常，容易误判为外部依赖慢或配置问题
- 接口超时、日志静默、重启后暂时恢复，过一阵又复现
必须同时满足三个硬条件才触发
这不是概率事件，而是特定条件下必然发生的逻辑错误。缺一不可：
- 多个线程共享同一个未同步的HashMap实例（如Spring单例Bean、static字段）
- 多个线程几乎同时达到扩容阈值（例如默认容量16 × 0.75 = 12，第13次put就可能触发）
- 被迁移的旧桶中链表长度≥2（哈希冲突集中，单节点桶不会成环）
JDK8改了什么？为什么还不能当线程安全用？
JDK8把头插改成尾插，迁移过程保持节点相对顺序，从机制上消除了成环可能——get不会再死循环，CPU不再因此满载。
- 但并发put仍可能丢失数据：两个线程同时计算同一位置，后写覆盖前写
- size()返回值可能不准：计数未加同步，读到中间态
- 迭代器仍会fail-fast，不是强一致性保证
真正需要并发读写的场景，必须用ConcurrentHashMap；若只是读多写少，可考虑Collections.synchronizedMap，但迭代时仍需额外同步。
