Java中CAS操作：putIfAbsent与compute用法解析

本文深入剖析了Java中ConcurrentHashMap的CAS相关操作，重点揭示了putIfAbsent并非“绝对原子”的本质原因——它仅保障key插入的线程安全，却无法抑制value构造过程中的副作用（如对象创建、IO或外部调用），从而导致资源浪费甚至逻辑错误；文章明确指出computeIfAbsent才是实现“查无则建”语义的正确选择，因其将查找、计算与插入三步压缩至同一哈希桶内原子执行，并强调compute系列方法的安全边界在于map结构一致性而非函数体内部逻辑，提醒开发者警惕共享状态修改、null值约束、性能阻塞及跨JVM兼容性等隐性陷阱，最终回归并发设计的核心：精准界定需保护的临界区，避免用碎片化操作拼凑本应由单一原子方法承载的读-算-写闭环。

ConcurrentHashMap 的 putIfAbsent 为什么不是“绝对原子”？

它只对单个 key 的插入做 CAS 保护，但如果你的 value 构造本身有副作用（比如 new 对象、IO、调用外部方法），那整个逻辑就不是原子的。常见错误是写成：map.putIfAbsent(key, new ExpensiveObject())——即使 key 已存在，ExpensiveObject 也会被构造一次。

• 正确做法：把构造逻辑包进 computeIfAbsent，它只在 key 确实不存在时才执行 mappingFunction
• 注意 putIfAbsent 返回的是旧值（可能为 null），不是是否插入成功的布尔值；别用返回值 == null 来判断“我这次插入成功了”，因为旧值本身就可能是 null
• 如果 value 是 null，putIfAbsent 会直接抛 NullPointerException，这点和 HashMap 不同

compute 和 computeIfPresent 的线程安全边界在哪？

它们都保证：对同一个 key，多个并发调用不会导致 map 内部结构损坏，也不会让 value 被覆盖丢失。但函数体（remappingFunction）本身不被同步——也就是说，如果函数里修改了外部共享状态，仍需额外同步。

• compute(key, (k, v) -> v == null ? "default" : v + "!") 是安全的；但 compute(key, (k, v) -> { counter++; return v; }) 中的 counter++ 不是线程安全的
• computeIfPresent 只在 key 存在且 value 非 null 时触发函数；如果 value 是 null，它什么也不做，也不会删除 key
• 所有 compute 类方法在函数返回 null 时，都会尝试删除该 key（前提是 key 原本存在），这个删除动作是原子的

什么时候该用 computeIfAbsent 而不是 get + putIfAbsent？

当你需要“查无则建”，且构建 value 成本高、或可能失败时。computeIfAbsent 把查+建+存三步锁在同一个哈希桶内，避免重复计算；而手写 get + putIfAbsent 至少两次哈希查找，还可能因中间态竞争导致多次构造。

• 典型场景：缓存初始化、单例工厂、连接池中按 key 懒创建资源
• 参数中的 mappingFunction 不能返回 null（否则抛 NPE），也不能抛受检异常；如需异常处理，得在函数体内 try-catch 并转为运行时异常或默认值
• 如果 mappingFunction 执行很慢，会阻塞同一桶内其他 key 的写操作（ConcurrentHashMap 分段锁粒度是 hash 桶，不是 key），这是容易被忽略的性能坑

所有 CAS 类更新方法共有的兼容性陷阱

Java 8 引入的这些方法（putIfAbsent、remove(key, value)、replace(key, oldValue, newValue)）底层依赖 Unsafe.compareAndSwapObject，但某些 JVM（尤其是老版本 Android ART 或某些嵌入式 JDK）可能未完整实现，导致行为不一致或直接 UnsupportedOperationException。

• 不要假设 replace(key, null, "x") 能清空 null 值——它要求 oldValue 必须精确等于当前值，而 null == null 为 true，所以这行代码其实是“如果当前值是 null，就替换成 x”，不是“如果 key 存在就替换”
• 在 Java 7 及更早版本中，这些方法根本不存在，编译会报错；如果项目需兼容，必须降级用 ConcurrentHashMap 外加显式 synchronized 或 ReentrantLock
• 所有方法都不支持 value 为 null，这是 ConcurrentHashMap 的硬约束，和 Hashtable 或 Collections.synchronizedMap 不同

真正难的不是记住哪个方法名该用，而是想清楚“我要保护的临界区到底包含哪些操作”——是单次写？还是读-算-写闭环？后者几乎总是要选 compute 系方法，而不是拼凑 get+putIfAbsent。

以上就是《Java中CAS操作：putIfAbsent与compute用法解析》的详细内容，更多关于的资料请关注golang学习网公众号！