HashMap 和 ConcurrentHashMap 有什么区别？并发读写为什么不能混用？

知识点详解：线程安全到底保护了哪一段操作

先看两个线程如何把检查结果用错

假设我们用一个共享 Map 缓存用户资料。线程 A、B 都先查询用户 42，结果都发现没有缓存。于是它们各自查询数据库，再各自写回。

即使这两次查询 Map 和两次写入 Map 都是安全的，也不代表「发现没有 → 创建 → 保存」这整个过程只有一个线程执行。中间仍然可以穿插别人的操作。

computeIfAbsent 把按 key 计算缺失值放到容器提供的原子操作里。但计算函数应该简短，不能递归地修改同一个 Map，也不适合塞进长时间阻塞的远程调用。耗时加载还要考虑请求合并、超时和失败缓存。

两个容器的区别不只是一把锁

HashMap 是普通哈希容器，适合不被并发修改的局部数据等场景。迭代时发现结构变化可能抛出异常，但这个机制不是并发正确性的保证，不能靠「没抛异常」证明安全。

ConcurrentHashMap 为并发访问设计。读取通常不需要等待写锁，遍历可以继续进行，但看到的不是整张表在某一个瞬间的完整快照。并发变化时的 size()，也不适合拿来保证「最多只能放入 100 个用户」这种严格约束。

另外，不要把早期 JDK 的分段锁结构当成所有版本的固定实现。面试先讲当前 API 保证；要谈内部结构，再说明具体 JDK 版本和源码。

Map 安全，不会顺便保护 value

假设 key 42 对应一个可变的购物车对象。Map 可以安全地把这个对象引用交给两个线程，但两个线程同时改购物车中的普通列表，列表不会因此获得线程安全。

处理方法取决于状态怎么使用：可以保存不可变对象，每次用原子更新替换；也可以在对象内部同步，或把修改集中到一个拥有者。不能只把外面的 Map 换掉，就宣布里面所有数据都安全。

同样，两个 key 一起更新也不在单 key 原子方法的保证范围内。余额转移等跨记录约束，应该交给明确的锁范围或数据库事务。

选择容器以后，还要验证竞争场景

读多写少不是免除同步的理由。关键是有没有多个线程共享可变状态，以及修改是否会重叠。只在启动阶段构建、之后可靠发布且不再修改的数据，与持续接收写入的缓存不是同一个问题。

测试时可以让两个线程同时到达「检查不存在」的位置，再一起继续，检查是否重复初始化。对于计数或限额，再检查大量竞争后最终值是否正确。压测只看有没有异常，很容易漏掉已经发生的丢失更新。

本题机制参考：JDK 25 HashMap、JDK 25 ConcurrentHashMap。

面试官继续追问

可以用 containsKey 加 put 实现唯一插入吗？

这两个调用之间存在竞争窗口。单 key 唯一插入要使用 putIfAbsent 等合适的原子操作，并检查返回结果。

ConcurrentHashMap 的遍历结果能当一致快照吗？

不能。遍历允许并发更新，可能反映不同时间的状态。需要业务快照时，应另行安排版本、锁或数据复制的边界。

为什么不能存 null？

这样缺失映射与显式 null 不会混在读取结果里，便于并发 API 表达无结果。具体保证以该容器 API 为准，不推广为所有 Map 的限制。

面试速记卡

• HashMap：不提供共享并发修改的同步保证。
• ConcurrentHashMap：访问安全，不等于复合业务原子。
• 同 key 复合修改使用适合的原子方法。
• 多 key 约束和 value 内部状态要另行协调。
• 遍历与 size 不是全表一致快照。