java stream 本身不支持在一次遍历中既过滤又统计不同条件的匹配数量；虽可通过 peek() 配合原子变量实现，但违背函数式编程原则、影响可读性与性能，推荐使用两次独立 stream 或传统循环。
java stream 本身不支持在一次遍历中既过滤又统计不同条件的匹配数量；虽可通过 peek() 配合原子变量实现，但违背函数式编程原则、影响可读性与性能，推荐使用两次独立 stream 或传统循环。
在 Java 开发中，常需对对象集合进行条件筛选（如保留满足 x && y 的元素），同时统计另一组无关条件（如 !x && z）的出现次数。直觉上希望“只遍历一次”以提升效率，但需谨慎权衡代码正确性、可维护性与实际性能收益。
不推荐的单 Stream 方案（仅作技术说明）
借助 peek() 的副作用机制，配合线程安全的 AtomicInteger，可在流处理过程中同步计数：
AtomicInteger isNotXandZCounter = new AtomicInteger(0);
List<myclass> filteredClasses = myClasses.stream()
.peek(clazz -> {
if (!clazz.isX() && clazz.isZ()) {
isNotXandZCounter.incrementAndGet();
}
})
.filter(clazz -> clazz.isX() && clazz.isY()) // 注意：原问题中 MyClass::isX() 是错误写法，应为 clazz.isX()
.toList();
int count = isNotXandZCounter.get();</myclass>
⚠️ 关键警告：
- peek() 设计初衷是用于调试，不应承载业务逻辑或产生副作用；
- 此写法破坏了 Stream 的无状态性与可并行性（若启用 parallelStream()，结果不可预测）；
- 实际性能未必优于两次流操作——JVM 对短链 Stream 优化成熟，且额外的分支判断与原子操作反而增加开销；
- 代码可读性差，违反“单一职责”原则，后续维护者易误改逻辑。
推荐方案：清晰、安全、高效
✅ 方案一：两次独立 Stream（最简洁、推荐）
语义明确、无副作用、易于测试和并行化（必要时可加 .parallel()）：
List<myclass> filteredClasses = myClasses.stream()
.filter(clazz -> clazz.isX() && clazz.isY())
.toList();
long isNotXandZCount = myClasses.stream()
.filter(clazz -> !clazz.isX() && clazz.isZ())
.count(); // 返回 long，注意类型</myclass>
✅ 方案二：单次 for 循环（最高性能 & 最佳控制）
当数据量极大或性能敏感时，传统循环更直观、零对象开销、便于调试：
List<myclass> filteredClasses = new ArrayList();
int isNotXandZCount = 0;
for (MyClass clazz : myClasses) {
if (clazz.isX() && clazz.isY()) {
filteredClasses.add(clazz);
}
if (!clazz.isX() && clazz.isZ()) {
isNotXandZCount++;
}
}</myclass>
? 总结建议：
- 优先选择“两次 Stream”，代码简洁、符合函数式风格、JVM 优化充分；
- 若需极致性能或复杂状态管理，用显式循环；
- 避免在 peek() 中做条件计数——它不是为此设计，且会埋下隐性 Bug；
- 始终以可读性、可维护性、可测试性为第一目标，微小的遍历开销通常远低于理解副作用的成本。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
