真实面经题目 · 原创解析
保证 Map 线程安全的核心是先明确并发语义：是只要单次 get/put 安全，还是复合操作也要原子；是允许弱一致迭代，还是必须看到稳定快照；是读多写少、写多读少，还是配置类读多且整体替换。常见方案包括外部加锁、Collections.synchronizedMap、ConcurrentHashMap、不可变 Map、读写锁和快照/COW。面试中不能只说“用 ConcurrentHashMap”，还要说明它解决了什么、不解决什么，以及复合操作、迭代一致性、内存可见性和选型边界。
可以从需求出发回答：普通 HashMap 本身不是线程安全的，并发读写可能出现数据竞争、覆盖更新、结构不一致、可见性问题，甚至在扩容和链表树化等结构变化时出现不可预期行为。保证线程安全有几类办法：第一，最直接是用 synchronized 或 ReentrantLock 在外部统一保护所有访问，包括 get、put、remove、遍历和先判断再插入这类复合逻辑，这样语义最清晰，但并发度低。第二，可以用 Collections.synchronizedMap，它本质是给每个方法加同一把互斥锁，适合简单场景，但遍历和复合操作仍然要手动对这个 map 加锁。第三，高并发读写通常选 ConcurrentHashMap，它内部通过 CAS、volatile 和分段或桶级别控制减少锁竞争，单次操作线程安全，并提供 putIfAbsent、compute、merge 这类原子复合方法；但它的迭代器是弱一致的，不保证遍历期间看到严格快照，也不支持 null key/value。第四，如果数据初始化后不变，用不可变 Map 最简单，配合安全发布可以天然线程安全；如果配置偶尔更新，可以构造新 Map 后用 volatile 引用或 AtomicReference 整体替换。第五，读多写少且需要比较强的一致性时，可以用 ReadWriteLock 或 StampedLock 包住普通 Map，读操作共享锁，写操作独占锁，但所有访问都必须走同一套锁。最后，选型要看并发量、读写比例、是否有复合原子性、是否要求遍历一致性和是否能接受拷贝成本。
Map 的线程安全不是一个单点问题。单次 put/get 不抛异常只是最低要求，真正要确认的是：多个线程同时修改时是否会丢更新；读线程是否必须马上看到写线程结果；遍历时是否允许看到部分新旧数据；containsKey 后 put 这种复合操作是否要整体原子；size、isEmpty 是否要强一致。不同答案对应不同实现，不能脱离业务语义直接说某一个类一定最好。
HashMap 没有为并发读写提供同步保证。多个线程同时 put、remove、resize 时，内部数组、链表、红黑树和计数状态可能被交错修改，导致数据覆盖、读取到旧值、结构状态不一致、遍历异常等问题。即使只是一个线程写、多个线程读，如果没有 happens-before 关系，读线程也不一定及时看到写入结果。因此 HashMap 可以在局部变量、线程内私有数据、构建后不再修改且安全发布的场景使用，但不能直接暴露给多线程并发读写。
最通用的方案是在所有访问 Map 的地方使用同一把锁，例如 synchronized、ReentrantLock 或业务对象自身的锁。它的优点是语义强：不仅单次 get/put 安全，遍历、批量修改、先查再改、多字段联动等复合逻辑也能放进同一个临界区保证原子性和可见性。缺点是锁粒度粗，所有读写串行化，高并发下吞吐量差；同时要求工程纪律很强，任何绕过锁直接访问底层 Map 的代码都会破坏安全性。
Collections.synchronizedMap 是一个同步包装器，对每个公开方法使用同一把互斥锁保护，适合改造成本低、并发不高、操作简单的场景。它解决的是单个方法调用的互斥和可见性问题，不自动解决复合操作原子性。例如 containsKey 后 put 仍然是两个方法调用，中间可能被其他线程插入；遍历时也必须手动对返回的同步 Map 对象加锁，否则迭代期间其他线程修改仍可能导致异常或不一致结果。
ConcurrentHashMap 是高并发场景最常用的选择。它让不同 key 或不同桶上的操作尽量并行，读操作通常不需要全局锁，写操作也尽量缩小锁范围，并通过 volatile、CAS 和必要的锁保证内部状态一致。它提供 putIfAbsent、replace、compute、computeIfAbsent、merge 等原子方法，用于替代常见的先查再改。但它不是万能锁：跨多个 key 的事务性更新、遍历期间的强快照、多个 Map 之间的一致性，都不由它自动保证。
如果 Map 构建完成后不再修改，不可变 Map 是最简单、最稳定的线程安全方案。可以使用 Map.of、Map.copyOf 或其他不可变集合实现，前提是 Map 引用被安全发布，例如通过 final 字段、类初始化、volatile 引用或受锁保护的发布路径。不可变只保证容器结构不变，如果 value 本身是可变对象，还要考虑 value 内部状态的线程安全。配置表、路由表、字典表这类读多且更新少的数据，常用构建新 Map 后整体替换引用的方式避免读路径加锁。
当读多写少、又需要比 ConcurrentHashMap 遍历更强的一致性时，可以用 ReadWriteLock 或 StampedLock 保护普通 Map。多个读线程可以同时持有读锁，写线程持有写锁时排斥所有读写，从而在遍历、批量读取、size 与内容联动判断等场景获得稳定视图。边界是实现复杂度更高，锁升级容易出错，写操作频繁时读写锁收益会下降，且必须保证所有访问路径都按规则加锁。
对于读极多、写极少、且读操作希望完全无锁或看到稳定版本的场景，可以使用快照或 Copy-On-Write 思路：写入时复制旧 Map，修改副本，然后通过 volatile 或 AtomicReference 发布新 Map。读线程始终读取某一个完整版本，不会被写线程中途干扰。它非常适合配置、规则、白名单、元数据缓存等小到中等规模数据；不适合写频繁或 Map 很大的场景，因为每次写入的复制成本和内存峰值都比较高。
面试中最容易漏的是复合操作。线程安全 Map 只能保证它承诺范围内的操作安全，不能自动让多步业务逻辑原子化。比如 if (!map.containsKey(k)) map.put(k, v) 在 synchronizedMap 和外部没有额外锁的场景下都可能竞态；在 ConcurrentHashMap 中应该用 putIfAbsent 或 computeIfAbsent。涉及多个 key、先读 A 再改 B、同时更新 Map 和数据库状态等逻辑，通常还需要外部锁、事务或更高层的并发控制。
不同 Map 的遍历语义差别很大。HashMap 在并发修改下没有安全保证；synchronizedMap 遍历时要手动持有同一把锁，才能防止遍历期间被修改；ConcurrentHashMap 的迭代器是弱一致的，遍历不会因为并发修改轻易失败，但也不保证看到遍历开始那一刻的完整快照；快照式不可变 Map 则能让读线程看到稳定版本。是否允许弱一致，取决于业务是做监控统计、缓存扫描，还是做结算、权限、配置发布这类强一致逻辑。
不能完全替代。ConcurrentHashMap 在高并发单 key 操作和常见原子更新上更适合，吞吐量通常更好，也提供弱一致迭代。但 synchronizedMap 的语义更接近所有方法同一把锁串行化，如果你需要把多个操作和遍历都放在同一把锁下获得强一致视图，synchronizedMap 或外部锁反而更直接。ConcurrentHashMap 不支持 null key 和 null value，也不保证遍历是某一时刻的快照，所以是否替代要看一致性需求，而不是只看性能。
因为这是两个独立操作，中间没有原子边界。线程 A 判断 key 不存在后，还没来得及 put，线程 B 也可能判断不存在并 put，最后 A 再 put 会覆盖 B，或者两个线程都执行了本应只执行一次的初始化逻辑。即使用的是单方法线程安全的 Map，也只能保证每个方法内部安全，不能保证两个方法组合安全。ConcurrentHashMap 中应该用 putIfAbsent 或 computeIfAbsent；如果初始化逻辑还涉及其他资源，就要考虑外部锁或幂等设计。
弱一致表示迭代过程中允许其他线程并发修改，迭代器不会像 fail-fast 迭代器那样依赖修改计数快速失败，但它也不承诺返回遍历开始时的精确快照。它可能看到部分新插入的数据，也可能看不到某些并发更新，整体只保证遍历过程内部结构安全、不会因为并发修改破坏容器。这个语义适合缓存扫描、统计、监控等容忍近似结果的场景，不适合要求严格一致的业务计算。
不可变 Map 的关键是构造完成后容器结构不再变化，因此多个线程读取同一个稳定对象不会发生写写或读写竞争。再配合安全发布，其他线程能够看到构造完成的状态，就可以无锁读取。需要注意两个边界：第一，不可变的是 Map 结构，如果 value 是可变对象，value 自己仍然可能不安全；第二，如果要更新配置，通常不是原地改旧 Map，而是构造一个新不可变 Map，再用 volatile 引用或 AtomicReference 一次性替换。
如果读多写少，并且读操作需要稳定一致视图，例如一次遍历期间不能被写入打断，读写锁保护 HashMap 是合理选择。多个读可以并发，写独占，语义比较强。但如果主要是大量独立 key 的 get、put、remove，并不要求遍历快照，ConcurrentHashMap 通常更简单、吞吐更好。读写锁的风险是所有访问都必须遵守锁规则，锁升级和长时间持锁也容易带来性能或死锁问题。
只能保证一部分。volatile Map 引用可以保证引用替换对其他线程可见，适合构造新 Map 后整体替换的快照模式。如果多个线程拿到同一个普通 HashMap 后继续原地 put、remove，volatile 并不能保护 HashMap 内部结构，也不能保证复合操作原子。简单说，volatile 适合发布不可变版本，不适合让可变 HashMap 并发修改变安全。
Map 容器层面的安全不等于 value 内部安全。ConcurrentHashMap 可以保证 key 到 value 引用的映射关系在并发访问下是安全的，但如果 value 是 ArrayList、HashSet 或普通可变对象，多个线程同时修改 value 仍然会有数据竞争。解决方式包括使用不可变 value，每次更新时替换新对象；使用线程安全的 value 类型；或者通过 compute、merge 等方法把读取旧值和生成新值放进 Map 对某个 key 的原子更新逻辑里。
