Stream API 的惰性求值是什么？parallelStream 一定更快吗？

简化版

Stream 是对数据处理流水线的抽象，不存储数据，并且通常只能消费一次；filter、map 等中间操作是惰性的，只有终止操作才触发执行。parallelStream 不一定更快，拆分合并成本、数据量、任务特征、共享线程池和顺序要求都可能让它更慢甚至产生问题。

详细版

Stream 流水线由数据源、零个或多个中间操作和一个终止操作组成。中间操作返回新 Stream，通常不会立刻遍历数据；终止操作触发计算，findFirst、anyMatch、limit 等还可能短路，不必处理全部元素。

使用 Stream 应遵守非干扰和无状态原则：处理过程中不要修改数据源，行为参数也尽量不要依赖会变化的共享状态。map 是一对一转换，flatMap 则把每个元素产生的流摊平成一个流。

并行流适合数据量足够大、易拆分、单元素计算较重且没有共享可变状态的 CPU 型任务。小集合、阻塞 I/O、严格顺序处理或频繁同步的任务，通常不适合直接改成并行流。

完整版教学

一、Stream 不是集合

集合关心元素的存储和管理，Stream 关心如何计算。Stream 可以来自集合、数组、文件或生成函数，但它本身不保存所有元素，也不能像集合一样重复遍历。

Stream<String> stream = List.of("Java", "Go", "Rust").stream();
long count = stream.filter(name -> name.length() > 2).count();
// stream.findFirst(); // 已执行终止操作，不能再次消费

终止操作执行后，这条 Stream 流水线就已被消费；需要再次计算时，应从数据源重新创建 Stream。

二、惰性求值如何工作

下面的 filter 和 map 只是在组装流水线，直到 findFirst 才开始拉取元素：

Optional<String> result = names.stream()
        .filter(name -> name.startsWith("A"))
        .map(String::toUpperCase)
        .findFirst();

操作通常按元素融合执行：一个元素依次经过 filter 和 map，不一定先过滤完整个集合再统一映射。由于 findFirst 是短路操作，找到首个结果后便可停止，这也是惰性模型的价值。

三、map、flatMap、reduce 与 collect

map 将一个元素映射成一个结果；如果映射结果本身是集合或 Stream，flatMap 可把嵌套结构展开：

List<String> words = lines.stream()
        .flatMap(line -> Arrays.stream(line.split("\\s+")))
        .toList();

reduce 适合把元素按结合运算归约成一个值，如求和；collect 适合把元素累积到集合或分组结果。并行归约时，操作应满足结合律，identity 也必须是真正的单位元，否则顺序流看似正确、并行流却可能得到不同结果。

四、为什么并行流不一定更快

并行流需要把数据拆成子任务，在线程间调度，最后再合并结果，这些都有成本。数组、ArrayList 容易均匀拆分，链表或某些迭代数据源的拆分成本更高；任务太轻时，调度成本可能超过计算收益。

并行流默认通常使用 ForkJoinPool.commonPool()。同一进程里的其他并行流和异步任务可能共享它，若在其中执行慢速阻塞 I/O，工作线程会被占住并影响无关任务。需要明确隔离、限流、超时和线程池治理的业务，更适合显式使用受控执行器。

五、副作用与顺序问题

以下写法在并行执行时会并发修改 ArrayList，可能丢数据或抛异常：

List<String> result = new ArrayList<>();
names.parallelStream()
        .filter(name -> !name.isBlank())
        .forEach(result::add); // 错误的共享可变状态

应使用 toList() 或合适的 Collector 汇总结果。forEach 在并行流中不保证遇到顺序，forEachOrdered 可以保序，但会增加协调成本。是否并行应通过代表性数据基准测试决定，不能只看代码更短。

六、用数字理解并行阈值与归约定律

假设处理 1,000,000 个元素，每个元素纯计算 10 微秒，串行理论计算约 10 秒，拆分到 8 核可能有收益；若每个元素只做 10 纳秒加法，总计算约 10 ms，任务拆分、调度和合并很可能吞掉收益。阈值没有跨机器通用常数，必须用代表性数据、JIT 预热后的基准测量吞吐与尾延迟。

归约还要求结合律。减法不满足结合律：顺序计算 (0 - 1) - 2 - 3 = -6，并行分组可能组合成不同结果；浮点加法数学上近似结合，但舍入顺序改变也可能产生细微差异。

结合律要求：combine(combine(a,b),c) == combine(a,combine(b,c))
单位元要求：combine(identity,x) == x

条件	有利于并行	不利于并行
数据源	数组、ArrayList 易拆分	迭代/不均匀源难拆分
单项工作	CPU 重、独立	极轻或阻塞 I/O
操作性质	无状态、结合归约	共享可变状态、锁竞争
顺序要求	unordered 可接受	`forEachOrdered` 等强顺序

七、状态操作、短路与资源生命周期

sorted、distinct 等 stateful intermediate operation 可能需要看到大量甚至全部输入，并在并行时产生缓冲和多轮处理；惰性不等于不占内存。limit、findFirst、anyMatch 可以短路，但是否能早停还受前置排序、顺序约束和数据源特性影响。

来自 Files.lines 等 I/O 源的 Stream 持有资源，必须 try-with-resources 关闭；普通集合 Stream 通常没有这类关闭需求。peek 主要适合调试观察，不能依赖它承担必须发生的业务副作用，因为实现可在不影响结果时省略某些阶段执行。

心法：Stream 优化的是声明式流水线，parallel 优化的是满足可拆分、无状态、结合律条件的计算；两者都不保证副作用执行次数。

八、常见误区与追问

误区：调用 map 时会立刻遍历整个集合。 中间操作通常只组装流水线，终止操作才触发处理。
误区：Stream 可以像 List 一样反复消费。 终止操作后流已被消费，再使用通常抛 IllegalStateException。
误区：parallelStream 对任何数据量都更快。 拆分、调度、合并、顺序和共享资源成本可能超过并行收益。
误区：给共享 ArrayList 加 synchronized 就是最佳并行收集方式。 同步竞争会抵消并行，应优先使用正确 Collector 或 toList。
追问：为什么 reduce 的运算要满足结合律？ 并行实现会改变分组顺序，不结合的操作可能得到与顺序流不同的结果。
追问：findFirst 与 findAny 有何取舍？ findFirst 尊重遇到顺序，findAny 允许返回任意匹配项，并行时可能减少协调。
追问：并行流能否安全执行阻塞 I/O？ 语法上能，但通常占用共享工作线程且缺少隔离治理，更适合显式执行器或虚拟线程方案。

九、加强记忆

Stream 是一次性计算流水线：中间操作惰性组装，终止操作触发执行，短路操作可能提前结束。并行流只有在数据易拆分、计算足够重、操作无共享状态且顺序要求低时才可能受益，绝不是把 stream() 换成 parallelStream() 就会提速。

简化版

详细版