Java Stream API 是为集合提供声明式数据处理的惰性求值工具，filter/map等中间操作不立即执行，需终端操作触发；collect(Collectors.toList())返回新列表，取首元素应优先用findFirst()；小数据、索引依赖、复杂状态更新等场景不宜使用Stream。
Java 的 Stream API 不是用来替代集合的，而是为已有集合（如 List、Set）提供一种声明式、不可变、支持链式调用的数据处理方式。它真正简化的是「遍历 + 过滤 + 转换 + 聚合」这类常见操作，但前提是理解它的惰性求值和终端操作触发机制。
为什么 filter() 和 map() 不会立刻执行
Stream 是惰性求值的：所有中间操作（如 filter()、map()、sorted()）只是组装执行计划，不产生结果也不遍历数据。只有遇到终端操作（如 collect()、forEach()、count()）时，整个流水线才一次性从头到尾拉取并处理元素。
常见误用：
- 只写
list.stream().filter(x -> x > 5)却没接collect()或其他终端操作 → 什么都不会发生，也得不到结果 - 在
map()中修改原集合元素（比如user.setName("new")）→ 虽然能运行，但违背函数式思想，且无法保证线程安全
collect(Collectors.toList()) 是最常用但最容易出错的终点
这是把流转回 List 的标准写法，但要注意：
立即学习“Java免费学习笔记（深入）”；
- 返回的是新集合，不是原
List的视图或副本 —— 修改结果列表不影响原集合，反之亦然 - 如果流为空，
collect()仍返回一个空ArrayList，不会返回null - 不要用
stream().collect(Collectors.toList()).get(0)取首元素 → 应该用findFirst()，避免构造完整列表再取索引，浪费内存和时间
示例对比：
// ❌ 低效：构建完整列表只为取第一个 Listresult = list.stream().map(String::toUpperCase).collect(Collectors.toList()); String first = result.get(0); // ✅ 高效：短路操作，找到即停 Optional first = list.stream().map(String::toUpperCase).findFirst();
什么时候不该用 Stream？
不是所有循环都适合改造成流。以下情况建议保留传统 for 或增强 for：
- 需要基于索引操作（如“跳过前 3 个，处理第 4 到第 10 个”）→
Stream没有原生索引支持，强行用AtomicInteger或IntStream.range()反而难读 - 循环体里有复杂状态更新（比如累计多个变量、break/continue 逻辑嵌套深）→ 流式写法会变得晦涩，甚至被迫用外部变量破坏无状态原则
- 处理极小集合（比如长度恒为 2~5 的配置列表）→
Stream创建开销可能比直接遍历还高 - 需要精确控制异常传播（如某个元素解析失败要立即抛出）→
Stream中抛出受检异常需包装，且默认不中断整个流（除非用forEachOrdered+ 外部标志）
parallelStream() 并不自动加速一切
并行流底层用的是 ForkJoinPool.commonPool()，但它只对满足以下条件的操作才明显提速：
- 数据量大（通常 > 10000 元素）
- 每个元素处理耗时较长（如 IO、正则匹配、加密计算）
- 操作无状态、无共享可变变量、无强顺序依赖（
reduce要求结合律，forEach不保证顺序）
反例：
// ❌ 并行流在这里几乎没收益，还引入线程调度开销 list.parallelStream().map(String::length).sum(); // ✅ 合理场景：每个元素都要发起 HTTP 请求 urls.parallelStream().map(this::fetchTitle).filter(Objects::nonNull).collect(toList());
另外，parallelStream() 在 Web 容器（如 Tomcat）中可能和主线程共用公共池，导致请求线程被阻塞 —— 生产环境建议显式指定自定义线程池。
