JDK7 HashMap多线程扩容为何CPU满载？

在Java集合框架里，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的改进与局限 JDK 8把头插改成了尾插，迁移过程保持了节点相对顺序，从根本上消除了成环的可能——get不会再死循环，CPU也不会因此满载。但别高兴太早，并发put仍然可能丢失数据：两个线程同时计算同一位置，后写覆盖前写；size()返回值可能不准，因为计数没有加同步；迭代器仍然是fail-fast，不是强一致性保证。 ## 正确选择线程安全的Map 如果要在线程间安全地使用HashMap，无脑选用ConcurrentHashMap即可。如果只是读多写少，也可以考虑Collections.synchronizedMap，但迭代时仍需要额外的同步。记住这个原则就行。