forEachOrdered的核心作用是在任何流（包括并行流）中严格保持元素原始顺序执行消费动作；它在并行流中强制按源序排队执行，引入线程协调机制，而forEach在并行流中无序执行、无同步开销。
Java Stream API 中的 forEachOrdered 是一个关键的终止操作，核心作用是**在任何流（包括并行流）中严格保持元素的原始顺序执行消费动作**。它不是“更安全的 forEach”，而是有明确语义和适用边界的工具——用错场景反而拖慢性能。
什么时候必须用 forEachOrdered
当业务逻辑依赖处理顺序时，不能妥协：
- 向外部系统逐条写入日志、数据库记录或消息队列，要求时间戳或ID严格递增
- 生成带序号的报告（如“第1项：…，第2项：…”），序号需与输入源一致
- 调用有状态的外部服务（如累计积分、更新同一账户余额），顺序错误会导致结果不一致
- parallelStream() 后接 sorted()，此时流已排序但仍是并行的，后续消费必须用 forEachOrdered 才能保证有序输出
和 forEach 的本质区别不在“串行/并行”，而在“顺序约束”
很多人误以为 forEach 是“串行专用”，forEachOrdered 是“并行专用”。实际是：
- 在 顺序流 中，两者行为完全一致，都按源顺序执行，无性能差异
- 在 并行流 中，forEach 允许任意线程以任意顺序执行动作，不加锁、无同步开销；forEachOrdered 则强制按源顺序排队执行，内部会引入线程协调机制（如使用 Spliterator 的 encounter order 保证 + 队列缓冲），带来明显延迟
- forEach 可能提前终止（如被中断或 JVM 信号打断），而 forEachOrdered 必须遍历全部元素
典型误用与规避建议
避免把 forEachOrdered 当成“保险丝”滥用：
立即学习“Java免费学习笔记（深入）”；
- 仅需打印调试或收集到本地 List？用 forEach 更快，顺序无关紧要
- 想对每个元素做独立计算（如转换为字符串、校验格式）？优先用 map 或 collect，它们天然支持并行且可组合
- 需要“先排序再处理”？不要写
.parallelStream().sorted().forEachOrdered(...)，这会抵消并行优势；考虑是否能用collect(Collectors.toList())拿到有序列表后再批量处理 - 若必须用 forEachOrdered 且性能敏感，可评估是否缩小并行度：
.parallelStream().unordered()不适用（会破坏顺序），但可调小 fork-join 线程池规模或改用顺序流
一个简洁可靠的写法示例
以下代码确保即使在多核机器上，输出也一定是 “A → B → C → D”：
List<String> data = Arrays.asList("A", "B", "C", "D");
data.parallelStream()
.map(s -> s.toLowerCase()) // 并行转换，无序但高效
.forEachOrdered(s -> System.out.print(s + " ")); // 仅此处保序输出
// 输出：a b c d（严格顺序）
