map.merge(word, 1, integer::sum) 是词频统计的正确用法，它原子性地实现“有则叠、无则建”，避免npe和并发丢失；勿用 get+put 组合或错误 lambda，慎混用 compute。
Map.merge() 怎么用才不覆盖已有值
直接用 merge() 做词频统计，核心是别把它当成“如果不存在就 put，存在就更新”的简单开关——它默认行为是「用 old + new 的结果替换旧值」，但你得自己提供合并逻辑。常见错误是传个 Integer::sum 却忘了初始值是 0，结果第一次遇到新词时传进去的 oldValue 是 null，直接 NPE。
实操建议：
- 始终用
map.merge(word, 1, Integer::sum)，第三个参数是 BiFunction，接收(oldValue, newValue)，返回新值；Integer::sum恰好能处理null（因为merge内部会把null当作 0 处理） - 不要写
map.merge(word, 1, (a, b) -> a + b)，看似一样，但 a 可能为null，运行时报NullPointerException - 如果 value 类型不是
Integer（比如AtomicInteger），必须自己判空，不能依赖Integer::sum
为什么不用 computeIfAbsent + getOrDefault + put 组合
手写三步：先 getOrDefault 拿当前频次，再加 1，再 put 回去——看着直白，但并发下会丢数据；换成 computeIfAbsent 又容易误用成只初始化不累加。而 merge() 是原子操作，JDK 8+ 的 ConcurrentHashMap 也支持它，线程安全且无竞态。
关键差异点：
立即学习“Java免费学习笔记（深入）”；
-
merge()在哈希桶级别加锁（或 CAS），比整个 map 加锁（如Hashtable）吞吐高得多 -
computeIfAbsent()适合「首次访问才创建对象」场景，不适合「每次都要叠加」——它只在 key 不存在时执行 mappingFunction，存在时直接返回旧值，没法干预更新逻辑 - 用
get() + put()组合，在多线程下可能两次读到相同旧值，两次写相同新值，导致一次计数丢失
Stream.collectingAndThen + groupingBy 能不能替代 merge
能，但别在高频更新场景用。比如对一整段文本做一次性统计，Arrays.stream(words).collect(Collectors.groupingBy(Function.identity(), Collectors.summingInt(w -> 1))) 很干净；但如果你在日志系统里逐条处理单词，每来一个就跑一遍 stream，性能直接垮掉——创建 Stream、装箱、Collector 初始化全都是额外开销。
真实权衡点：
- 单次批量处理：用
groupingBy更函数式，代码短，可读性好 - 持续增量更新（如实时词频监控）：必须用
merge()，避免反复构造中间集合和流管道 -
groupingBy返回的是新Map，无法复用已有 map 实例；merge()直接改原 map，内存友好
merge 和 compute 的边界在哪
compute() 更底层、更自由，但也更容易出错。它强制你处理 null，无论 key 存不存在，都调用你给的 function；merge() 则只在 key 存在时才触发合并逻辑，不存在就直接 put，语义更贴近「有则叠，无则建」。
选哪个？看需求是否需要「统一处理逻辑」：
- 纯词频统计：用
merge(word, 1, Integer::sum)，简洁安全 - 要同时支持「加 1」「减 1」「清零」多种操作：用
compute(word, (k, v) -> v == null ? 0 : v - 1)，但必须自己处理所有分支 -
compute()的 lambda 里若抛异常，整个操作失败；merge()的 remappingFunction 抛异常也会中断，但触发条件更可控（仅 key 存在时）
真正难的不是语法，是想清楚：这个 map 是只被你一个人写，还是会被多个模块以不同语义更新。一旦混用 merge 和 compute，value 的含义就容易错位——比如某处用 merge 累加，另一处用 compute 赋固定值，后续再 merge 就完全不对了。
