ConcurrentHashMap的putIfAbsent不是绝对原子，因其仅对key插入做CAS保护，value构造副作用（如new对象）仍会执行；正确做法是用computeIfAbsent延迟构造。
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。
立即学习“Java免费学习笔记（深入）”；
- 不要假设
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。
