Stream.filter 筛选 List 元素方法详解

本文深入解析了 Java Stream.filter 方法在筛选 List 元素时的关键行为与常见陷阱：它不修改原列表、必须通过 collect 显式落地结果，而 toList() 返回的是不可变列表，需可变结果时应选用 toCollection(ArrayList::new)；filter 不自动处理 null，必须显式防御性检查以避免空指针异常；同时强调 Stream 的惰性求值与单次消费特性，提醒开发者警惕重复 collect、缓存 Stream 或在 filter 中执行重操作等性能隐患——掌握这三处易错点（忘 collect、误用不可变列表、忽略 null），才能真正写出健壮高效的函数式代码。

Stream.filter 为什么不能直接修改原 List

因为 Stream.filter 返回的是一个新 Stream，不是原集合的引用，更不会改变原始 List。常见错误是调用完 filter 就以为原列表已被“筛掉”了不符合条件的元素——其实什么都没变。

必须显式收集结果，否则过滤操作根本没落地。典型误写：

list.stream().filter(x -> x > 10); // 没有 .collect()，这行代码毫无副作用

• 必须链式调用 collect(Collectors.toList()) 或其他收集器才能拿到结果
• 原 List 始终不变，这是函数式操作的默认行为
• 如果需要就地修改（不推荐），得用传统 for 循环 + Iterator.remove()

collect 时选 toList() 还是 toCollection(ArrayList::new)

Java 16+ 的 Collectors.toList() 返回的是不可变 List（ImmutableCollections.ListN），一旦后续要 add、remove 就会抛 UnsupportedOperationException。这点常被忽略，尤其在测试或调试中临时往结果里加元素时突然崩掉。

• 要可变列表：用 collect(Collectors.toCollection(ArrayList::new))
• 只读场景（如传参、遍历）：toList() 更轻量，且明确表达“不打算改”
• 注意 toCollection(LinkedList::new) 等写法也合法，按需选择底层实现

空值处理：filter 前要不要先判 null

filter 本身不会自动跳过 null，如果元素可能为 null，而你的谓词（Predicate）里又直接调用了 .equals() 或 .length()，就会触发 NullPointerException。

• 安全写法：把 null 检查放进 filter 条件，比如 filter(x -> x != null && x.startsWith("A"))
• 或者提前用 filter(Objects::nonNull) 过滤掉 null，再接其他逻辑
• 别依赖“数据肯定不为空”——生产环境总有意外

性能陷阱：filter 后立即 collect 还是留到后面

Stream 是惰性求值的，但一旦调用 collect，整个流水线就会从头执行一次。如果反复对同一 Stream 调用 collect（比如误写成两次），会报 IllegalStateException: stream has already been operated upon。

• 每个 Stream 只能被消费一次；重复使用需重新生成：list.stream().filter(...).collect(...)
• 不要为了“复用”而缓存 Stream 对象，它不是可重入资源
• 大数据量下，避免在 filter 中做耗时操作（如远程调用、文件读取），否则性能雪崩

实际用的时候，最常卡住的不是语法，而是忘了 collect、误判了返回集合的可变性、或者没兜底 null —— 这三处不检查，线上跑两小时才暴露问题。

今天关于《Stream.filter 筛选 List 元素方法详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！