computeIfAbsent 是 Java 8 引入的救命函数——它能帮你省掉 90% 的 if (!map.containsKey(key)) map.put(key, new Value()) 模板代码，且线程安全（在 ConcurrentHashMap 中）。
为什么不用先 get 再判 null？
手动判空再 put 看似直观，但有三处硬伤：
- 非原子操作：多线程下可能重复初始化（比如两个线程同时发现 key 不存在，都执行 new Value()）
- 冗余判断：
get查一次，put又查一次，哈希计算和桶遍历白费 - 代码膨胀：尤其当
Value构造成本高（如 new HashMap(), parse JSON）时，逻辑被弱智 if 包裹得看不清重点
computeIfAbsent 的参数到底怎么填？
签名是 V computeIfAbsent(K key, Function super K, ? extends V> mappingFunction)，关键在第二参数：
-
mappingFunction是懒执行的：只在 key 不存在时才调用，且只调用一次 - 函数接收的是
key，不是旧 value —— 所以适合做“基于 key 的动态构造”，比如key → new ArrayList()或key → loadFromDB(key) - 如果 mappingFunction 返回
null，整个方法返回null，且不存入 map（注意：HashMap允许 null value，但ConcurrentHashMap不允许！会抛NullPointerException）
示例：map.computeIfAbsent("user123", k -> fetchUserProfile(k)) —— key 不存在才触发远程调用。
立即学习“Java免费学习笔记（深入）”；
哪些场景必须用它？哪些反而要小心？
适合的场景：
- 构建嵌套结构：如
Map<string list>></string>，避免每次 add 前检查 list 是否为空 - 缓存加载：key 对应资源需首次访问时初始化（如配置、连接池）
- 统计聚合：如
Map<string integer></string>计数，map.computeIfAbsent(word, k -> 0) += 1（注意：这行不安全，应改用merge或compute）
容易踩坑的地方：
- mappingFunction 里别写副作用逻辑（如发 HTTP、改 DB），因为无法保证只执行一次（某些 Map 实现或并发下可能重试）
- 别在 lambda 里捕获外部可变变量，尤其在并发 map 中——
ConcurrentHashMap的 compute 系列方法不保证对同一 key 的多次调用串行化 - 如果 key 本身是复杂对象，确保其
equals/hashCode正确，否则computeIfAbsent找不到已有 key，反复初始化
和 compute、merge 的核心区别在哪？
一句话定位：
-
computeIfAbsent：只在 key 不存在时运行函数，传入的是key -
compute：无论 key 存不存在都运行函数，传入的是key和当前value（可能为 null） -
merge：key 存在时用 oldVal + newVal 合并，不存在时直接 put newVal；适合计数、字符串拼接等“二元合并”场景
比如累加计数：map.merge("a", 1, Integer::sum) 比 computeIfAbsent 更直接，也比手写 if + get + put 更安全。
真正难的不是记住语法，而是判断“这个初始化逻辑是否真的该由 map 自己承担”——如果构造过程依赖外部状态、需要事务控制、或失败后不该重试，那 computeIfAbsent 就不是解药，只是把问题藏得更深了。
