putIfAbsent能避免覆盖已存在值是因为它仅在key对应value为null时才写入新值，否则直接返回旧值；它判断的是value是否为null而非key是否存在，故key→null时仍会写入。
putIfAbsent 为什么能避免覆盖已存在值
putIfAbsent 是 ConcurrentHashMap 和 Java 8+ 中 HashMap 等实现的默认方法，它只在 key 对应的 value 为 null 时才写入新值；如果 key 已存在且 value 非 null，就直接返回旧值，不触发任何赋值操作。这和 put 的“无条件覆盖”有本质区别。
注意：它判断的是「当前 value 是否为 null」，不是「key 是否存在」——所以如果 map 中存了 key → null，putIfAbsent 仍会写入新值，这常被误认为“失效”。
什么时候该用 putIfAbsent 而不是 put
典型场景是「首次初始化」「懒加载缓存」「多线程下安全设默认值」。比如：
- 缓存中查不到用户配置，就加载并存入，但不能覆盖别人刚写入的有效配置
- 并发请求同时初始化某个单例 bean，只允许第一个成功写入
- 统计计数器初始化：
map.putIfAbsent("error_404", new AtomicInteger(0))
如果只是单线程、且明确要覆盖旧值，用 put 更直白；强行用 putIfAbsent 反而让逻辑变绕，还可能掩盖 bug（比如你本以为 key 不存在，结果发现它存了个 null）。
常见踩坑：null 值导致意外写入
这是最常被忽略的一点：putIfAbsent 不关心 key 是否存在，只看 value 是否为 null。下面这段代码看似安全，实则危险：
map.put("user_123", null); // 误存 null
map.putIfAbsent("user_123", loadUserFromDB()); // 依然会执行 loadUserFromDB() 并写入！
解决办法分情况：
- 业务上禁止存
null值 → 初始化时用Objects.requireNonNull(value)拦住 - 需要区分「未初始化」和「显式置空」→ 改用
Optional<T>或自定义占位对象（如UNINITIALIZED） - 必须支持 null → 改用
computeIfAbsent配合显式检查：map.computeIfAbsent(key, k -> existsInDB(k) ? loadFromDB(k) : null)
并发环境下 putIfAbsent 的原子性保障
ConcurrentHashMap.putIfAbsent 是原子的，适合多线程竞争场景；但 HashMap.putIfAbsent（继承自 AbstractMap）只是普通同步逻辑，**不保证线程安全**，在并发写时可能丢失更新或抛 ConcurrentModificationException。
所以务必确认实际类型：
- 用
new ConcurrentHashMap<>()或ConcurrentHashMap.newKeySet() - 不要把
HashMap强转成ConcurrentHashMap—— 编译通过但运行时行为完全不同 - Spring 的
@Cacheable底层若用ConcurrentMap，其putIfAbsent才真正起效
真正容易被忽略的，是「你以为用了线程安全 Map，其实被某处包装类或代理悄悄替换了实现」——建议在关键路径加日志或断点，确认 map.getClass() 输出的是 ConcurrentHashMap。
