forEachOrdered在并行流中不改变并发执行方式，仅保证Consumer按原始流顺序执行：各线程并行计算后将任务提交FIFO队列，由单一调度线程串行消费，从而实现顺序输出但不牺牲计算并行性。
forEachOrdered 在并行流中不改变元素处理的并发执行方式，而是**保证消费动作（Consumer）按原始流顺序执行**——即：多个线程可以同时处理不同元素，但每个元素传给 Consumer 的时机被强制串行化，严格遵循原始数据顺序。
为什么并行流默认不保证 forEach 顺序？
并行流将数据拆分到多个线程处理，forEach 是无序消费操作，JVM 不约束各线程调用 Consumer 的先后。例如流 [1,2,3,4] 并行处理时，可能先输出 4、再输出 1，顺序不可预测。
forEachOrdered 如何实现“顺序消费”？
它内部使用同步机制（如锁或队列）对 Consumer 调用进行**串行调度**：
- 各工作线程完成自己负责的元素计算后，不直接执行 Consumer，而是将“元素 + 消费动作”提交到一个**FIFO 队列**；
- 一个专属的调度线程（或通过 synchronized / Lock 保护）按队列顺序逐个取出并执行 Consumer；
- 因此，即使 3 在 2 之前算完，也必须等 2 入队、出队、执行完，才轮到 3 的 Consumer。
关键注意事项
这不是“顺序处理”，而是“顺序消费”：
立即学习“Java免费学习笔记（深入）”；
- ✅ 元素的 计算过程仍并行（性能未退化为单线程）；
- ✅ 最终 Consumer 执行顺序与原始流一致（如
list.stream().parallel().forEachOrdered(System.out::println)输出必为 1,2,3,4）； - ❌ 不能用于有状态的副作用操作（如修改共享变量），因 Consumer 执行虽有序，但计算阶段已并发，中间结果不可控；
- ⚠️ 性能开销比 forEach 略高（需同步入队/出队），尤其在 Consumer 很轻量时可能得不偿失。
替代方案建议
如果真正需要顺序处理（而非仅顺序打印/记录），应避免并行流：
- 用
stream().forEach(...)—— 单线程、天然有序、无同步开销； - 若部分逻辑可并行（如 map 转换），可先
parallelStream().map(...).collect(...)得到新集合，再用顺序流消费； - 对日志、调试等场景，forEachOrdered 是简洁可靠的选择。
不复杂但容易忽略：顺序保障只作用于 Consumer 执行这一层，和上游计算是否并行无关。
