putIfAbsent在ConcurrentHashMap中能避免覆盖已存在值，因其基于CAS和锁实现原子性检查与插入；而在HashMap中无原子性保障，多线程下无法防覆盖。
putIfAbsent 为什么能避免覆盖已存在值
putIfAbsent 是 HashMap 的线程不安全版本里**不具备原子性保障**的操作——这点必须先说清楚。它只在单线程下“看起来”能防覆盖，因为它的逻辑是：如果 key 不存在，才 put；否则返回已有 value。但一旦进入多线程环境，putIfAbsent 在 HashMap 中**根本不能用于并发写入防护**，它会和 put 一样触发 ConcurrentModificationException 或数据丢失。
真正能用 putIfAbsent 安全防覆盖的，是线程安全的 ConcurrentHashMap。它的 putIfAbsent 是基于 CAS + synchronized 分段/Node 锁实现的原子操作，能确保「检查是否存在」和「插入新值」两个动作不可分割。
ConcurrentHashMap.putIfAbsent 的正确用法
直接替换你原来用 HashMap 的地方，换成 ConcurrentHashMap，再调用 putIfAbsent：
ConcurrentHashMap<String, String> map = new ConcurrentHashMap<>();
map.putIfAbsent("key1", "default-value"); // 如果 key1 不存在，才设为 "default-value"
常见误用场景和建议：
- 不要在
putIfAbsent返回后，再手动判断是否需要重试或 fallback —— 它的返回值就是“旧值（若存在）”或null（若插入成功），直接用这个返回值做逻辑分支即可 - 注意返回值语义：
putIfAbsent(k, v)返回的是该 key **插入前**的旧值；如果 key 原本不存在，返回null；如果原本存在，返回那个旧值 —— 不是布尔值 - 不要传
null作为 value：ConcurrentHashMap不允许nullvalue，会抛NullPointerException - key 可以为
null吗？不行，ConcurrentHashMap的 key 和 value 都不允许为null
和 computeIfAbsent 比，什么时候该选 putIfAbsent
两者都能防覆盖，但语义和开销不同：
-
putIfAbsent(k, v)是“静态赋值”：v 被立即计算并传入，哪怕 key 已存在，v 也会被构造出来（比如 new 一个对象、调用一次方法） -
computeIfAbsent(k, mappingFunction)是“懒加载”：只有 key 确实不存在时，mappingFunction 才会被调用，适合 v 构造代价高（如 IO、复杂计算）的场景 - 如果你只是存一个常量或轻量对象（如字符串字面量、枚举），
putIfAbsent更直白、无函数对象开销 - 如果你的默认值依赖外部状态或耗资源，优先用
computeIfAbsent
容易踩的坑：看似线程安全，实则漏掉竞态点
即使用了 ConcurrentHashMap.putIfAbsent，仍可能出问题，典型情况是：你只靠它设了一个初始值，但后续逻辑又对这个 value 做了非原子修改。
例如：
ConcurrentHashMap<String, List<String>> map = new ConcurrentHashMap<>();
map.putIfAbsent("tasks", new CopyOnWriteArrayList<>()); // ✅ 原子设初始 list
map.get("tasks").add("job1"); // ❌ 非原子！多个线程同时 add 可能破坏一致性
这种写法的问题在于：putIfAbsent 保证了 key 对应的 value 初始化是线程安全的，但 value 本身（比如 List）不是线程安全容器，后续操作仍需同步或选用线程安全类型（如 CopyOnWriteArrayList、ConcurrentLinkedQueue）。
更隐蔽的坑是复合判断+操作，比如：
if (map.get("counter") == null) {
map.put("counter", 0);
}
map.compute("counter", (k, v) -> v + 1); // ❌ if + put 不是原子的，竞态仍在
这类逻辑必须整体替换成 computeIfAbsent 或 putIfAbsent + 后续原子更新（如用 AtomicInteger 作 value）。
最易被忽略的一点：putIfAbsent 只保护“key 是否存在”这一层，不保护 value 内部状态、不保护跨 key 的业务逻辑一致性 —— 这些得靠更高层设计兜底。
