为什么JDK7版本的HashMap在多线程扩容时会导致CPU满载
作者:慢热型
时间:2026-06-20
浏览:0
JDK7HashMap多线程扩容因头插法产生环形链表,导致get()死循环和CPU满载。JDK8改用尾插法消除环,但并发仍会丢数据,线程安全需用ConcurrentHashMap。
在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,但迭代时仍需要额外的同步。记住这个原则就行。
本文内容来源于互联网,如有侵权请联系删除。
作者最新文章
CPU硅脂涂抹方法图解及正确操作步骤
2026-09-22 15:23
网易2026年Q2财报:营收301亿元,游戏收入增10%,三款重点新游披露进展
2026-09-08 17:51
PDF怎么添加页码?页码位置和起始页怎么设置?
2026-09-03 09:11
图片文件怎么转换成PDF?多张图片如何按顺序合成?
2026-09-02 19:33
CorelDRAW绘制正弦曲线的两种方法:贝塞尔工具与变形工具
2026-09-02 16:08
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多


































