为什么在Stream API中合并多个Map时不推荐使用reduce方法？

你给出的reduce写法本质上违反了Java Stream API中reduce方法的设计规约，属于对可变汇聚场景的错误实现，主要存在以下缺陷：

• 存在不可控的副作用，会污染原始数据
  该实现直接修改reduce传入的第一个参数r，也就是你的原始集合myCol中存储的Map对象。如果后续业务逻辑还需要用到这些原始Map的原有数据，会直接出现数据异常。
• 完全不支持并行流，线程安全风险极高
  reduce的规约要求累加操作是无状态、不修改输入对象的纯运算。如果切换为并行流执行，多个线程会同时修改同一个累加Map对象，轻则出现计算结果错误，重则抛出ConcurrentModificationException。
• 代码本身存在语法错误，无法直接运行
  你给出的示例代码有两处明显编译问题：
  1. reduce接收的二元操作符要求返回合并后的结果对象，你的lambda表达式只有forEach逻辑，缺少return r;语句
  2. orElseThrow中传入的是异常实例构造逻辑，示例中缺少new关键字，正确写法应为orElseThrow(() -> new RuntimeException())
• 就算修复语法、规避副作用，性能也远低于collect方案
  如果要符合reduce的无副作用规约，你不能修改原有Map，每次合并都需要创建新的Map对象、拷贝已有数据再合并新Entry，时间复杂度会升至O(n²)，数据量较大时性能差距非常明显。

Map<String, Double> outMap = 
myCol.stream()
     .flatMap(m -> m.entrySet().stream())
     .collect(Collectors.toMap(Map.Entry::getKey, Map.Entry::getValue, Double::sum));

这套实现完全符合Stream API的设计规范：

• 无副作用：不会修改原始集合中的任何Map对象，所有汇聚操作都在收集器内部创建的新Map上执行
• 原生支持并行：collect是专门为可变汇聚场景设计的API，内部已经做了线程安全的拆分、合并逻辑，并行执行也能保证结果正确
• 可读性更强：代码清晰表达了「扁平化所有Entry -> 按键聚合值」的逻辑，符合常规编码习惯

内容的提问来源于stack exchange，提问作者betterchen