本文介绍在 Java Stream 中实现“一次遍历、双重目标”的技巧：既按条件 A 过滤元素，又统计满足条件 B（不参与过滤）的元素数量；重点分析 peek() 的副作用用法及其替代方案，并强调生产环境中的最佳实践。
本文介绍在 java stream 中实现“一次遍历、双重目标”的技巧：既按条件 a 过滤元素，又统计满足条件 b（不参与过滤）的元素数量；重点分析 `peek()` 的副作用用法及其替代方案，并强调生产环境中的最佳实践。
在 Java 开发中，我们常需对集合进行条件筛选（如保留 isX() && isY() 为 true 的对象），同时统计另一组独立条件（如 !isX() && isZ()）的出现次数。直观做法是使用两个独立 Stream——分别调用 filter().collect() 和 filter().count()，但这会遍历源列表两次，带来不必要的性能开销。
理论上，可通过 Stream.peek() 在流处理过程中“旁路”执行计数逻辑，实现单次遍历：
AtomicInteger count = new AtomicInteger(0);
List<MyClass> filteredClasses = myClasses.stream()
.peek(clazz -> {
if (!clazz.isX() && clazz.isZ()) {
count.incrementAndGet();
}
})
.filter(clazz -> clazz.isX() && clazz.isY())
.toList();
int isNotXandZCounter = count.get();该写法利用 peek() 的副作用机制，在每个元素被处理前检查并递增计数器，随后再应用主过滤逻辑。虽然语法上可行，但强烈不推荐在生产代码中使用，原因有三：
- ✅ 违背函数式编程原则：Stream 设计初衷是无状态、无副作用的声明式操作；peek() 本用于调试，滥用会破坏可读性与可测试性；
- ⚠️ 线程安全风险：若流启用并行（.parallelStream()），AtomicInteger 虽保证原子性，但整体逻辑仍易受竞态影响，且 peek 执行顺序不保证；
- ? 性能未必更优：JVM 对短链式 Stream 优化成熟，两次遍历的开销通常远小于 peek 带来的分支预测失败与缓存失效。
更健壮的替代方案如下：
立即学习“Java免费学习笔记（深入）”；
-
显式迭代（推荐）：语义清晰、性能可控、易于调试：
List<MyClass> filtered = new ArrayList<>(); long isNotXandZCounter = 0; for (MyClass clazz : myClasses) { if (clazz.isX() && clazz.isY()) { filtered.add(clazz); } if (!clazz.isX() && clazz.isZ()) { isNotXandZCounter++; } } -
Collector 自定义聚合（高级）：封装过滤与计数逻辑于一个 Collector，兼顾声明式风格与单一遍历：
var result = myClasses.stream() .collect(Collector.of( () -> new ResultContainer(), // 持有 filteredList + counter (acc, clazz) -> { if (clazz.isX() && clazz.isY()) acc.filtered.add(clazz); if (!clazz.isX() && clazz.isZ()) acc.counter++; }, (a, b) -> { a.filtered.addAll(b.filtered); a.counter += b.counter; return a; }, acc -> acc ));
总结：尽管技术上可用 peek() 实现单流双目标，但其副作用本质与 Stream 设计哲学相悖。优先选择显式循环或定制 Collector——它们更可靠、更易维护，也更符合 Java 生态对清晰性与稳健性的长期倡导。
