ConcurrentHashMap线程安全原理详解

ConcurrentHashMap 专为高并发场景设计，巧妙规避了 HashMap 在多线程下引发的 ConcurrentModificationException、数据丢失和死循环等致命问题，既不像 Collections.synchronizedMap 那样因全局锁导致性能瓶颈，也不依赖粗粒度的“先查后改”逻辑——它通过 JDK 7 的分段锁或 JDK 8+ 的 CAS + 桶级 synchronized 实现细粒度并发控制，支持安全的复合操作（如 computeIfAbsent）、多线程协作扩容，以及弱一致性但不抛异常的遍历能力，是构建高性能、线程安全缓存与共享映射结构的首选方案。

ConcurrentHashMap 解决了 HashMap 的线程不安全问题

直接说结论：ConcurrentHashMap 解决的是多线程环境下对 HashMap 并发读写导致的 ConcurrentModificationException、数据丢失、死循环（JDK 7 及以前）等线程安全问题。它不是简单加锁，而是通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）实现更高并发度的线程安全。

为什么不能直接用 Collections.synchronizedMap 包装 HashMap

Collections.synchronizedMap(new HashMap()) 虽然能保证单个操作原子性，但无法保证复合操作的线程安全，比如 if (!map.containsKey(key)) map.put(key, value) 这种“检查-执行”逻辑仍会出错。而且它的全局锁粒度太粗，高并发下性能差。

• 所有读写都竞争同一把锁，吞吐量随线程数增加迅速下降
• 迭代器不是 fail-safe：遍历时其他线程修改会抛 ConcurrentModificationException
• 不支持并发遍历与更新共存

JDK 8 中 ConcurrentHashMap 的关键设计变化

JDK 8 彻底重构了 ConcurrentHashMap，放弃分段锁（Segment），改用更轻量的机制：

• 底层是数组 + 链表/红黑树，和 HashMap 类似
• 插入/更新使用 CAS 尝试写入头节点；失败后对链表头或红黑树根节点加 synchronized 锁（锁粒度降到单个桶）
• 扩容时支持多线程协作迁移，避免长时间阻塞
• size() 不再是 O(1)，而是累加每个桶的 baseCount 和 CounterCell 数组，精度为估算值（可能滞后）

ConcurrentHashMap map = new ConcurrentHashMap<>();
map.computeIfAbsent("key", k -> expensiveInit(k)); // 线程安全的懒初始化

哪些操作是真正线程安全且推荐使用的

不是所有方法都适合并发场景。以下操作在文档中明确保证原子性与线程安全性：

• putIfAbsent(k, v)、remove(k, v)、replace(k, oldV, newV) —— 带条件的原子更新
• computeIfAbsent(k, mappingFunction) —— 推荐替代“先查后 put”模式
• forEach(action)、reduce(...) 等聚合方法 —— 内部使用弱一致性迭代器，不会抛 ConcurrentModificationException

但要注意：keySet().iterator() 返回的迭代器仍是弱一致的（可能看不到最新写入，也不会报错），不适用于强一致性校验场景。如果业务要求“看到全部已提交变更”，得自己加外部同步或换方案。

好了，本文到此结束，带大家了解了《ConcurrentHashMap线程安全原理详解》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！