Java Stream 本身不支持“一边过滤一边统计不同条件”的原生操作；虽可通过 peek() + 原子变量实现单流双任务，但违背函数式编程原则、降低可读性与可维护性，推荐明确分离关注点——用两次独立 Stream 操作更清晰、安全且性能相当。
java stream 本身不支持“一边过滤一边统计不同条件”的原生操作；虽可通过 `peek()` + 原子变量实现单流双任务，但违背函数式编程原则、降低可读性与可维护性，推荐明确分离关注点——用两次独立 stream 操作更清晰、安全且性能相当。
在实际开发中，常遇到这样的需求：对一个对象列表（如 List<MyClass>）执行主过滤逻辑（例如 isX() && isY()），同时额外统计另一组条件的匹配数量（如 !isX() && isZ()），且希望避免两次遍历集合。直觉上，单次流处理似乎更“高效”，但需谨慎权衡可读性、正确性与工程实践。
✅ 推荐方案：两次独立 Stream（清晰、安全、高效）
List<MyClass> myClasses = /* 初始化数据 */;
// 主过滤：保留满足 isX() && isY() 的对象
List<MyClass> filteredClasses = myClasses.stream()
.filter(clazz -> clazz.isX() && clazz.isY())
.toList(); // Java 16+，或 collect(Collectors.toList())
// 独立计数：统计满足 !isX() && isZ() 的元素个数
long isNotXandZCount = myClasses.stream()
.filter(clazz -> !clazz.isX() && clazz.isZ())
.count();✅ 优势明显：
- 语义清晰，职责单一，符合单一职责原则；
- 无副作用，线程安全（Stream 操作天然无状态）；
- JVM 对短链 Stream 优化成熟，两次遍历的性能损耗微乎其微（尤其对比对象构造、I/O 或业务逻辑）；
- 易于单元测试、调试和后续扩展（如改为 Collectors.groupingBy 或添加日志）。
⚠️ 不推荐方案：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 的无状态性（stateless）和纯函数特性，导致：
• 并行流（parallelStream()）下结果不可预测；
• 代码难以推理、复用和测试；
• 违反函数式编程核心理念，增加维护成本。
? 总结建议
- 优先选择两次 Stream：现代 JVM 下性能差异可忽略，而代码质量提升显著；
- 若列表极大（千万级+）且性能实测成为瓶颈，再考虑自定义迭代器或 for 循环一次性聚合（但需充分测试并发与边界场景）；
- 切勿为“减少一次遍历”牺牲可读性与可靠性——清晰胜于巧妙，明确胜于隐晦。
最终，优雅的代码不是写得最少，而是让人一眼读懂、放心修改、稳定运行。
