当前位置：首页 > 文章列表 > 文章 > java教程 > Java Stream 分组统计如何避免重复遍历：Collectors.groupingBy 的性能与内存取舍

Java Stream 分组统计如何避免重复遍历：Collectors.groupingBy 的性能与内存取舍

来源：17golang原创 2026-08-25 09:43:32 0浏览收藏

订单列表已经在数据库里按时间查出来了，业务代码却又连续遍历几遍：先按状态分组，再统计金额，最后还要取每组数量。数据量一大，这种写法的代价不在某一行 API，而在中间集合不断膨胀。更稳妥的做法是先明确结果形状，再选择 Collectors.groupingBy 和下游收集器，让一次归约直接产出需要的数据。

如果最终只需要每个状态的数量或金额，不要先把每个分组都收集成完整的 List；优先使用 counting()、summingLong() 或自定义下游收集器。这样可以少保留一层中间对象，但并不意味着 Stream 自动减少了源数据本身的内存占用。

实践要点

只要统计结果，就用下游收集器直接归约。
需要明细列表时，才接受每组 List 的内存成本。
并行流要结合数据量、分组基数和合并成本实测。

先把“分组结果”定义清楚

下面用一个不可变的订单记录作为例子。状态只有 PAID、REFUNDED 和 PENDING，金额用分为单位的 long 保存，避免在归约过程中引入浮点误差。

record Order(String status, long amountCent) {}

List orders = List.of(
    new Order("PAID", 12900),
    new Order("PAID", 8800),
    new Order("REFUNDED", 12900),
    new Order("PENDING", 4500)
);

如果页面要展示每个状态的订单明细，结果类型应该是 Map>；如果只展示数量和成交金额，结果就不该携带完整订单对象。先确定这一点，后面的收集器选择会简单很多。

需要明细时才使用 List 分组

最直观的写法是：

Map> byStatus = orders.stream()
    .collect(Collectors.groupingBy(Order::status));

它的优点是可读性好，后续要筛选某个状态的订单也方便。代价也很明确：每条订单至少要被某个分组列表引用一次，分组数量和列表对象都会增加。如果只为了算数量再遍历这些列表，就形成了不必要的中间结构。

只统计数量和金额时直接使用下游收集器

数量统计可以把下游收集器改成 counting()：

Map countByStatus = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        Collectors.counting()
    ));

金额合计同理：

Map amountByStatus = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        Collectors.summingLong(Order::amountCent)
    ));

这两段代码都不会为每个状态保留订单列表。注意，groupingBy 仍然要建立一个结果 Map，源集合也仍然存在；它节省的是分组明细的额外引用和列表结构，不是把所有内存成本都变成零。

一个归约同时得到多个指标

页面经常既要数量又要金额。此时不要对同一源集合做两次分组，可以使用 teeing 将两个下游结果合并。它需要 Java 12 或更高版本：

record StatusStat(long count, long amountCent) {}

Map stats = orders.stream()
    .collect(Collectors.groupingBy(
        Order::status,
        Collectors.teeing(
            Collectors.counting(),
            Collectors.summingLong(Order::amountCent),
            StatusStat::new
        )
    ));

如果项目还停留在 Java 8，可以先保留一次分组后的列表，或者写一个小型可变累加器。迁移时要把版本边界写进构建检查，不能只在本地 JDK 21 上编译通过就结束。

并行流不是默认的性能开关

groupingByConcurrent 可以在并行流场景下使用并发 Map，但它并不会自动让所有分组统计更快：

Map countByStatus = orders.parallelStream()
    .collect(Collectors.groupingByConcurrent(
        Order::status,
        Collectors.counting()
    ));

数据量小、状态种类少、单条计算很轻时，拆分任务和合并结果的成本可能超过收益。状态种类很多时，线程竞争也会改变结果。建议固定数据生成方式，分别测量顺序流、并行流和普通循环的耗时，并观察堆占用，而不是只看一次请求的墙上时间。

用结果检查来防止“统计正确但模型错误”

上线前至少检查三个边界：空集合返回空 Map；未知状态是否应该归入 OTHER；金额是否可能超出 long 的业务范围。还要核对统计总数与源数据数量一致：

long groupedCount = countByStatus.values().stream()
    .mapToLong(Long::longValue)
    .sum();
if (groupedCount != orders.size()) {
    throw new IllegalStateException("grouped count does not match source size");
}