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)</string>

• 避免写 (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）。写的时候得把它当成一个纯、快、窄作用域的计算单元。