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<String, Integer> map = new ConcurrentHashMap<>();
map.computeIfAbsent("key", k -> expensiveInit(k)); // 线程安全的懒初始化
哪些操作是真正线程安全且推荐使用的
不是所有方法都适合并发场景。以下操作在文档中明确保证原子性与线程安全性：
立即学习“Java免费学习笔记（深入）”；
-
putIfAbsent(k, v)、remove(k, v)、replace(k, oldV, newV)—— 带条件的原子更新 -
computeIfAbsent(k, mappingFunction)—— 推荐替代“先查后 put”模式 -
forEach(action)、reduce(...)等聚合方法 —— 内部使用弱一致性迭代器，不会抛ConcurrentModificationException
但要注意：keySet().iterator() 返回的迭代器仍是弱一致的（可能看不到最新写入，也不会报错），不适用于强一致性校验场景。如果业务要求“看到全部已提交变更”，得自己加外部同步或换方案。
