Java 8 的 merge 方法适用于需按规则合并同 key 值的场景，如计数累加、字符串拼接、对象字段合并；它强制处理冲突逻辑，非 putAll 升级版，性能略低但语义更精确。
Java 8 的 merge 方法到底适合什么场景
merge 不是 putAll 的升级版，而是解决一类特定冲突的工具：当 key 已存在时，你得自己决定新旧 value 怎么“合”——加、拼、取大、选非空……它强制你面对冲突逻辑，而不是默认覆盖。
常见错误现象：merge 被当成“安全版 put”，结果 key 存在时触发了意料外的 lambda 计算（比如 old + newValue 却没检查 old 是否为 null），抛出 NullPointerException。
- 只在需要「按规则合并同 key 值」时用
merge，比如计数累加、字符串拼接、对象字段合并 - 必须提供非 null 的
remappingFunction，且该函数要能处理oldValue == null的情况（即使你认为不会发生） - 性能上比
putAll略低——每次都要查 key、判空、再调 lambda；但语义更精确，避免隐式覆盖
示例：
map.merge("count", 1, Integer::sum); // 安全累加，key 不存在就设 1，存在就 old+1
putAll 的真实行为和隐蔽风险
putAll 就是批量 put，逐个遍历源 Map 的 entry，对每个 key 执行「无条件覆盖」。它不关心目标 Map 里有没有这个 key，也不管旧值是什么类型或状态。
立即学习“Java免费学习笔记（深入）”；
常见错误现象：用 putAll 合并两个配置 Map，结果后者的 null 值把前者有效的配置项清掉了；或者合并用户属性 Map 时，误把空字符串覆盖了非空字段。
- 适用于「完全信任源数据」「目标 Map 是空白或可被整体接管」的场景，比如初始化、重载配置
- 源 Map 中 value 为
null会直接写入目标 Map——这和put(key, null)效果一致，可能意外删除已有 key - 不触发任何回调或合并逻辑，速度最快，但零容错；如果源 Map 很大，又频繁调用，注意避免在并发环境下直接操作非线程安全的 HashMap
什么时候该手写循环，而不是硬套 merge 或 putAll
当合并逻辑跨多个字段、需读取旧值其他属性、或要跳过某些 entry 时，merge 的单 entry lambda 就不够用了——它的 remappingFunction 只拿到 oldValue 和 newValue，看不到 key、也拿不到 map 其他状态。
使用场景：合并用户信息 Map，要求「只更新非空字段」「邮箱变更要发通知」「积分字段要相加而非覆盖」。
- 别强行把多步逻辑塞进
merge的 lambda，可读性和调试性会崩坏 - 改用传统 for-each 遍历源 Map，内部用 if 分支处理不同 key 的策略，该查数据库就查，该发消息就发
- 如果合并后还要做统一校验或持久化，手写循环反而更容易插入 hook 点
示例：
for (Map.Entry<String, Object> e : source.entrySet()) {<br> String key = e.getKey();<br> Object newVal = e.getValue();<br> if ("email".equals(key) && !Objects.equals(map.get(key), newVal)) {<br> notifyEmailChanged(newVal);<br> }<br> if ("score".equals(key)) {<br> map.merge(key, (Integer)newVal, Integer::sum);<br> } else if (newVal != null) {<br> map.put(key, newVal);<br> }<br>}
ConcurrentHashMap 下的 merge 和 putAll 行为差异
ConcurrentHashMap 的 merge 是原子的：整个「查 key → 判空 → 执行 remappingFunction → 写入」在一个分段锁内完成，不会被其他线程打断。而 putAll 是逐个 put，每 put 一次都单独加锁，中间可能穿插其他线程的修改。
容易踩的坑：以为 putAll 在 ConcurrentHashMap 里也是原子批量操作，结果在高并发下观察到部分 entry 被覆盖、部分没生效，其实是执行中途被抢占导致的中间态可见。
- 若需强一致性合并（比如更新一批关联指标），优先用
merge配合明确的 remappingFunction -
putAll在 ConcurrentHashMap 中不保证全部成功或全部失败，失败时已写的 entry 不会回滚 - 如果源 Map 本身也在被其他线程修改，
putAll迭代过程可能抛ConcurrentModificationException（取决于具体实现，但别依赖它不抛）
merge 的 remappingFunction 必须是纯函数——不能有副作用，也不能依赖外部可变状态。一旦在里面写日志、改全局变量、或调用远程接口，就会在并发下失控。 
