Java 1.8 引入了 Stream API，提供了如 map、filter 和 reduce 等中间操作和终端操作，极大地简化了集合处理。然而，对于一些复杂场景，如状态依赖的操作或无限流的处理，JDK 1.8 的能力有限。
JDK 24 中 JEP 485 引入新特性Stream Gatherers，旨在增强 Java Stream API 的灵活性和表达力。它允许开发者定义自定义的中间操作，这些操作可以维护状态、处理无限流，并生成新的流。
一、与 JDK 1.8 的主要变化
1、自定义中间操作
JDK 1.8 的 Stream API 提供了一组固定的中间操作，开发者若需实现自定义逻辑，往往需要使用状态化的 lambda 表达式或外部库，这通常导致代码复杂且难以维护。
Stream Gatherers 引入了 gather 方法，接受一个 Gatherer 对象。Gatherer 类似于 Collector，但用于中间操作而非终端操作。它由四个函数组成：initializer（初始化状态，可选）、integrator（处理每个元素）、combiner（合并并行状态，可选）和 finisher（结束处理，可选）。这允许开发者定义状态依赖的中间操作，例如跟踪前一个元素或缓冲输入。
例如，处理连续重复元素的去重操作，在 JDK 1.8 中可能需要手动维护状态，而在 Stream Gatherers 中可以直接使用 gather 定义更优雅的逻辑。
2、处理无限流
JDK 1.8 的 Stream API 在处理无限流时存在限制，许多操作（如 collect）需要终端操作，容易导致内存溢出或性能问题。
Stream Gatherers 设计上支持无限流的懒惰处理，通过 Gatherer 的机制可以动态生成输出流，特别适合如传感器数据流或事件流的场景。
例如，windowSliding 可以对无限流进行滑动窗口分析，而不会提前加载所有数据。
3、内置 Gatherers
JDK 24 提供了五个内置 Gatherers，位于
java.util.stream.Gatherers 类中，包括：
- windowFixed(n)：将元素分组为固定大小的窗口。
- windowSliding(n)：创建滑动窗口，每个窗口包含前一个窗口的元素（除第一个）和下一个元素。
- fold(initial, operation)：类似左折叠，顺序处理元素。
- mapConcurrent(maxConcurrency, mapper)：并发执行映射操作，使用虚拟线程。
- scan(initial, operation)：计算累积结果，类似于前缀和。
这些操作在 JDK 1.8 中要么需要手动实现（如通过 reduce 或自定义收集器），要么完全不可用。例如，windowFixed(4) 可以轻松生成如 [[0,1,2,3], [4,5,6,7]] 的窗口，而 JDK 1.8 需要复杂的缓冲逻辑。
以下表格总结了部分内置 Gatherers 与 JDK 1.8 的对比：
操作 | JDK 1.8 实现 | Stream Gatherers (JDK 24) | 优势 |
固定窗口（windowFixed） | 通过 collect 和手动缓冲，代码复杂 | gather(Gatherers.windowFixed(n))，直接可用 | 简洁，易读，性能优化 |
滑动窗口（windowSliding） | 无直接支持，需要自定义逻辑 | gather(Gatherers.windowSliding(n))，内置支持 | 减少代码量，支持无限流 |
并发映射（mapConcurrent） | 使用 parallelStream().map()，受限于 fork-join 池 | gather(Gatherers.mapConcurrent(n, mapper))，用虚拟线程 | 适合阻塞操作，性能提升 |
累积计算（scan） | 无直接支持，需要手动累积 | gather(Gatherers.scan(initial, operation))，内置支持 | 简化实现，适合顺序处理 |
二、优化点
1、效率提升
通过标准库优化的内置 Gatherers，开发者可以避免手动实现复杂逻辑，从而减少性能开销。例如，mapConcurrent 使用虚拟线程技术，特别适合 I/O 密集型任务，相比 JDK 1.8 的 parallelStream().map()，能更好地利用现代硬件资源。
自定义 Gatherers 允许开发者针对特定场景优化逻辑，避免 JDK 1.8 中可能出现的冗余计算或内存使用。
2、并行处理
**Gatherer 支持通过 combiner 函数实现并行执行，这与 JDK 1.8 的并行流类似，但更灵活。例如，mapConcurrent 可以配置最大并发数（maxConcurrency），并利用虚拟线程技术，适合阻塞操作的并发处理，相比 JDK 1.8 的 fork-join 池更高效。
3、代码简洁性
Stream Gatherers 减少了复杂变换所需的代码量。例如，JDK 1.8 中实现滑动窗口可能需要手动维护缓冲区和状态，而使用 windowSliding 只需要一行代码。
这不仅提升了代码的可读性，还降低了手动实现的错误风险，特别是在并行场景下。
三、jdk8和jdk24分别实现滑动窗口
假设需要生成大小为 2 的滑动窗口。
1、JDK 1.8 实现
Stream numbers = Stream.of(1, 2, 3, 4, 5);
Stream<List> windows = numbers.collect(ArrayList::new, (list, element) -> {
if (list.size() == 2) {
list.remove(0);
}
list.add(element);
if (list.size() == 2) {
// 需要额外的逻辑将窗口添加到结果流
}
}, (left, right) -> {
// 并行合并逻辑复杂
});
// 实现复杂，且难以处理无限流 2、JDK 24 Stream Gatherers 实现
Stream numbers = Stream.of(1, 2, 3, 4, 5);
Stream<List> windows = numbers.gather(Gatherers.windowSliding(2));
// 直接生成 [[1,2], [2,3], [3,4], [4,5]]，简洁高效 从上述对比可见，Stream Gatherers 显著简化了实现，特别适合状态依赖的操作。
一个可能出乎意料的细节是，mapConcurrent 的引入利用了虚拟线程技术（Project Loom），这在 JDK 1.8 中完全不可用。它允许并发映射操作在虚拟线程上执行，特别适合 I/O 密集型任务，如网络请求或数据库查询，相比 JDK 1.8 的 parallelStream().map()，性能提升显著。
四、结论
Stream Gatherers 在 JDK 24 中为 Java Stream API 带来了重大改进，相较于 JDK 1.8，它提供了更强的自定义能力、更好的无限流支持和优化的并行处理。通过内置 Gatherers 和自定义操作，开发者可以更高效地处理复杂流变换，提升代码可读性和性能。