Java Stream teeing 收集器适合哪些双结果场景

我第一次把 Collectors.teeing 用在报表代码里，是因为同一批订单既要算总金额，又要保留订单数。以前的写法通常是先收集成列表，再遍历两次；数据量一大，临时对象和重复遍历就很难解释。我的判断是：如果两个结果都来自同一条 Stream、彼此不需要中途修改元素，teeing 很合适；如果第二个结果依赖第一个结果，或者要复用复杂的中间状态，自定义收集器或普通分步代码反而更直白。

Collectors.teeing 会把每个输入元素同时交给两个下游 Collector，两个下游完成后再用 merger 合成一个最终结果。它从 Java 12 开始提供，适合“同一批数据、两种独立汇总、一个返回对象”的场景。

官方资料：https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/stream/Collectors.html

先把“双结果”拆成两个独立责任

teeing 的核心不是“让 Stream 多跑几遍”，而是把两个下游收集器挂到同一个终端操作上。第一个参数负责结果一，第二个参数负责结果二，最后的 BiFunction 只负责合并已经完成的结果。官方 API 对它的描述也是“composite of two downstream collectors”。

因此我会先问三个问题：两个结果是否消费同一批元素？两个统计是否互不依赖？合并时是否只需要拿到两个最终值？三个答案都为“是”，再考虑 teeing。像“先求平均值，再按平均值决定第二次筛选条件”就不是这个工具最自然的场景。

用一次 collect 同时得到数量与金额

下面的例子把订单数量和金额汇总成一个不可变结果。这里故意让两个下游职责不同：counting() 只数元素，summingLong() 只累加金额；merger 不再遍历订单。

import java.util.List;
import java.util.stream.Collectors;

record Order(String id, int cents) {}
record OrderStats(long count, long totalCents) {}

List orders = List.of(
    new Order("A-101", 1299),
    new Order("A-102", 2500),
    new Order("A-103", 799)
);

OrderStats stats = orders.stream().collect(Collectors.teeing(
    Collectors.counting(),
    Collectors.summingLong(Order::cents),
    // 两个下游都完成后，组装领域结果
    OrderStats::new
));

System.out.println(stats.count());      // 3
System.out.println(stats.totalCents()); // 4598

我觉得这种写法最舒服的地方，是结果类型把业务含义留在了代码里。金额用分为单位，避免示例里引入浮点舍入问题；真实项目中还应按金额模型决定用 long、BigDecimal 还是专用值对象。

下游结果可能为空时，先处理 Optional

teeing 不会替你改变下游 Collector 的空输入语义。比如 maxBy 返回 Optional，空 Stream 就是 Optional.empty()。因此 merger 中不要直接调用 get()，而是把“没有最大值”表达为业务结果。

record PriceRange(java.util.Optional highest,
                  long count) {}

PriceRange range = orders.stream()
    .filter(order -> order.cents() > 1000)
    .collect(Collectors.teeing(
        Collectors.maxBy(java.util.Comparator.comparingInt(Order::cents)),
        Collectors.counting(),
        // maxBy 可能为空，保留 Optional 让调用方显式处理
        (maxOrder, count) -> new PriceRange(
            maxOrder.map(Order::cents), count)
    ));

if (range.highest().isPresent()) {
    System.out.println(range.highest().get());
} else {
    System.out.println("没有符合条件的订单");
}

这里有一个容易忽略的边界：filter 放在 teeing 之前，两个下游看到的是同一批“已过滤订单”；如果只想让其中一个结果过滤，就把 Collectors.filtering 放进对应下游，而不要把 Stream 级别的 filter 写错位置。

分组后做两种统计，才是它的高价值场景

在 groupingBy 里面嵌套 teeing，可以让每个部门各自得到人数和最高薪资。每个分组都会创建自己的下游收集状态，merger 也只接收该分组的两个结果。

record Employee(String department, int salary) {}
record DepartmentStats(long people, java.util.Optional maxSalary) {}

java.util.Map byDepartment = employees.stream()
    .collect(Collectors.groupingBy(
        Employee::department,
        Collectors.teeing(
            Collectors.counting(),
            Collectors.maxBy(java.util.Comparator.comparingInt(Employee::salary)),
            // 每个部门独立合并人数和最高薪资
            DepartmentStats::new
        )
    ));

这类组合适合仪表盘摘要、部门报表和分页结果的汇总字段。不要把 teeing 当成自动提速开关：两个下游都接收每个元素，映射函数或比较器很昂贵时，总成本仍然可能明显增加；并行 Stream 还要确认下游 Collector 的组合语义和结果顺序是否符合要求。

我的选择清单

• 两个结果都来自同一批元素，且只在最后合并：优先考虑 teeing。
• 存在空结果：让下游返回 Optional，或在 merger 里明确默认策略。
• 只过滤一个统计：使用下游的 filtering，不要误伤另一个结果。
• 要保留元素顺序、复杂中间状态或强业务流程：普通多步写法通常更容易维护。

最后可以记成一句话：teeing 适合“同源输入的两个独立观察值”，不适合把一段有先后依赖的业务流程硬塞进一个 collector。先写清两个下游的职责，再决定是否值得用它。

相关问题

teeing 会让 Stream 被消费两次吗？

从使用者角度仍是一次终端 collect；实现上每个元素会分别交给两个下游，因此不能把它理解为只做一份累积工作。

Java 11 项目能直接使用 teeing 吗？

不能直接使用 Java 12 才加入的 Collectors.teeing。需要升级运行与编译环境，或保留兼容 Java 11 的分步收集写法。