在 Java 语境里，`HashMap` 的线程安全问题本质上分两层：一层是**数据竞争**导致的可见性与丢失更新；另一层是并发结构修改带来的**内部结构不一致**（扩容、链表/树调整过程中被打断）。因此“保证多线程读写安全”不是给 `HashMap` 打补丁，而是按访问模式选用合适的并发策略与容器。 ## 线程不安全的来源：不止“读写冲突” `HashMap` 的核心状态包含 `table` 数组、桶内链表/红黑树结构、`size`、`modCount` 等。并发下常见风险： - **丢失更新**：两个线程同时 `put` 同一键或不同键，最后写入覆盖、`size` 计数不准。 - **可见性问题**：一个线程 `put` 后，另一个线程未必立刻在 `get` 中看到（缺少 happens-before 关系）。 - **结构竞争**：扩容（rehash）、桶内节点插入/移动如果被另一个线程同时修改，可能出现链断、指针错乱等结构不一致。JDK 8 之后实现细节改变，但“并发修改导致行为不确定”这一点不变。 - **迭代不可靠**：`HashMap` 迭代器是 fail-fast（基于 `modCount`），并发修改通常抛 `ConcurrentModificationException`，更关键的是即使不抛，也不提供一致性保证。结论是：只要存在并发写，或读需要符合特定一致性语义，`HashMap` 就不应直接暴露在多线程下使用。 ## 方案一：读多写少，用外部锁把 `HashMap` 变成串行临界区最朴素也最可控：对同一把锁内的所有访问（读与写）进行互斥。 - 适用：写很少、容量不大、读也允许被写阻塞；需要强一致（读到的就是最新写入）。 - 实现要点： - 锁对象必须是同一个，且保护所有对 map 的访问路径（包括迭代）。 - 迭代时要么在锁内完成，要么复制快照再迭代。示例： ```java final Map map = new HashMap<>(); final Object lock = new Object(); V get(K k) { synchronized (lock) { return map.get(k); } } void put(K k, V v) { synchronized (lock) { map.put(k, v); } } ``` 这种方式的语义清晰：锁内形成 happens-before，结构安全与可见性一起解决；代价是并发度低。 ## 方案二：用 `Collections.synchronizedMap` 快速“加壳” `Collections.synchronizedMap(new HashMap<>())` 本质也是外部锁，只是把锁逻辑封装到返回的包装对象里。 - 适用：快速改造遗留代码；并发度要求不高。 - 关键陷阱：**复合操作仍需手动同步**，迭代也必须在外部同步块内完成。 ```java Map m = Collections.synchronizedMap(new HashMap<>()); synchronized (m) { // 迭代必须这么做 for (var e : m.entrySet()) { /* ... */ } } ``` “加壳”不等于自动修复所有竞态，尤其是 `if (absent) put` 这类 check-then-act。 ## 方案三：高并发读写，直接换 `ConcurrentHashMap` 并发场景的标准解：`ConcurrentHashMap`（CHM）。它通过分段/桶级别的控制（JDK 8 以后主要是 CAS + 桶内局部同步）提升并发度，读在多数路径上无锁。 - 适用：读写都频繁；希望高吞吐；能接受弱一致遍历（迭代不抛 CME，但可能看见并发更新的部分结果）。 - 语义特点： - 单次 `get/put` 是线程安全的。 - 复合操作应使用原子方法：`computeIfAbsent`、`putIfAbsent`、`compute`、`merge` 等，避免竞态窗口。 - 不允许 `null` 键与 `null` 值（用以消除歧义并简化并发语义）。示例（典型的“并发加载缓存”）： ```java ConcurrentHashMap cache = new ConcurrentHashMap<>(); V v = cache.computeIfAbsent(k, key -> load(key)); ``` 这类原子 API 等价于把“查+建+放”压缩成一个受控的临界区，避免重复加载与覆盖。 ## 方案四：读极多、写较少，用 `ReadWriteLock` 提升读并发当读远大于写且希望读并发，`ReentrantReadWriteLock` 可以让多个读线程并行，写线程独占。 - 适用：读占绝对多数、写较少但不能丢；数据结构仍是 `HashMap`，但希望读不互斥。 - 注意点： - 读锁保护所有读取路径，写锁保护所有写入路径。 - 复合读写升级（读锁升级为写锁）容易踩死锁/饥饿边界，通常需要释放读锁再抢写锁。骨架如下： ```java final Map map = new HashMap<>(); final ReentrantReadWriteLock rw = new ReentrantReadWriteLock(); V get(K k) { rw.readLock().lock(); try { return map.get(k); } finally { rw.readLock().unlock(); } } void put(K k, V v) { rw.writeLock().lock(); try { map.put(k, v); } finally { rw.writeLock().unlock(); } } ``` 在写并不稀少时，读写锁的管理开销与写阻塞会抵消收益，此时 CHM 往往更合适。 ## 方案五：写一次读多次，用不可变与发布（immutable + safe publication）如果是配置、字典表这类“构建完成后只读”，最稳的做法是**构建阶段单线程**，构建完成后用安全发布手段暴露一个不可变视图。 - 适用：初始化后不再修改，或以“整体替换”方式更新。 - 手段： - 用 `final` 引用发布（构造完成后不再变）。 - 或用 `volatile` 引用进行“整表替换”，读线程永远读到某一版完整快照。示例（整表替换）： ```java volatile Map dict = Map.of(); // 或 Collections.unmodifiableMap void reload() { Map m = new HashMap<>(); // 单线程填充 m dict = Collections.unmodifiableMap(m); // 原子替换引用 } V get(K k) { return dict.get(k); } ``` 这种模型把并发写变成“单点发布”，读路径没有锁，语义清晰。 ## 常见误区与校验点 - 只把 `HashMap` 引用设为 `volatile` 不够：`volatile` 仅保证引用可见，不保证 map 内部结构在并发写下安全。 - 只在写时加锁、读不加锁不够：没有 happens-before，读可能看到中间态或旧值；扩容/结构调整时风险更大。 - 用 `ConcurrentHashMap` 但仍写 `get` 后 `put`：会引入竞态窗口，应换成 `computeIfAbsent/merge` 等原子复合方法。 - 迭代语义要先定：需要强一致遍历（看到一个时刻的全量视图）时，外部锁快照或不可变快照更可靠；CHM 的迭代是弱一致。 ## 选型速记（按访问模式） - 强一致 + 并发度不要求：`synchronized`/`Collections.synchronizedMap` - 高并发读写：`ConcurrentHashMap` + 原子方法（`compute/merge`） - 读远多于写且仍要用 `HashMap`：`ReadWriteLock` - 初始化后只读或整表替换：不可变快照 + 安全发布（`final/volatile` 引用）以上策略的共同点是：用明确的同步原语或并发容器为访问路径建立 happens-before，并避免在 `HashMap` 内部结构变动时发生并发交错。

1 个回答