Java Stream 怎样避免重复遍历昂贵数据源

如果一个方法把同一个 Stream 保存起来，先统计数量，再统计金额，第二次调用为什么会报错？关键在于：Stream 是一次性消费的流水线，不是可以反复打开的集合。终止操作完成后，当前 Stream 的生命周期就结束了。需要重复遍历时，应保存可重复遍历的源数据，或者保存一个每次都能创建新 Stream 的函数。

官方文档：https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/stream/Stream.html

先看 Stream 为什么只能消费一次

Java Stream 由源、零个或多个中间操作、一个终止操作组成。中间操作通常是惰性的，像 filter 和 map 只是描述要做什么；当调用 count、collect、forEach 等终止操作时，元素才会被遍历。

因此，Stream 对象更像“一次查询计划”，而不是装着数据的容器。Oracle API 明确建议同一个 Stream 只操作一次，复用已经操作过的 Stream 可能抛出 IllegalStateException。即使某些实现没有立刻报错，也不能把未定义的复用行为当成可靠接口。

先排除把同一个 Stream 当集合使用

下面的写法把一个 Stream 引用当成可重复遍历的集合。第一行终止操作完成后，第二行再次使用同一个流水线，常见结果就是状态非法。

Stream source = loadOrders().stream();

// 第一次终止操作已经消费了 source
long paidCount = source.filter(Order::isPaid).count();

// 不要依赖已消费 Stream 的第二次遍历
long totalAmount = source.mapToLong(Order::amount).sum();

这里的问题不是 filter 或 mapToLong 不能组合，而是它们都挂在同一个已经结束的 Stream 上。若两个统计条件不同，最直接的修复是让每次统计都从可重复源创建新的 Stream。

把源或创建函数保存下来

修复重复遍历前，先判断昂贵数据源是什么。若昂贵操作是一次读取文件或一次远程查询，可以把结果物化为集合；若源数据可以安全地重新打开或重新查询，则可以保存 Supplier。两者都遵循同一个原则：每次终止操作使用新的 Stream 实例。

方案一：保存集合，再创建 Stream

数据量在内存预算内、且一次读取后会被多次使用时，集合通常更容易理解。集合本身可重复遍历，orders.stream() 每调用一次都会得到新的 Stream。

List orders = loadOrders();

// 每次调用 stream() 都创建新的 Stream，集合才是可复用源
long paidCount = orders.stream()
        // 只保留已支付订单，不修改原集合
        .filter(Order::isPaid)
        .count();

long totalAmount = orders.stream()
        // 第二次从集合重新创建流水线
        .mapToLong(Order::amount)
        // 用 long 汇总金额，避免把结果写入共享可变变量
        .sum();

这个方案把读取成本集中在 loadOrders()，之后的每次遍历只支付集合遍历成本。代价是集合占用内存，并且集合中的对象可能比后续统计真正需要的字段更多。

方案二：保存 Supplier，每次创建新 Stream

如果数据源本身可以重新生成 Stream，或者希望延迟到真正统计时才读取，可以保存 Supplier>。不要保存已经生成的 Stream，而是保存“生成 Stream 的动作”。

Supplier> freshOrders = () -> loadOrders().stream();

// get() 返回第一个独立 Stream，只服务这一项统计
long paidCount = freshOrders.get()
        // 每个统计都从新实例开始
        .filter(Order::isPaid)
        .count();

// get() 再返回一个新实例，避免复用上一个 Stream
long totalAmount = freshOrders.get()
        // 重新读取或重新创建源数据的代价要提前评估
        .mapToLong(Order::amount)
        .sum();

Supplier 方案的重点不是“免费重复遍历”。如果 loadOrders() 会访问数据库或远程服务，那么每次 get() 都可能产生一次新的 I/O。此时应明确缓存策略、查询一致性和失败重试边界，而不能为了绕过 Stream 生命周期偷偷增加远程请求。

文件流要把资源生命周期一起处理

Files.lines 返回的 Stream 背后可能持有文件句柄。它和基于集合的 Stream 不同，不能只关注“能不能再次遍历”，还要保证使用结束后及时释放资源。需要多次统计时，可以为每次统计重新打开文件，并把每个 Stream 放入独立的 try-with-resources。

static long countWarnings(Path path) throws IOException {
    try (Stream lines = Files.lines(path, StandardCharsets.UTF_8)) {
        // try-with-resources 会在终止操作完成后关闭文件流
        return lines.filter(line -> line.startsWith("WARN ")).count();
    }
}

static long countErrors(Path path) throws IOException {
    try (Stream lines = Files.lines(path, StandardCharsets.UTF_8)) {
        // 第二次统计重新打开文件，不复用已经关闭的 Stream
        return lines.filter(line -> line.startsWith("ERROR ")).count();
    }
}

如果文件很大，又需要多项统计，应先评估是否一次读取并在一个遍历中完成多个结果，或把结果写入合适的中间结构。简单地为每项统计重新扫描文件会增加 I/O；但把文件 Stream 长期保存起来，则会把文件句柄生命周期交给调用者，风险更高。

用选择表决定保存什么

可以把判断顺序固定为：先确认是否真的需要重复遍历，再确认源能否物化，接着估算重新读取的成本，最后检查资源是否需要关闭。这样处理后，Stream 只是一次性消费的工作单元，集合、Supplier 或文件路径才是可以重新获取数据的入口。

常见问题

调用两次 stream() 会不会复用同一个 Stream？

不会。对集合调用 stream() 通常会创建新的 Stream 实例；真正需要避免的是把已经保存的 Stream 变量再次交给终止操作。

把 Stream 收集成 List 后就一定适合重复遍历吗？

不一定。它解决了 Stream 一次消费的问题，但会增加内存占用；还要确认集合快照是否满足业务一致性要求。

Supplier> 能自动缓存读取结果吗？

不能。Supplier 只负责每次提供新的 Stream。若它内部重新访问数据库、文件或网络，每次调用都可能产生新的 I/O，缓存需要由业务代码单独设计。

为什么 Files.lines 不能像集合 Stream 一样直接长期保存？

因为它可能持有文件资源。应缩短 Stream 的使用范围，并用 try-with-resources 确保终止操作后关闭资源。