Java Stream核心是延迟执行与函数式流水线，中间操作仅组装指令，终端操作才触发计算；Stream只能消费一次；调试用peek()；distinct/groupingBy/topN/并行流等有特定适用边界和性能陷阱。
Java Stream 是大厂面试高频考点，不只考“怎么用”，更看重你是否理解其设计思想、适用边界和性能陷阱。
Stream 的本质不是集合操作工具
很多候选人把 Stream 当成 for 循环的替代写法，这是误区。Stream 的核心是延迟执行 + 函数式流水线：中间操作（filter/map/sorted）只是组装指令，终端操作（collect/forEach/count）才真正触发计算。
- 写完 filter.map.collect 就以为执行了？错——collect 前整条链都没跑
- 重复调用同一个 Stream？会抛 IllegalStateException，Stream 只能消费一次
- 想调试中间结果？别用 System.out::println，改用 peek()，它专为调试设计且不影响流逻辑
面试最爱问的三类典型题
大厂常围绕“业务场景 + Stream 限制 + 手动优化”出题，比如：
- 去重并保留首次出现顺序：distinct() 可以，但底层依赖 hashCode/equals；若对象无合理重写，得用 collect(Collectors.toMap(...)) 手动控制
- 分组后取每组 topN：groupingBy + mapping + collectingAndThen 套娃组合，但要注意 mapValues 是 List，需再用 limit 或 sorted 截取
- 并行流真比串行快？：只有数据量大、操作 CPU 密集、无共享状态时才值得开 parallel()；IO 操作、有锁逻辑、小数据集反而更慢
容易被忽略的关键细节
面试官常从边角切入考察基本功：
立即学习“Java免费学习笔记（深入）”；
- Stream.of(null) 不报错，但 map 中解包 null 就 NPE；Optional 配合 map 或 orElseThrow 更安全
- Collectors.groupingBy() 默认返回 HashMap，若需有序结果，得显式传入 LinkedHashMap::new 作为 supplier
- reduce 有三个参数的重载（identity, accumulator, combiner），并行时 combiner 必须满足结合律，否则结果不可靠
怎么答才算“懂”而不是“会”
别背 API，重点说清选择依据：
- 为什么这里用 toList() 而不是 toSet()？——看是否允许重复、是否需要去重语义
- 为什么用 Collectors.counting() 而不是 mapToInt(i -> 1).sum()？——前者复用 collector 状态，后者多一次装箱/拆箱
- 如果需求是“统计每个分类下价格 > 100 的商品数”，优先 groupingBy + filtering + counting，而不是先 filter 再 groupingBy——减少遍历次数
不复杂但容易忽略：Stream 是语法糖，不是银弹。该用传统循环时就别硬套，面试官想听的是你权衡后的判断，不是炫技。
