对比jdk1.8，看jdk24 Stream Gatherers牛逼在哪？

关注

原创最新推荐文章于 2026-08-10 21:40:24 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

JDK 1.8 64位安装详解与教程本文还有配套的精品资源，点击获取简介：本文详细介绍了Java Development Kit (JDK) 1.8的安装过程，包括下载、安装、配置环境变量、卸载以及JDK 1.8的新特性。JDK 1.8是Oracle公司发布的重要Java开发工具包版本，适用于64位操作系统，并具备更好的资源利用率和性能。安装步骤包括接受许可协议、选择安装类型和位置、配置环境变量以及在必要时... 阅读详情

在这里插入图片描述

一、与 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<Integer> numbers = Stream.of(1, 2, 3, 4, 5);
Stream<List<Integer>> 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<Integer> numbers = Stream.of(1, 2, 3, 4, 5);
Stream<List<Integer>> 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()，性能提升显著。