为什么JDK7版本的HashMap在多线程扩容时会导致CPU满载
作者:慢热型
时间:2026-06-20
浏览:3
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,但迭代时仍需要额外的同步。记住这个原则就行。
本站声明:本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系bd@zhengruan.com
作者最新文章
漫蛙官网线路更新提醒了吗
2026-10-13 13:42
漫蛙漫画登录入口免费漫画在线看最新版本
2026-10-13 13:18
漫蛙漫画入口如何找
2026-10-13 13:17
win10笔记本外出联网如何阻止自动下载更新包
2026-10-08 18:21
photoshop智能对象不能直接编辑
2026-10-05 13:52
热门文章
更多
精品专题
更多
Mac软件
更多
WINDOWS
更多










































