Java Stream API的流水线模型是描述模型而非执行模型，源→中间操作链→终端操作构成三段式结构，中间操作惰性记录行为，终端操作触发Sink链执行，融合构建器、策略、观察者和流水线模式，无状态操作支持并行，有状态操作影响性能。
Java Stream API 的流水线模型不是执行模型，而是描述模型——它不立刻干活，而是先画一张“处理蓝图”，等终端操作一声令下，才真正启动数据流动。
流水线三段式结构：源 → 中间操作链 → 终端操作
整条流水线像一条装配线，每个环节职责明确：
-
源（Source Stage）：只负责“出料”，比如
list.stream()或IntStream.range(1, 100)，背后封装的是Spliterator，不参与计算，也不消耗数据。 -
中间操作链（Intermediate Stages）：如
filter、map、sorted，每个都返回新 Stream，仅记录“要做什么”和“上游是谁”，不触发任何实际处理。它们是惰性的，堆得再多也不执行。 -
终端操作（Terminal Operation）：如
collect()、findFirst()、forEach()，一旦调用，就从末端反向组装Sink链，再正向推数据流过所有 stage，完成整条流水线的执行。
Stage 与 Sink：分工协作的执行机制
Stage 是配置节点，Sink 才是干活的人：
- 每个中间操作生成一个
Stage对象，保存行为逻辑（如predicate或function）和上游引用，但不做运算。 - 终端操作触发时，系统从最后一个 Stage 开始，逐级调用
opWrapSink(downstream)，把下游 Sink “包一层”自己的逻辑，最终形成嵌套结构：例如collect()→MapSink→FilterSink→SourceSpliterator。 - 数据真正流经时，每个 Sink 各司其职：过滤的只管判别，转换的只管映射，收集的只管归并，彼此解耦，互不影响。
设计模式支撑下的可组合性与延迟性
流水线能力不是凭空而来，它融合了多个经典设计模式：
立即学习“Java免费学习笔记（深入）”；
-
构建器模式：链式调用
stream().filter().map().sorted()实质是逐步配置蓝图，而非立即执行。 -
策略模式：
Predicate、Function等函数式接口让行为可插拔，同一filter方法能接受任意判断逻辑。 - 观察者模式：终端操作作为“触发事件”，通知所有 Stage 启动 Sink 执行，实现松耦合响应。
- 流水线模式（核心）：将复杂处理拆为线性、可替换、可调试的 stage，每个只专注输入→处理→输出，天然支持并行与优化。
有状态 vs 无状态：影响执行效率的关键分水岭
中间操作是否依赖全局上下文，直接决定性能表现：
-
无状态操作（如
filter、map、peek）：每个元素独立处理，可任意分片、并行、短路，适合大规模数据。 -
有状态操作（如
sorted、distinct、limit）：需缓存或观察前置部分/全部数据才能决策当前元素行为，会引入缓冲区或全局协调，可能削弱并行优势。 - 例如：
.parallelStream().sorted().map(...).collect()中，sorted会强制等待全部数据到位，使后续 map 无法真正并行展开；而把filter提前，就能显著减少排序数据量。
