stream api 是声明式、不可变、支持并行的数据处理抽象，不修改原集合、不存储数据，仅描述操作；适合一次性链式转换、中等数据量、需延迟或并行场景，不适合反复遍历、极简操作、极致性能或需break/continue的场景。
Java 的 Stream API 不是用来替代集合操作的“新语法糖”，而是为**声明式、不可变、支持并行**的数据处理提供统一抽象。它不修改原集合，也不存储数据，只描述“要做什么”，这点必须先明确。
什么时候该用 Stream，什么时候不该用？
适合用 Stream 的场景：一次性的链式转换（如过滤+映射+聚合）、逻辑较清晰、数据量中等（10^4 ~ 10^6）、需要延迟执行或并行加速。
不适合的场景：
- 需要频繁反复遍历同一数据（Stream 只能消费一次）
- 操作极简单（比如单次 for 循环取最大值），用 Stream 反而增加开销
- 对性能极度敏感且已知集合很小（JVM 优化后传统循环可能更快）
- 需要中途 break/continue 控制流（Stream 没有原生支持，得靠 anyMatch/findFirst 曲线救国）
filter + map + collect 是最常用组合
这是绝大多数业务中清洗和组装数据的主干流程。注意三者顺序不能乱，且中间每一步都返回新 Stream，不改变原始集合。
常见错误：
- 在 filter 中写副作用逻辑（如 System.out.println()），应改用 peek()（仅用于调试）
- 忘记终端操作（如漏掉 collect() 或 forEach()），整个流不会执行
- 用 collect(Collectors.toList()) 后又想修改返回的 List，结果抛 UnsupportedOperationException（某些收集器返回的是不可变容器）
List<String> names = users.stream()
.filter(u -> u.getAge() >= 18)
.map(User::getName)
.filter(Objects::nonNull)
.map(String::toUpperCase)
.collect(Collectors.toList());
Stream.iterate 和 Stream.generate 容易误用
这两个是创建无限流的工厂方法，但若不加限制直接 collect，会 OOM。必须配合 limit() 或短路终端操作（如 findAny()）。
立即学习“Java免费学习笔记（深入）”；
iterate 适合有明确起始和迭代规则的序列（如斐波那契、步进数列）；generate 更适合无状态随机值或对象构造。
-
Stream.iterate(0, n -> n + 2).limit(5)→[0, 2, 4, 6, 8] -
Stream.generate(UUID::randomUUID).limit(3)→ 三个随机 UUID - 错例：
Stream.iterate(1, i -> i * 2).collect(Collectors.toList())→ 死循环
并行流（parallelStream()）不是银弹
它底层用 ForkJoinPool.commonPool()，默认线程数等于 CPU 核心数减一。好处是大集合计算密集型任务可提速；坏处是：
- 非线程安全的操作（如往 ArrayList 里 add）会导致数据丢失或异常
- 小集合或 I/O 密集型任务反而更慢（线程调度开销 > 计算收益）
- 调试困难（堆栈混乱、执行顺序不确定）
真正安全的并行操作：只读数据 + 无状态中间操作 + 使用线程安全的收集器（如 Collectors.toConcurrentMap）
List<Integer> result = numbers.parallelStream()
.map(n -> n * n)
.filter(n -> n % 2 == 0)
.collect(Collectors.toList()); // 这里 collect 是线程安全的流的真正复杂点不在语法，而在理解「延迟执行」「一次性消费」「无状态函数」这三个约束。写完一段流操作，先问自己：它是否可读、可测、可中断、不依赖外部状态——如果任一是否定的，就该考虑换回传统循环或拆成多个小流。
