为什么JDK7版本的HashMap在多线程扩容时会导致CPU满载

在Ja va集合框架里，HashMap的线程安全问题是个老生常谈却又常被忽视的坑。JDK 7 版本的多线程扩容容易导致CPU飙满，这个问题既经典又隐蔽。JDK 8 确实通过头插改尾插、引入红黑树等手段解决了环形链表和死循环，但请注意——它依然不是线程安全的容器。并发put可能丢数据，size()也不准，迭代器照样fail-fast。所以真正需要并发读写的地方，还是得请出ConcurrentHashMap。 --- JDK 7 的多线程扩容为什么会让CPU满载？核心原因是头插法在并发场景下产生了环形链表。resize()内部调用的transfer()方法，对每个桶的链表采用头插方式迁移到新数组：原链表A→B→null，头插后变成B→A→null——顺序反转。这种“倒着插”的逻辑，单线程下完全正常；可一旦多线程并发，指针重写就完全依赖执行时序了。 你来看下面这个典型的交错场景： - 线程T1读取了e=A、next=B，正在准备把A插到新桶，然后挂起了。 - 线程T2趁机完成了整个迁移，新桶里已经是B→A→null。 - T1恢复后，还拿着旧的next（B）继续干活：把A的next设置成B，可此时B的next已经指向A。 - 结果：A.next == B 且 B.next == A —— 环就这样形成了。 环一旦存在，任何对该桶的get()或containsKey()调用都会进入一段无限循环： ``` for (Entry e = table[i]; e != null; e = e.next) ``` 因为e永远不为null，循环体持续执行指针跳转和条件判断——没有任何I/O、没有锁等待、没有异常抛出，指令极轻但永不退出。所以CPU会长时间满载，但jstack里线程状态始终是RUNNABLE，堆栈反复卡在getEntry或transfer里的e = e.next那一行。GC照常运行，jstat -gc也无异常，很容易被误判为外部依赖慢或者配置问题。接口超时、日志静默，重启后暂时恢复，过一阵又复现。 当然，这不是概率事件，而是特定条件下必然发生的逻辑错误。需要同时满足三个硬条件才会触发： - 多个线程共享同一个未同步的HashMap实例（比如Spring单例Bean、static字段）。 - 多个线程几乎同时达到扩容阈值（默认容量16×0.75=12，第13次put就可能触发）。 - 被迁移的旧桶中链表长度≥2（哈希冲突集中，单节点桶不会成环）。 缺一不可。 --- 那么JDK 8 改了什么呢？它把头插改成了尾插，迁移过程保持了节点相对顺序，从根本上消除了成环的可能——get不会再死循环，CPU也不会因此满载。但别高兴太早，并发put仍然可能丢失数据：两个线程同时计算同一位置，后写覆盖前写；size()返回值可能不准，因为计数没有加同步；迭代器仍然是fail-fast，不是强一致性保证。 所以，如果要在线程间安全地使用HashMap，无脑选ConcurrentHashMap就对了。如果只是读多写少，也可以考虑Collections.synchronizedMap，但迭代时仍需要额外的同步。记住这个原则就行。