Java Stream 的 filter 为什么看起来没运行？

下面这段代码调用了 filter，但控制台什么都没有：

java 复制代码

names.stream()
     .filter(name -> {
         System.out.println("检查：" + name);
         return name.length() >= 4;
     });

原因是：filter 是中间操作，只描述过滤规则，不会立刻遍历数据。 Java Stream 会等到终结操作需要结果时，才开始处理这条流水线。

补上终结操作，流水线才开始工作

java 复制代码

List<String> result = names.stream()
        .filter(name -> {
            System.out.println("检查：" + name);
            return name.length() >= 4;
        })
        .toList();

toList() 需要得到过滤后的列表，因此会触发流水线。每个元素经过 filter 判断，符合条件的进入结果列表。collect(...)、count()、forEach(...)、findFirst() 和 anyMatch(...) 也都是终结操作。

可以把 Stream 管道理解成一张待执行的处理说明：

text 复制代码

数据源 → filter → map → toList
                       ↑
                 终结操作触发遍历

filter、map、sorted 等中间操作返回的仍然是 Stream；它们可以继续接在一起，形成完整流程。只有当终结操作需要一个结果或动作时，数据源才开始被访问。这种惰性让多个步骤可以融合处理，也避免了还没需要结果就提前计算。

终结操作不一定检查所有元素

有些终结操作只要找到足够的信息就能结束。例如：

java 复制代码

boolean hasLongName = names.stream()
        .filter(name -> name.length() >= 4)
        .anyMatch(name -> name.startsWith("J"));

anyMatch 找到一个符合条件的元素后，就已经能确定结果为 true，后面的元素不必继续处理。findFirst() 也会在找到第一个匹配元素后停止。因此，"终结操作触发遍历"不等于"每个操作都会把整个数据源跑完"。

别用 peek 的副作用证明业务逻辑执行过

Stream 允许实现根据结果优化流程。比如一个已知大小的列表直接调用 count()，如果某个中间步骤不影响元素数量，实现可能跳过这一步。因此，下面的调试输出不保证每次都会出现：

java 复制代码

long count = names.stream()
        .peek(System.out::println)
        .count();

不要把 peek 或 filter 中的打印、写文件、更新外部计数器当成业务动作的可靠执行点。filter 应负责判断元素是否保留；需要对每个结果执行动作时，使用明确的终结操作，或把副作用移到流水线之外。并行流下还要额外考虑动作是否会被多个线程同时调用。

排查"代码没跑"的三步

找终结操作 ：末尾是否有 toList()、collect()、count()、forEach() 等？
确认结果是否需要全部元素 ：findFirst()、anyMatch() 可能提前停止，这是正常的短路行为。
检查副作用放置位置 ：不要靠 peek() 或中间操作中的副作用保证业务动作发生。

记住：中间操作搭管道，终结操作取结果；管道会按需执行，不保证每个元素、每个中间步骤都被访问。

参考：Java 21 Stream API、Java 21 Stream 包说明。