putIfAbsent能避免覆盖已有数据，因为它仅在key不存在或对应value为null时才插入新值，且是原子操作；但HashMap版非线程安全，多线程须用ConcurrentHashMap，并确保value非null以防误判。
putIfAbsent 为什么能避免覆盖已有数据
putIfAbsent 是 HashMap（以及所有实现 ConcurrentMap 的类）提供的原子操作：仅当 key 不存在或对应 value 为 null 时，才插入新值；否则直接返回当前已存在的 value，不执行写入。这比先 get 再 put 的手动判断更安全——后者在多线程下存在竞态窗口，可能被其他线程覆盖。
常见误用：null 值导致意外覆盖
如果业务中允许 value 为 null，putIfAbsent 就不可靠：它会把 null 当作“不存在”，从而错误地写入新值。例如：
map.putIfAbsent("order-123", null); // 若原值是 null，也会被替换！
解决办法取决于业务语义：
- 禁止 value 为
null，统一用特殊对象（如Optional.empty()或自定义占位符）表示“无值” - 改用
computeIfAbsent+ 明确的计算逻辑，避免依赖 null 判断 - 对关键业务场景，用
ConcurrentHashMap配合putIfAbsent，但确保 value 永远非 null
和 put + if 判断对比：性能与线程安全差异
手写判断看似直观，但隐患明显：
if (!map.containsKey(key)) {<br> map.put(key, value); // 竞态：两线程同时通过 if，都执行 put<br>}
putIfAbsent 底层由 JVM 或并发容器保证原子性，无需额外同步。注意：
-
HashMap的putIfAbsent本身**不是线程安全的**，仅适用于单线程或外部加锁场景 - 多线程下必须用
ConcurrentHashMap，它的putIfAbsent才真正原子 - 即使单线程，也别为了“看起来清晰”而放弃
putIfAbsent——少一次get调用，性能略优
真实业务场景示例：订单幂等注册
比如支付系统中，一个订单号只能绑定一个支付流水 ID，重复请求应返回已有 ID：
ConcurrentHashMap<String, String> orderToPayId = new ConcurrentHashMap<>();<br>// 收到新请求<br>String orderId = "ORD-789";<br>String newPayId = "PAY-456";<br><br>String actualPayId = orderToPayId.putIfAbsent(orderId, newPayId);<br>if (actualPayId == null) {<br> // 成功注册，actualPayId 是 newPayId<br>} else {<br> // 已存在，actualPayId 是之前注册的 payId，直接返回<br>}
这里必须用 ConcurrentHashMap，且 value 不能为 null——否则 putIfAbsent 返回 null 无法区分“首次注册成功”和“查到 null 值后强行覆盖”。
最常被忽略的是 value 的 null 容忍度和容器类型选择：用错类或允许 null，putIfAbsent 就从防护变成漏洞。
