Stream.sequential()对已创建的并行流完全无效，仅在流构建阶段起作用；parallelStream()后调用sequential()不改变其并行特性，真正可控的方式是改用stream()、forEachOrdered或先collect再重开流。
Stream.sequential() 不能把并行流“降级”
直接说结论：Stream.sequential() 对已创建的并行流**完全无效**。它只在流构建阶段起作用——一旦调用过 parallel()，后续再链式调用 sequential()，不会改变该流的并行特性。JDK 源码里明确注释了：“This method has no effect on sequential streams, and may have no effect on parallel streams.”
常见错误现象：
- 写成
list.parallelStream().filter(...).sequential().map(...).collect(...)，以为后面操作变串行了，实际整个流仍是并行执行 - 调试时发现
ForkJoinPool.commonPool()仍有线程被占用，但业务逻辑却依赖顺序（比如日志打印、全局计数器），结果出现竞态或乱序
真正能控制执行模式的三种方式
想让一段流逻辑走单线程顺序执行，必须从源头切断并行能力：
-
用
stream()替代parallelStream()：最直接，也最安全。例如list.stream().filter(...).map(...) -
显式构造顺序流 +
forEach或forEachOrdered：如果原始数据源是并行流但你只希望消费端顺序处理，可用forEachOrdered（注意：它不改变中间操作的并行性，只保证终端操作的执行顺序） -
用
Collectors.toList()先落地，再对结果重开流：适用于需要先并行计算、再顺序后处理的场景，比如parallelStream().map(...).collect(Collectors.toList()).stream().forEach(...)
parallelStream() 后加 sequential() 的真实行为
这段代码：
List.of(1, 2, 3, 4).parallelStream()
.peek(x -> System.out.println("peek: " + x + " on " + Thread.currentThread().getName()))
.sequential()
.map(x -> x * 2)
.forEach(System.out::println);输出中 peek 仍会出现在多个线程上（如 ForkJoinPool.commonPool-worker-2），证明 sequential() 并未生效。因为 parallelStream() 创建的是 ParallelStream 实例，而 sequential() 返回的是同一个实例（只是内部标记未切换），JDK 不做运行时模式切换。
容易被忽略的关键点
并行流的执行模型绑定在流构建那一刻，不是靠链式调用动态调整的。如果你在工具方法里接收一个 Stream<t></t> 参数，别幻想用 .sequential() 来“统一转为顺序”——它可能根本没效果。真正可控的方式只有：要么让上游传入顺序流，要么自己重新构造新流。
