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

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

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

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

下面用一个不可变的订单记录作为例子。状态只有 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");
}

常见误区与选择建议

为了一个 count 先收集全部明细

如果没有后续明细需求，直接使用 counting()。这不是为了追求代码短，而是让结果类型准确表达页面真正需要的数据。

把 groupingBy 换成并发版本就算优化

并发收集器适合有足够计算量且分组键竞争可接受的场景。先做基准，再决定是否引入并行流；不要用它掩盖数据库查询、对象创建或序列化的瓶颈。

忽略 Map 的键顺序

默认 groupingBy 不承诺业务展示顺序。如果接口需要固定顺序，显式传入 LinkedHashMap::new，或在输出层按状态枚举排序，不要依赖某次运行的偶然结果。

延伸问答

分组后还需要每组最大金额怎么办？

可以使用 Collectors.maxBy，并在输出层处理 Optional。若要同时保留明细和统计，建议把需求拆成两个明确的结果对象，避免让一个 Map 承担互相冲突的生命周期。

什么时候普通 for 循环更合适？

需要多个字段一起累加、对异常输入做精细分支，或需要严格控制对象分配时，普通循环往往更直白。Stream 的价值是表达归约关系，不是替代所有循环。

最后的落地清单

先按最终消费方式选择 List、counting() 或 summingLong()；再确认 JDK 版本是否支持所用收集器；最后用空集合、未知键、大数据量和并行对照样本复查结果。只要把“是否需要明细”这一个问题问清楚，groupingBy 的内存取舍通常就不会再靠猜。