putifabsent能避免竞态，因其是单次cas操作，而非containskey+put的两次独立操作；它仅对单key生效，不保证value构造无副作用，大开销场景应改用computeifabsent。
putIfAbsent 为什么能避免“先查后写”的竞态
多线程下用 containsKey + put 判断并插入，本质是两次独立操作：线程 A 查完 key 不存在，还没来得及 put，线程 B 就已插入成功——结果两个线程都执行了 put，违背预期。而 putIfAbsent 是单次 CAS 操作：它在定位到数组桶（tabAt）后，直接尝试用 CAS 写入新节点，失败则重试，整个过程不依赖外部状态判断。
注意三点：
-
putIfAbsent返回值是旧值（如果存在）或新值（如果插入成功），不能只看返回null就认为插入成功——要检查是否真的写入了 - 该方法仅对单个 key 生效，不适用于需同时更新多个 key 的场景
- 如果 value 构造开销大（比如要 new 一个对象），别在参数里直接构造，应改用
computeIfAbsent
computeIfAbsent 和 compute 是更安全的原子计算入口
当 value 需要基于 key 动态计算（如初始化缓存、构建对象），putIfAbsent 容易因重复构造导致浪费；而 computeIfAbsent 保证函数只在 key 确实不存在时才调用一次，且整个“查→算→写”是原子的。
示例场景：加载用户配置，避免多次 IO 或网络请求
configMap.computeIfAbsent(userId, id -> loadFromDatabase(id));
关键细节：
- 函数
mappingFunction必须是无副作用的纯函数，否则并发调用可能触发多次执行（虽然最终只有一个生效） - 若函数抛出异常，本次操作失败，key 不会被插入，也不会影响其他线程
-
compute和computeIfPresent同理，但分别适用于“总是计算”和“仅存在时计算”两种语义
跨多个 ConcurrentHashMap 的更新无法靠单个 map 保证原子性
如果你有 m1 和 m2 两个 ConcurrentHashMap，想让 m1.put(k, v) 和 m2.put(k, v) 要么都成功、要么都不生效——这是典型的分布式事务问题，ConcurrentHashMap 本身不提供跨实例原子性。
常见误操作：
- 对两个 map 加同一把锁：违反“不要在 concurrent 实例上同步”的警告，且锁粒度粗，性能差
- 用
synchronized(this)包裹：仍无法防止其他代码路径绕过该同步块修改 map
可行替代方案：
- 合并为一个 map，value 类型为自定义容器（如
Pair<v1 v2></v1>），用putIfAbsent或compute原子更新整个结构 - 引入外部协调机制（如数据库事务、Redis Lua 脚本），但会脱离纯内存操作范畴
- 接受最终一致性，用事件驱动方式异步补偿（例如监听 m1 更新后发消息触发 m2 更新）
size() 和 containsValue 不适合做条件判断依据
很多同学想用 map.size() == 0 或 !map.containsValue(v) 来控制逻辑分支，这在并发下极不可靠。
原因很直接：
-
size()是估算值，JDK 8 中通过 baseCount + counterCells 数组 CAS 累加，高并发下可能滞后于真实状态 -
containsValue()需遍历所有 segment / node，过程中其他线程可能正修改，结果既不实时也不一致 - 这两个方法都不是原子操作，不能作为 if 条件的安全依据
真正需要“是否存在某个值”的场景，应该反向建模：用值作 key，或维护额外的倒排索引 map（同样用 putIfAbsent 维护）。
最常被忽略的一点：ConcurrentHashMap 的“原子性”始终限定在单个 key 的单个操作内。一旦涉及多个 key、多个 map、或读写混合的复杂逻辑，就必须跳出“靠一个方法解决”的思维，转而设计符合业务语义的协作协议。
