stream.reduce()求和不必须传三个参数，但单参数形式返回optional，空流时调用get()会抛异常；推荐用双参数形式reduce(0, integer::sum)或三参数形式确保安全，intstream.sum()更高效。
Stream.reduce() 求和必须传三个参数？
不是必须，但单参数 reduce() 只适用于有自然起始值（如 Optional 返回）的场景；求和这类明确需要初始值的操作，推荐用三参数重载——否则会返回 Optional<integer></integer>，还得额外判空或调 orElse(0)，反而多一层风险。
常见错误现象：stream.reduce(Integer::sum) 看似简洁，但输入为空流时返回 Optional.empty()，后续直接 .get() 就抛 NoSuchElementException。
- 用三参数形式：
reduce(identity, accumulator, combiner) -
identity必须是恒等值：对加法就是0，不能写成1或null -
accumulator是二元操作，如(sum, x) -> sum + x，不可修改外部变量 -
combiner在并行流中合并分段结果，加法下必须与accumulator语义一致，即(a, b) -> a + b
int[] 或 List 转 Stream 后怎么安全求和
原始类型数组（如 int[]）不能直接 Arrays.stream(arr).reduce(...) 得到 int——因为 Arrays.stream(int[]) 返回的是 IntStream，它自带 sum() 方法，比 reduce 更高效、更直观。
而 List<integer></integer> 是引用类型流，stream.reduce(0, Integer::sum, Integer::sum) 才是标准写法。
-
int[] arr = {1, 2, 3}; int s = Arrays.stream(arr).sum();✅ 直接、无装箱 -
List<integer> list = Arrays.asList(1, 2, 3); int s = list.stream().reduce(0, Integer::sum, Integer::sum);</integer>✅ 安全，空列表也返回0 -
list.stream().mapToInt(Integer::intValue).sum()✅ 避免装箱开销，适合大数据量
为什么并行流里 reduce 的 combiner 不能随便写
并行流会把数据切片，各线程分别 accumulate，最后用 combiner 合并中间结果。如果 combiner 写成 (a, b) -> a * b，那结果就变成乘积而非求和——逻辑彻底错乱，且难以复现（只在并行且分片 >1 时暴露）。
加法满足结合律，所以 Integer::sum 既可作 accumulator 也可作 combiner；但减法、除法、字符串拼接等不满足结合律的操作，绝不能复用同一函数。
- 正确：两个参数都用
Integer::sum或都用(a, b) -> a + b - 错误：
reduce(0, (s,x)->s+x, (a,b)->a-b)—— 这会导致结果依赖分片顺序，不可预测 - 性能影响：combiner 被频繁调用，应尽量轻量；避免在其中做 I/O、锁、复杂对象创建
Stream.reduce() 求和比 for 循环慢吗
单纯求和场景下，for 循环几乎总是更快：无对象创建、无函数调用开销、无流管道构建成本。Stream 的优势在于组合表达能力，不是单点性能。
容易被忽略的一点：如果上游已经是流（比如从数据库 ORM 返回的 Stream<t></t>），再转回集合用 for 循环，反而多一次收集开销，此时直接 reduce 更合理。
- 小数据量（reduce 或
sum() - 大数据量 + 原生
IntStream：优先用sum()，它底层是循环展开+向量化指令 - 混合操作链（filter/map/reduce）：别为了“求和快”提前
collect(toList())，破坏流式处理优势
