ConcurrentHashMap复合操作原子性深度解析：线程安全不等于原子

1. 先搞清楚：你问的"复合操作"到底是哪一类？

先说结论，免得你等不及：ConcurrentHashMap 对"单个方法"是原子性的，但对"先读后写、先查后改"这一类复合操作，默认不保证原子性。但这话又不绝对，因为 ConcurrentHashMap 里有一部分方法本身就是复合操作，比如putIfAbsent、remove(key, value)、replace，这些方法在内部实现上又是原子性的。所以问题的关键不在"ConcurrentHashMap 是不是线程安全"，而在于你到底把哪几步操作当成一个整体。

我在实际项目里见过太多人踩这个坑：看到 ConcurrentHashMap 就说"线程安全"，然后直接写：

if (map.containsKey(key)) { map.put(key, value); }

这代码放在多线程环境里，线上就会偶发出问题。查日志查半天，发现每个线程单独看逻辑都对，但合在一起就是会出现重复覆盖、数据丢失。原因很简单：containsKey 是一步，put 是另一步，两步之间其他线程完全可以插进来。ConcurrentHashMap 只能保证它提供的每个方法内部是原子的，但它没有办法替你把这跨方法的两步操作"焊死"成一个原子操作。

那怎么办？不是让你放弃 ConcurrentHashMap，而是你得搞清楚它的原子性边界到底在哪里。这篇我打算从源码实现角度拆一遍，再结合缓存、计数器、分布式锁这些真实场景，把"复合操作原子性"这件事彻底聊透。

2. 从 JDK 8 的源码设计看并发模型：为什么单步操作是安全的

2.1 锁粒度进化：从分段锁到 CAS + synchronized

聊原子性之前，得先明白 ConcurrentHashMap 凭什么能保证单步操作原子。JDK 7 时代它用的是分段锁（Segment），把整个 Map 分成 16 段，每段一把锁，不同的 key 落在不同的段上就能并行写。JDK 8 之后改成了CAS + synchronized 锁桶，锁粒度进一步缩小到单个哈希桶（bin），并发能力比 JDK 7 强不少。

所谓 CAS，就是compareAndSwap，翻译成人话就是："如果内存里的值现在还是我预想的那个旧值，就把它替换成新值；如果不是，就什么都不做，返回失败。"这是个 CPU 级别的原子操作，不需要加锁。ConcurrentHashMap 在写入链表头节点、更新size计数这些场景里大量用了 CAS，所以很多单步操作根本不需要锁就能保证原子性。

而 synchronized 锁桶发生在什么时候？当多个线程同时往同一个哈希桶里写，CAS 竞争失败的时候。比如两个线程同时往同一个链表里追加节点，光靠 CAS 不够，因为链表结构变更涉及多个指针的联动，所以 Java 8 的实现是：先用 CAS 往空桶里放头节点，成功就完事；如果桶里已经有节点了，那就对桶的头节点加 synchronized 锁，锁住之后再操作链表。

这设计最巧妙的地方是：并发高的场景（同一个桶竞争）才加锁，并发低的场景（不同桶或空桶）CAS 搞定，锁的粒度控制在最小。很多人问"JDK 8 的 ConcurrentHashMap 还分段吗"，答案是：不再分段了，但原理上比分段更精细。

2.2 为什么 ConcurrentHashMap 的读操作不需要加锁

ConcurrentHashMap 的get方法是完全不加锁的，这是它读性能高的根本原因。它靠的是 volatile 修饰的Node数组和Node节点的val、next字段。volatile 的含义是：一个线程对 volatile 变量的修改，对其他线程是立即可见的（happens-before 关系）。也就是说，当你往 map 里 put 一个 key 时，即使没加锁，其他线程的 get 也能立刻看到这次修改（前提是没有正在扩容之类的中断状态）。

这里有个关键点值得展开：volatile 保证的是可见性，不保证复合操作的原子性。get方法本身只有一步"读取某个 key 对应的 value"，这自然没问题；但如果你在 get 之后紧接着做别的判断、再做别的写操作，volatile 就管不了这么远了。

另外要提醒你一个细节：ConcurrentHashMap 的 get 不允许返回 null 的原因是它内部用 null 来标记"节点正在移动"等特殊状态。所以当你调用map.get(key)返回 null 时，有可能是 key 确实不存在，也有可能是节点正处于 resize 的中间状态。设计者干脆规定：不允许存入 null 键和 null 值，这样 get 返回 null 就统一表示"没找到"，避免了歧义。很多新手在"同时读写报 null"的问题上栽跟头，就是因为往 ConcurrentHashMap 里放了 null 值。

2.3 size() 为什么是个"估算值"

size()方法的原子性也经常让人误解。它返回的是当前 map 的元素个数吗？严格说，是"某一瞬间的近似值"。JDK 8 的实现里，size()会先尝试不加锁地统计每个桶的节点数，加上一个baseCount的 CAS 计数；如果竞争激烈导致统计结果不稳定，它还会用CounterCell数组来分散计数压力。

也就是说，ConcurrentHashMap 的 size() 不是一个快照，更不是一种强一致的数量。官方注释里直接说了"may be inaccurate"。这跟HashMap的size()语义差别很大，不过在某些场景下这个差异无所谓（比如统计缓存总量、展示个大概数量），但在需要精确计数的场景就必须小心：你不能靠if (map.size() == 0)来判断"容器空了，该做初始化了"，因为这个判断在多线程环境下可能看到的是一个漂移的中间值。

3. 复合操作原子性的分水岭：到底哪些操作是安全的

现在进入正题。我把 ConcurrentHashMap 的常用操作分成四类，分别说明原子性边界。建议你收藏这张表，写完代码之后对着自查。

表格里最值得展开的是第三行和第五行。

3.1 putIfAbsent/remove/replace 为什么是原子的

putIfAbsent最简单，语义是"如果 key 不存在，就放进 value 并返回 null；如果 key 已存在，就返回已有 value，不修改"。它内部调用的是putVal方法，传入参数onlyIfAbsent = true。在putVal的实现里，当发现 key 对应的桶已有时，会遍历链表/红黑树查找节点；找到节点后，在锁内判断onlyIfAbsent，为 true 就不覆盖。整个过程是在锁桶之后完成的，所以从"检查 key 是否存在"到"决定是否写入"之间，没有其他线程插足的空间。这就是原子性。

remove(key, value)就更典型了：它要求"只有当 key 对应的 value 等于你传入的那个 value 时才删掉"，这本质上是一个"读取旧值 + 比较 + 删除"的复合操作。如果是你自己先 get 再判断再 remove，中间绝对会被其他线程打断；但 ConcurrentHashMap 把这个三合一封装成了单个方法，内部实现是：进入锁桶后，遍历找到节点，比对值，相等才删除。于是这个"读改写"链条被锁保护了，成为原子操作。

replace(key, oldValue, newValue)跟remove(key, value)原理一样，也是"CAS 语义"的封装。

这里才是真正的坑点：别人提供的原子方法你不用，偏要自己先 get 再判断。我见过不少代码是这么写的：

if (map.get(key) == null) { map.put(key, value); }

这个逻辑等价于"不存在才放"，但它是非原子的，因为 get 和 put 之间可能有另一个线程先 put 了相同 key，然后你的 put 把它覆盖掉了（虽然 value 可能一样，但对象引用、时间戳等细节会有差异）。正确姿势应该直接写：

map.putIfAbsent(key, value);

又简洁又安全。

3.2 computeIfAbsent 的"读改写"闭环

computeIfAbsent是 JDK 8 加入的，语义是："如果 key 不存在，就用传入的 Function 计算出一个值，放进去并返回；如果 key 已存在，直接返回已有值。"它内部实现是：在锁桶之后，先查链表/树，没有找到节点时，才调用 Function，然后创建新节点插入链表。也就是说，整个"判断不存在 + 计算 + 写入"的过程，是在同一把锁内完成的，不会被其他线程打断。

这方法特别适合做缓存初始化的场景。比如我之前做一个本地缓存模块，每秒有几百个线程同时请求同一个 key 的初始化数据，如果用"先 get 再 put"，会出现大量重复计算；用computeIfAbsent就能保证同一个 key 只有第一个线程执行加载逻辑，其余线程直接拿到结果。不过要注意两点：

第一，Function内部不能再操作同一个 ConcurrentHashMap，否则可能死锁或者产生难以理解的递归行为。官网没有明确说这是禁忌，但实际测试中，computeIfAbsent里回调函数再次调用compute或put同一个 map 时，在 JDK 8 某些版本会抛出IllegalStateException: Recursive update，从 JDK 9 开始也依然有递归边界限制。稳妥的做法是：回调函数里只管加载外部数据，绝不碰当前 map。

第二，它的原子性不等于"同步执行锁外逻辑"。如果 Function 里做网络请求、数据库查询这种耗时操作，那这把锁会一直持有，同一个桶的其他写操作都会被阻塞。所以千万别在computeIfAbsent里做重量级 IO，否则就是拿并发容器的名义干串行化的活。

4. 安全性完全依赖方法选型？不，还要看你的使用边界

有些人看完上一节，可能觉得"那我全用 computeIfAbsent、merge 不就完事了？"没那么简单。复合操作的范围远不止"读改写单个 key"。下面我拆几个真实场景，每个场景都有对应的安全和不安全写法。

4.1 场景一：高频计数器

需求：多线程累加某个 key 的计数，例如统计每个用户 ID 的请求次数。新手很容易写成：

Integer count = map.get(userId); if (count == null) { map.put(userId, 1); } else { map.put(userId, count + 1); }

这个写法的非原子性很明显：两个线程同时读到count = 10，同时 put 11，结果丢失一次累加。正确解法有几种：

• 用compute：

map.compute(userId, (k, v) -> v == null ? 1 : v + 1);

• 用merge（更简洁）：

map.merge(userId, 1, Integer::sum);

• 或者用LongAdder作为 value：

map.computeIfAbsent(userId, k -> new LongAdder()).increment();

第三种方案我比较推荐在高并发计数的场景用，因为Integer是不可变对象，每次累加都要替换整个对象引用，CAS 竞争激烈时 CPU 开销不小；LongAdder内部做了分片累加，性能更稳。

4.2 场景二：缓存击穿防护

做本地缓存时经常要处理"key 不存在则加载"的逻辑，有个经典错误是双重检查锁（DCL）写法：

if (map.get(key) == null) { synchronized (lock) { if (map.get(key) == null) { Value v = loadFromDB(key); map.put(key, v); } } }

这个 DCL 在 HashMap 上是对的（配合锁），但在 ConcurrentHashMap 上就属于多余的锁。直接computeIfAbsent搞定，锁粒度还更细（只锁对应桶，不锁整个 lock 对象）：

Value v = map.computeIfAbsent(key, k -> loadFromDB(k));

这里有个关于computeIfAbsent的隐藏细节：如果loadFromDB返回 null，那么computeIfAbsent会认为"没有值可放"，并且不会为这个 key 创建映射。也就是说，当你的数据源确实可能返回 null 时，要特别小心——它会变成"每次都执行加载逻辑"，也就是缓存永远填不上。处理办法是包装一个Optional或者约定"加载不到就返回一个空对象占位"。

4.3 场景三：先检查后执行的权限/状态判断

有这样一个业务场景：只有 key 不存在时才允许执行某个操作（比如幂等控制、订单防重）。业务代码可能是：

if (!orderMap.containsKey(orderId)) { orderMap.put(orderId, processing); // 执行业务逻辑 }

这个代码在多线程下会出大问题：两个线程同时执行containsKey都返回 false，然后都进入业务逻辑，导致订单被处理两次。正确做法是：

Object prev = orderMap.putIfAbsent(orderId, processing); if (prev == null) { // 只有当前线程抢到了初始化权，才执行业务逻辑 }

putIfAbsent返回 null 表示"之前没有值，我放成功了"，返回非 null 表示"之前已经有值，其他线程抢了先"。利用返回值来判断"谁抢到了锁"，是高并发场景里很常用的套路。

4.4 场景四：批量读取后统计

还有一种更隐蔽的复合操作：多个 key 之间需要保持一致。比如"转账"场景：A 账户扣款，B 账户加款。这在 ConcurrentHashMap 的场景里属于跨键事务，任何单键原子方法都解决不了。即使分别用compute对 A 和 B 做原子更新，也没办法保证"A 扣款成功的同时 B 加款一定成功"，中间一旦有异常，A 扣了 B 没加。这种情况下要么用数据库事务，要么用分布式事务框架，要么自己实现补偿机制。ConcurrentHashMap 的原子性是单键级别的，不是事务级别的。

这个边界必须想清楚，否则你会在架构选型时犯大错。

5. 怎么正确实现复合操作？四套实用方案

如果你遇到的场景确实是复合操作且需要强一致，我给你几套方案，按复杂度从低到高排列。

5.1 方案一：优先找现成的"原子型复合方法"

这是性价比最高的方案。把需求翻译成putIfAbsent、remove(key, value)、replace(key, old, new)、compute、merge、computeIfAbsent、computeIfPresent这类方法，尽量不自己拼凑。这里的关键能力是识别你的需求等价于哪个标准方法：

我在实际项目中总结的经验是：90% 的单 key 复合操作，都能在这张表里找到对应方法。如果你发现自己要写好几行 if-else 才能实现，大概率是方法选型没到位。

5.2 方案二：自旋重试 + CAS 思想

有些复杂操作无法用现成方法表达，但可以借鉴 CAS 的自旋思路。原理是：循环里读取当前值，计算新值，然后尝试用replace(k, old, new)原子地更新；如果更新失败，说明期间有其他线程修改了这个 key，重新读取再来一次。示例：

while (true) { Integer oldVal = map.get(key); Integer newVal = oldVal == null ? 1 : oldVal + 1; if (oldVal == null) { if (map.putIfAbsent(key, newVal) == null) { break; } } else if (map.replace(key, oldVal, newVal)) { break; } // 失败则继续循环，重新读取 }

这个写法把"读改写"变成了"乐观锁重试"：先乐观地假设没人改，失败再重来。优点是并发粒度极细，没有长时间持锁；缺点是写竞争激烈时循环次数会增加，CPU 会有点忙。一般单 key 冲突不严重时完全没问题。

5.3 方案三：外部锁隔离

如果复合操作涉及多个步骤，且中间步骤不能被其他线程打断（例如先校验再写入还要做日志记录），可以用外部锁把整个步骤包起来：

synchronized (lockObject) { if (map.containsKey(key)) { // ... } map.put(key, newValue); // 其他步骤 }

但要注意，这里锁的保护范围必须和所有操作该 key 的代码路径保持一致。如果有的地方用synchronized(lockObject)，有的地方又直接用map.put，那就等于没锁。锁不完整 = 没有锁，这是并发编程最常见的人也最容易犯的错。

5.4 方案四：用 Striped Lock 做细粒度锁

如果你对性能有要求，不想用一把大锁锁所有 key，可以按 key 的哈希值分散锁对象。比如用 Guava 的Striped：

Striped<Lock> locks = Striped.lazyWeakLock(1024); Lock lock = locks.get(key); lock.lock(); try { // 复合操作 } finally { lock.unlock(); }

原理和 ConcurrentHashMap JDK 7 的 Segment 类似：1024 把锁，按 key 哈希映射到其中一把，不同 key 大概率落在不同锁上，互不干扰；同一 key 永远落在同一把锁上，所以对同一个 key 的复合操作是串行的。这种方式比较适合"复合操作很复杂、用现成方法表达不了、但又不想全局串行"的场景。

5.5 方案五：不要用 ConcurrentHashMap 去硬扛强一致事务

最后必须强调：如果你的复合操作跨越多个 key、多个容器，甚至多个服务，ConcurrentHashMap 本身无法给你事务保证。这时候选型应该是数据库、分布式事务中间件，或者提前设计好状态机、对账补偿机制。把并发容器当数据库用，是很多分布式事故的根源。

6. 常见并发陷阱排查实录：看上去安全，实际上翻车

这一节我整理几个实战中高频踩坑的案例，每个都有人付过学费。

6.1 陷阱一：containsKey + put 的老套路

症状：偶发数据覆盖，线下测不出来，线上压测必现。排查方法：在代码里加日志打印线程名和 put 前后的旧值，会发现两个线程同时进入 put 分支。根治方案：替换为putIfAbsent或computeIfAbsent。

6.2 陷阱二：get 之后做非原子判断，忘记 null 的可能

比如：

Object obj = map.get(key); if (obj != null) { // 执行业务逻辑 }

这个逻辑本身没问题，但如果后面紧跟的是map.remove(key)或者map.replace(key, obj, newObj)，就埋雷了。因为obj可能是别的线程修改前的旧引用，等你在旧引用上做判断、再想更新时，map 里的值已经变了。正确做法是用replace(key, obj, newObj)的返回值来判断是否替换成功，而不是先 get 再替换。

6.3 陷阱三：往 ConcurrentHashMap 里放 null 导致异常

报错信息一般是NullPointerException或看起来像"没有找到 value"的奇怪现象。ConcurrentHashMap不允许 null 键和 null 值，这是设计使然。尤其在"同时读写报 null"的热搜词里就藏这这个坑。我记得有一次排查线上问题，发现某条数据写入时 value 是 null，put直接抛 NPE，但外层 catch 把异常吞了，导致数据一直写不进去。凡是用 ConcurrentHashMap 的地方，都要对数据源做 null 过滤。

6.4 陷阱四：迭代 ConcurrentHashMap 时误以为弱一致性是强一致

ConcurrentHashMap的迭代器是弱一致的：迭代过程中，其他线程对 map 的修改，迭代器不保证能看到，也不保证会抛ConcurrentModificationException。这跟HashMap的fail-fast迭代器完全不同。很多人据此写"全量扫描 + 删除"的功能：

for (Map.Entry<String, Integer> entry : map.entrySet()) { if (entry.getValue() < threshold) { map.remove(entry.getKey()); } }

这代码不会抛异常，但删除操作是并发进行的，可能漏删。如果要求"快照式遍历 + 精确删除"，正确做法是先把要删的 key 收集到列表里，遍历结束后再批量 remove；或者直接用map.entrySet().removeIf(...)，JDK 8 的removeIf内部是按桶加锁遍历删除的，安全性好很多。

6.5 陷阱五：size() 判断触发错误

需求：缓存容量达到上限时清理。代码：

if (map.size() > MAX_SIZE) { map.clear(); }

size()是估算值，clear()之后其他线程可能正好又放入了新的元素，这逻辑本身就是非原子的。如果真要限量，建议用CacheBuilder之类的带容量控制的缓存组件，或者自己做 Striped Lock 的复合控制，别指望 map.size() 能当信号量用。

6.6 陷阱六：compute 回调里抛异常导致映射被删除

computeIfPresent的回调如果返回 null，key 会被移除；如果回调抛异常，映射关系会保持原样（不更新也不删除）。很多人的预期是"抛异常就回滚到初始状态"，这在单步操作下确实是回滚了，但在复合操作里容易产生不一致。比如回调里先更新了外部数据，再抛异常，map 里虽然是旧值，外部数据库已经是新值了。不要在 compute 回调函数里做有副作用的操作，这是铁律。

7. 从实际项目出发：给复合操作场景设计的经验清单

聊完了原理和误区，最后给一套我在项目里常用的设计决策清单，看到具体需求时可以直接按这个顺序做判断。

第一层判断：这个复合操作只涉及一个 key 吗？

• 是，继续看能不能用现成的原子方法表达；不能，用自旋 + replace。
• 否，直接考虑外部锁、Striped Lock、或者干脆改数据库/分布式锁。

第二层判断：这个操作对强一致要求高吗？

• 高（幂等、防重、扣款、订单状态流转）：必须用原子方法或完整锁。
• 低（统计、缓存、日志聚合）：可以用 ConcurrentHashMap 自带方法，容忍弱一致。

第三层判断：这个操作内部有没有 IO 操作？

• 有网络/DB IO：别在 compute 里做，也别在锁内做，否则并发能力瞬间归零。正确做法是先加载数据到局部变量，再用 putIfAbsent 或 compute 做最终写入。
• 没有 IO：随便用 compute 系列。

第四层判断：这个操作会被高频调用吗？

• 高频且单 key 竞争激烈：考虑 LongAdder 值对象、Striped Lock、或者降低锁粒度。
• 低频：直接用最简单可靠的方案，别过度设计。

这套清单基本覆盖了我遇到过的九十多个并发业务场景。你可以把它贴到项目文档里，作为代码审查时的自查项。

8. 踩坑总结与个人体会

最后说点实在的。我在写高并发代码的早期，也犯过"用 ConcurrentHashMap 就以为万事大吉"的错误，直到线上出现了一次幂等控制失效的 P0 事故。那次事故的根因就是：代码里先containsKey再put，两个线程同时进来，导致同一笔订单被处理了两次。从那以后，我给自己定了一条铁律：只要看到一个复合操作需要多行代码才能完成，就必须停下来问自己——有没有现成的并发原语或者原子方法能表达这个逻辑？大多数时候答案是有，只是你没去查文档。

再分享一个小技巧：排查并发代码时，可以在关键复合操作前后加版本号或时间戳，打印到日志里，线上对照日志看时间窗口。你会发现很多"偶发问题"其实都发生在两个操作之间那几毫秒的时间缝隙里——这就是并发问题的本质：不是某一行的错，而是"行与行之间的缝隙"出了错。

ConcurrentHashMap 是一把好用的钥匙，但你要清楚它开的锁是哪一把。复合操作原子性问题没有一刀切的答案，需要按方案选型、按场景决策。把上面的分类逻辑和实践清单吃透，再多线程场景都不会再被"它到底原子吗"这个问题绊住。