Map.merge()仅在键已存在时调用remappingFunction；键不存在则直接put，不执行函数；返回null会删除该键；多线程需用ConcurrentHashMap保证原子性。
Map.merge() 的核心行为：只在键存在时才触发 remappingFunction
调用 merge() 时，如果键 不存在，直接 put 新值，remappingFunction 根本不执行；只有键 已存在，才会把旧值、新值传给它。这是很多初学者误以为“每次都会调用函数”的根源。
常见错误现象：merge("k", 1, (old, new) -> old + new) 在首次插入时返回 1，但有人期望它“先查再加”，结果发现没累加——因为根本没进 lambda。
- 务必确认键是否已存在，否则累加逻辑不会触发
- 若想无条件累加（比如初始化为 0 再加），应先确保键存在，或改用
compute() -
remappingFunction返回null会导致该键被移除（不是保留旧值）
累加场景：用 Integer::sum 或自定义加法逻辑
统计频次、求和等场景最常用。Java 8+ 提供了 Integer::sum 这类方法引用，简洁且语义清晰。
Map<String, Integer> counts = new HashMap<>();
counts.merge("apple", 1, Integer::sum); // 首次：put("apple", 1)
counts.merge("apple", 1, Integer::sum); // 已存在：put("apple", 2)
- 避免写
(a, b) -> a + b，用Integer::sum更安全（自动处理 null 检查？不，它不处理 null —— 所以确保旧值非 null） - 如果 value 可能为 null（比如用
computeIfAbsent初始化后又 merge），必须自己判空，例如(old, unused) -> (old == null ? 0 : old) + 1 - 对于
Long或Double，没有内置 sum 方法引用，得手写(a, b) -> a + b并注意装箱开销
覆盖场景：用 (old, new) -> new 或更复杂的策略
覆盖看似简单，但容易忽略旧值的资源释放或副作用。比如 value 是一个集合，直接替换可能造成内存泄漏。
典型错误：merge("key", list, (old, newList) -> newList) —— 如果 old 是个大集合，不显式清空或丢弃，GC 延迟可能导致 OOM。
- 纯覆盖用
(old, new) -> new即可，但要确认业务允许丢弃旧值 - 若需合并集合，别直接替换，改用
(old, newList) -> { old.addAll(newList); return old; } - 若新值是“更优”版本（如时间戳更新），可用
(old, new) -> new.timestamp > old.timestamp ? new : old
性能与线程安全：HashMap.merge() 不是原子的，ConcurrentHashMap 才是
很多人在多线程下直接用 HashMap.merge() 做计数，结果出现漏加。这是因为 HashMap 的 merge() 包含 get + compute + put 三步，非原子。
错误日志常表现为：并发调用 merge("k", 1, Integer::sum) 后，最终值小于预期总和。
- 单线程用
HashMap没问题；多线程必须换ConcurrentHashMap -
ConcurrentHashMap.merge()是原子操作，内部用 CAS + synchronized 保证一致性 - 注意：即使用了
ConcurrentHashMap，remappingFunction里不要做耗时或阻塞操作，否则拖慢整个桶的并发度
真正容易被忽略的是 remappingFunction 的执行时机和上下文：它在 map 内部锁住对应 bin 期间运行，既不能假设外部状态，也不能抛出受检异常（函数接口是 BiFunction，只允许 RuntimeException）。写的时候得把它当成一个纯、快、窄作用域的计算单元。
