compute 是“先读再算再写”，键不存在时也调用函数；merge 是“有则合并，无则插入”，键不存在时直接 put 新值、不调用函数。
compute 和 merge 的语义差异在哪
compute 是“先读再算再写”，不管键是否存在，都会调用你传的函数；merge 是“有则合并，无则插入”，只在键已存在时才触发合并逻辑，否则直接 put。
常见错误现象：用 merge 替代 compute 处理初始化逻辑，结果 key 不存在时啥也不干，值没设上。
使用场景：
-
compute适合需要统一处理（比如递增计数、懒加载对象）； -
merge更适合“已有值就叠加，没有就新建”的聚合场景，比如归并统计。
参数差异：
立即学习“Java免费学习笔记（深入）”；
-
compute(K key, BiFunction super K, ? super V, ? extends V> remappingFunction)：函数接收 key 和当前 value（可能为 null），必须返回新值； -
merge(K key, V value, BiFunction super V, ? super V, ? extends V> remappingFunction)：value 是“新值”，函数只在旧值非 null 时才调用，且只接收两个 V。
null 值处理不一致，极易踩坑
compute 的函数里，第二个参数是当前 value —— 如果 key 不存在，这个参数就是 null；你得自己判断是否要初始化。
merge 的函数根本不会被调用，如果 key 不存在，它直接把传入的 value 放进去，不经过函数。
容易忽略的点：
-
compute中若函数返回null，会从 map 中移除该 key； -
merge中若函数返回null，同样会移除 key； - 但
merge的初始value参数不能为null（除非 map 允许 null value，如HashMap），否则抛NullPointerException。
示例对比：
Map<String, Integer> map = new HashMap<>();
map.compute("a", (k, v) -> v == null ? 1 : v + 1); // → "a"=1
map.merge("b", 1, Integer::sum); // → "b"=1
map.merge("a", 1, Integer::sum); // → "a"=2
map.compute("c", (k, v) -> null); // → 移除 "c"（即使不存在也安全）
性能与并发 Map 的行为差异
在 ConcurrentHashMap 中，compute 和 merge 都是原子操作，但实现机制不同：
-
compute对整个 key 的桶加锁，执行函数全程独占； -
merge在 key 不存在时走快速 put 路径，仅在冲突时才升级为 compute-like 锁。
性能影响：
- 高并发下，频繁用
compute更新同一 key 容易形成热点锁； -
merge对“新增为主、合并为辅”的场景更友好； - 两者都不建议在函数体内做耗时操作（如 IO、远程调用），会阻塞其他线程。
兼容性注意：
-
computeIfAbsent和computeIfPresent是更细粒度的替代选择，Java 8 就有； -
merge在 Java 8 引入，但部分老项目用的 Guava 或 Apache Commons 可能有同名方法，语义未必一致。
什么时候该选哪个：一个判断流程
看你要解决的问题是不是“先查后改”：
- 需要基于 key 做条件判断（比如 key 是用户 ID，要根据角色决定初始化策略）→ 用
compute； - 只关心 value 怎么合并（比如累加、字符串拼接、对象字段合并）→ 优先
merge； - 函数体里要区分“首次插入”和“再次更新” →
compute更直白，merge得靠额外状态或默认值绕开； - 担心
null传入导致 NPE →compute更可控，因为你能看到当前 value 是什么。
最常被忽略的一点：merge 的第三个参数函数，两个入参顺序是 (oldValue, newValue)，不是 (newValue, oldValue)。写反了会导致逻辑倒置，而且编译不出错。
