HashMap线程不安全原因详解

HashMap 的线程不安全性远不止“偶尔丢数据”那么简单——它源于底层操作的非原子性、JDK 1.7 中扩容引发的致命死循环、迭代时脆弱的 fail-fast 机制，以及读写间缺失的内存可见性保障；即使升级到 JDK 1.8，问题也只是从显性的 CPU 爆满转向更难排查的脏读、漏读与 size 估算失真。ConcurrentHashMap 虽为首选替代方案，却并非银弹：它提供高性能的桶级并发控制和无锁读，但默认弱一致性意味着你可能读不到最新写入、遍历时看不到全部元素，甚至 size() 都只是近似值。真正安全的并发编程，不在于换一个“听起来安全”的类，而在于理解每种数据结构的同步契约，并在业务强一致性需求下主动补足锁或原子计数等保障机制。

put操作非原子性导致数据覆盖

多个线程同时对同一个 key 调用 put，极大概率丢失数据——这不是偶发bug，而是设计使然。因为 putVal 方法中“检查 key 是否存在”和“插入新节点”是两个独立步骤，中间没有任何同步机制。

• 线程A读取桶位置为空，准备插入；此时CPU切换到线程B，B完成插入并更新 size
• 线程A恢复后，仍按“空桶”逻辑插入，直接覆盖B写入的值
• 即使key不同，若哈希冲突落在同一桶，链表头插（JDK 1.7）或尾插（JDK 1.8）过程中的指针重赋值也可能被并发打断

扩容（resize）引发死循环（JDK 1.7特有）

JDK 1.7 的 resize 使用头插法迁移链表，多线程并发执行时，两个线程反复反转同一链表，极易形成环形链表。一旦形成，后续任意线程调用 get 遍历该桶，就会陷入无限循环，CPU飙升到100%。

• 该问题在 JDK 1.8 中已通过改用尾插法规避，但不等于线程安全了——只是把最危险的死循环换成了更隐蔽的数据不一致
• 即便JDK 1.8，多线程同时触发扩容仍会导致部分线程的扩容结果被丢弃，table 数组更新丢失，新增元素“消失”

迭代时修改触发ConcurrentModificationException

这是最容易被观察到的线程不安全表现：一个线程正在用 entrySet().iterator() 遍历，另一个线程执行 put 或 remove，几乎必然抛出 ConcurrentModificationException。

• 根本原因是 modCount 变量未被 volatile 修饰，且迭代器只做简单计数校验，不提供同步保障
• 这个异常不是“保护机制”，而是 fail-fast 的事后报错——它不阻止并发修改发生，只在检测到不一致时中断
• 注意：即使没抛异常，也可能返回脏读、漏读或重复数据（尤其在扩容中途被读）

正确替代方案怎么选？ConcurrentHashMap不是万能解药

别再用 synchronized(new HashMap()) 或 Hashtable——前者锁粒度太粗，后者已被官方标记为遗留类，性能差且不支持 null 键值。

• ConcurrentHashMap 是首选：JDK 1.8 后取消分段锁（Segment），改用 synchronized + CAS 控制桶级锁，读操作完全无锁，写操作仅锁单个桶
• 若需强一致性（如遍历时要求看到全部已提交修改），ConcurrentHashMap 的弱一致性语义可能不够——此时应考虑加业务层锁，或改用 CopyOnWriteMap（仅适用于读远多于写的极低频写场景）
• 切记：ConcurrentHashMap 的 size() 方法返回的是估算值，高并发下可能不准；如需精确计数，得配合 LongAdder 等原子计数器

真正容易被忽略的点是：哪怕你只用 get，只要其他线程在并发 put 或扩容，就可能读到过期值或 null（尤其在 JDK 1.7/1.8 初期版本）。线程安全从来不是“某个方法安全”，而是整个操作序列的可见性与原子性保障。

到这里，我们也就讲完了《HashMap线程不安全原因详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！