Java Stream 惰性求值为什么让日志没输出：中间操作与终止操作的触发边界

排查一段 Java 过滤逻辑时，最容易让人误判的现象是：filter 里面明明写了日志，程序却一行也没打印。代码没有报错，集合也不是空的，断点就是进不去。多数时候问题不在日志框架，而在 Stream 还没有被真正消费。

没有终止操作时，日志为什么完全不出现

先看一个足够小的现场。下面的代码把大于 10 的订单编号筛出来，还在 filter 里打印每个被检查的编号：

List orders = List.of(7, 12, 18);

Stream candidates = orders.stream()
    .filter(id -> {
        System.out.println("check=" + id);
        return id > 10;
    });

System.out.println("pipeline-created");

运行结果只有 pipeline-created。filter 没有被调用，不是因为 Stream 把日志吞了，而是这条链还停在“描述如何处理数据”的阶段。中间操作返回的仍然是一个 Stream，它把规则保存下来，却没有主动向源集合要元素。

从代码执行时间线定位真正的触发点

把终止操作补上，再按时间顺序看调用链：

List result = orders.stream()
    .filter(id -> {
        System.out.println("check=" + id);
        return id > 10;
    })
    .map(id -> id * 100)
    .toList();

System.out.println(result);

这次 toList() 会向上游请求数据，Stream 才从 orders 依次取值。每个元素先经过 filter，通过后再进入 map，最终被收集到结果列表。也就是说，日志所在的 lambda 并不是定义时执行，而是终止操作消费到对应元素时执行。

短路终止操作会改变日志数量

调试时另一个误区是把日志条数当成集合总大小。下面的 findFirst 找到第一个偶数后就可以停止：

Optional firstEven = Stream.of(3, 5, 8, 10, 12)
    .filter(value -> {
        System.out.println("check=" + value);
        return value % 2 == 0;
    })
    .findFirst();

日志通常只会出现 3、5、8。10 和 12 没有被检查，并不意味着它们被错误过滤，而是终止条件已经满足。anyMatch、allMatch、noneMatch 也有类似行为：它们在结果已经确定时停止向上游取数据。

因此，问题现场应先区分“完全没有日志”和“日志少于预期”。前者优先检查是否缺少终止操作；后者要看终止操作是否具备短路语义，以及数据顺序是否稳定。

流只能消费一次，调试代码不要复用同一个对象

Stream 不是可重复读取的集合。一次终止操作完成后，再次调用终止操作会抛出 IllegalStateException: stream has already been operated upon or closed：

Stream stream = orders.stream().filter(id -> id > 10);
long count = stream.count();
List list = stream.toList(); // IllegalStateException

调试时如果既想看数量又想打印结果，不要缓存一个 Stream 等着重复使用。保留 orders 这样的源集合，然后按需重新创建流：

long count = orders.stream().filter(id -> id > 10).count();
List list = orders.stream().filter(id -> id > 10).toList();

如果构建流的过程很复杂，可以把“创建流”提取成返回 Stream 的方法，但要明确每次调用都重新绑定新的源，别把已经运行过的 Stream 放进成员变量长期保存。

把惰性求值问题写进排查清单

1. 先确认链末端有没有 toList、collect、forEach、count 或匹配类终止操作。
2. 再判断终止操作是否短路，日志少可能是正常停止。
3. 检查 lambda 是否真的被当前这条链引用，避免只创建流水线却没有执行它。
4. 确认没有重复消费同一个 Stream；需要多次验证时从源集合重新创建。

这份顺序比直接在 filter 里加更多日志更有效。先确定流水线有没有启动，再解释处理了多少元素，最后才去怀疑条件表达式或数据内容。

常见问题

调用 stream() 后就会遍历集合吗？

不会。stream() 只创建一个顺序流，必须接上终止操作才会触发源集合遍历。

peek 能不能用来做正式业务逻辑？

不建议。peek 主要适合临时观察流水线，是否执行仍取决于终止操作，短路操作也可能让它只看到部分元素。

为什么 count() 有时看不到 filter 里的日志？

正常的引用流会执行过滤逻辑，但编译器或运行时可能利用已知大小等特性优化遍历。需要稳定调试时，优先用明确的收集结果或断点确认，不要把日志当作唯一证据。

并行流会不会改变这个执行规律？

不会改变“中间操作等待终止操作”的基本规律，但执行顺序和线程归属可能不同。本文的日志顺序判断只适用于顺序流。

收尾：先确认流水线启动，再判断条件是否正确

Java Stream 的惰性求值不是隐藏的异步执行，而是把遍历时机交给终止操作。遇到日志不出现，先看链条是否真正被消费；遇到日志数量不全，再看是否短路；遇到第二次执行报错，则回到源集合重新创建流。把这三个边界分开，Stream 的“没执行”和“只执行了一部分”就不会再混成一个问题。