真实面经题目 · 原创解析
Map 本身只是键值存储抽象，是否线程安全取决于具体实现和访问方式。普通 HashMap 在并发读写下不安全，可能出现数据丢失、结构破坏、读到不一致状态等问题。保证线程安全通常有几类方案：用外部锁保护所有访问、使用 Collections.synchronizedMap 包装、使用 ConcurrentHashMap、在读多写少场景使用不可变快照或 CopyOnWrite 思路。实际回答时要结合读写比例、是否需要复合操作原子性、是否需要强一致迭代、性能和内存成本来选型。
可以从三个层次回答。第一，HashMap 不是线程安全的。它的 put、resize、链表或红黑树结构调整都没有同步保护，并发修改时可能导致覆盖写入、丢失更新、读到中间状态，甚至在旧版本实现中扩容时可能形成异常链表结构。因此只要存在并发写，就不能直接使用普通 HashMap。第二，常见安全方案要按场景选。最简单的是外部锁，例如 synchronized 或 ReentrantReadWriteLock 包住所有访问，优点是语义清楚，适合需要多个操作组成一个原子事务的场景，缺点是并发度低。Collections.synchronizedMap 是对 Map 方法加互斥锁的包装，单个方法调用是线程安全的，但复合操作仍然需要额外同步，迭代时也要手动在同一把锁内保护。更常用的是 ConcurrentHashMap，它针对并发访问设计，读操作大多无锁，写操作通常只锁局部桶或使用 CAS，扩容也做了并发协作，吞吐量通常明显好于整表加锁。第三，还要补充边界。ConcurrentHashMap 的单个 put、remove、get 是线程安全的，但“先判断再插入”这类复合逻辑不能用 containsKey + put 拆开写，应使用 putIfAbsent、computeIfAbsent、compute、merge 等原子方法。ConcurrentHashMap 的迭代器是弱一致的，不会抛 ConcurrentModificationException，但不保证看到遍历期间所有最新修改。如果读多写少，并且能接受更新通过整体替换发布，可以使用不可变 Map 快照、volatile 或 AtomicReference 持有新快照，或者 CopyOnWrite 思路，以牺牲写入成本和内存换取无锁读。最终选择取决于一致性要求和性能取舍：高并发通用场景优先 ConcurrentHashMap，复合事务用外部锁，不频繁更新的配置类数据用不可变快照。
HashMap 的内部结构维护不是原子操作，并发 put、remove、resize 时没有互斥保护。多个线程同时修改同一个桶、同时触发扩容、同时更新 size 或链表节点，都可能产生丢失更新、覆盖写、结构不一致、读到旧值或中间状态等问题。因此线程安全问题不是单纯的可见性问题，还包括原子性和内部结构一致性问题。
如果只是少量并发访问，可以用外部锁或 Collections.synchronizedMap，把所有访问串行化，简单但吞吐量有限。如果是高并发读写，通常使用 ConcurrentHashMap，它通过更细粒度的并发控制降低锁竞争，读多场景性能更好。如果数据更新很少、读取非常频繁，可以用不可变快照或 CopyOnWrite 思路，读线程始终读稳定版本，写线程构造新 Map 后一次性发布。
线程安全容器只能保证它定义的单个操作安全，不自动保证业务上的多步逻辑安全。例如 containsKey 后再 put 之间可能被其他线程插入，仍然有竞态。需要使用 ConcurrentHashMap 的 putIfAbsent、computeIfAbsent、compute、merge 等原子方法，或者在外部用同一把锁包住整段业务逻辑。
Collections.synchronizedMap 的迭代不是自动线程安全的，遍历期间需要手动持有包装对象的锁，否则可能出现并发修改异常或不一致结果。ConcurrentHashMap 的迭代器是弱一致的，遍历时不会因为并发修改直接失败，但也不承诺反映遍历期间的所有更新。若业务需要遍历期间的强一致快照，应复制一份快照或使用不可变快照方案。
整表加锁方案实现简单、一致性强，但并发度最低。ConcurrentHashMap 适合大多数高并发读写场景，但不能替代所有业务级事务锁。不可变快照和 CopyOnWrite 读性能优秀，读路径简单稳定，但写入需要复制数据，适合配置、路由表、规则表等写少读多数据，不适合频繁写入的大 Map。
不能。ConcurrentHashMap 吞吐量通常更好，但它的迭代是弱一致的，也不自动保证业务多步操作的事务性。如果需要把多个操作作为一个不可分割的整体，外部锁或更高层的并发控制仍然必要。
因为两个方法调用之间存在时间窗口。线程 A 判断 key 不存在后，线程 B 可能已经插入同一个 key，线程 A 再 put 就会覆盖或造成重复初始化。应使用 putIfAbsent 或 computeIfAbsent 让检查和插入成为一个原子操作。
通常不需要。它的实现通过 volatile、CAS、局部同步等机制保证并发可见性和结构安全，读操作大多可以无锁完成。但这只保证容器层面的读取安全，不代表读到的 value 对象内部状态也一定线程安全。
不保证。它提供弱一致遍历，可能看到遍历开始前或遍历过程中一部分更新，也可能看不到部分并发更新。它的优势是遍历不会因为并发修改而失败，适合对精确快照要求不高的场景。
不可变快照让读线程始终访问一个稳定 Map，不需要加锁，也不会读到被修改到一半的结构。写线程构造新 Map 后一次性替换引用，发布新版本。代价是每次写入可能复制较多数据，并产生额外内存压力。
Hashtable 基本是整表方法级同步，所有读写竞争同一把锁，并发性能差。ConcurrentHashMap 使用更细粒度的并发控制，读写冲突更少，适合高并发场景。
