17370845950

ConcurrentHashMap 通过分段锁（JDK 7）或 CAS + synchronized（JDK 8+）解决 HashMap 的线程不安全问题，支持高并发读写，避免 ConcurrentModificationException、数据丢失和死循环。

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