我一直觉得，搞 Java 的人如果到现在还没把 Stream 用明白，那基本等于白干了这么多年。JDK8 出来已经很久了，但我在代码评审里见得太多了：有人用 for 循环写一堆样板代码，有人把 Stream 用成了语法糖却不知道背后的惰性求值，还有人因为不懂短路操作在生产上 OOM。Stream 这套 API 不是让你少写几行代码那么简单，它改变的是你对集合数据的处理方式。这篇东西我会把 JDK8 中 Stream 的常用方法从头到尾拆一遍，讲清楚每个操作符到底做了什么、什么时候用、有什么坑，还会带上实际项目里验证过的代码片段。适合刚接触 Stream 的新人，也适合那些用了一段时间但还没系统梳理过的同学，看完你至少能把 filter、map、flatMap、collect、reduce 这一串方法用得明明白白。
1. 先搞清楚 Stream 到底是个什么东西
很多人在使用 Stream 时最大的问题，不是某个方法不会用，而是压根没理解 Stream 的定位。你把它当成集合的工具类，那用起来就会很别扭。Stream 不是数据结构，它不存数据，它是对数据源的一整套计算模型。你可以把它理解成一条流水线：数据从一头进去，中间经过各种加工工位，最后从另一头出来一个结果。这个比喻虽然简单，但能解释 Stream 的绝大多数特性。
1.1 为什么 Java 8 要引入 Stream
在 JDK8 之前，处理一个集合的业务逻辑通常是这样写的：
List<String> names = Arrays.asList("Alice", "Bob", "Charlie", "David"); List<String> result = new ArrayList<>(); for (String name : names) { if (name.length() > 3 && name.startsWith("A")) { result.add(name.toUpperCase()); } }这代码本身没问题，问题在于它把“怎么遍历”和“做什么处理”耦合在了一起。你每加一个条件，就要往 for 循环里塞逻辑，循环会变得越来越长。而且这种写法天然鼓励你在循环里做副作用操作，比如往另一个集合里 add 数据，这在并发环境下很容易出问题。
Stream 的思路是反过来的：你只声明要对数据做什么，遍历过程交给框架。过滤、转换、聚合这些操作全部可以链式组合，代码读起来像在描述业务，而不是像在指挥机器一步步执行。更重要的是，这种声明式的写法让框架有机会做优化。比如 limit(10) 配合 filter，Stream 底层的短路机制可能只遍历前几个元素就够了，而你手写的 for 循环通常会傻傻地把整个集合跑完。
1.2 Stream 的生命周期和惰性求值
Stream 的生命周期只有三步：创建 Stream、中间操作、终止操作。这里有一个新手最容易踩的坑——中间操作不会真正执行。
List<String> list = Arrays.asList("a", "b", "c"); list.stream().filter(s -> { System.out.println("过滤: " + s); return true; });这段代码执行后，控制台什么都不会打印。因为 filter 是中间操作，它只是记录了你要做什么，并没有真正去遍历数据。只有当你调用 forEach、collect、count 这类终止操作时，整个流水线才会被真正触发。
这个设计叫惰性求值。好处很明显：中间操作可以拼成一个完整的执行计划，然后一次性优化执行。比如 filter 和 map 组合时，每个元素只会经过流水线一次，而不是 filter 全部跑完再跑 map。你在写 Stream 链式调用时，其实是在构建一个有向无环图，终止操作触发的瞬间，这个图才会被执行。
这也解释了一个很常见的报错：Stream has already been operated upon or closed。Stream 是一次性的，你用完一个终止操作之后，这个流就废了。想再用，只能重新从数据源创建。这一点和 Iterator 类似，但很多人会惯性以为 stream 是集合的一个视图，可以反复使用，结果就踩坑了。
1.3 五种最常见的创建方式
创建 Stream 的方式五花八门，但实际开发中高频使用的就这几种：
// 1. 从集合创建，最常用 List<String> list = new ArrayList<>(); Stream<String> stream = list.stream(); // 2. 从数组创建 String[] array = {"a", "b", "c"}; Stream<String> stream2 = Arrays.stream(array); // 3. 直接指定元素 Stream<String> stream3 = Stream.of("a", "b", "c"); // 4. 无限流，配合 limit 使用 Stream<Double> randomStream = Stream.generate(Math::random).limit(5); // 5. 迭代流 Stream<Integer> iterateStream = Stream.iterate(0, n -> n + 2).limit(10);Stream.generate 和 Stream.iterate 是不限定长度的无限流，直接用会死循环， 必须配合 limit 或者短路终止操作。// 6. 文件流，读文件行专用 Files.lines(Paths.get("data.txt")).forEach(System.out::println);日常开发里，集合.stream() 占了绝大多数场景。文件流在日志分析、批处理程序里很实用。无限流配合 limit 在生成测试数据时是好东西，我经常用 Stream.generate 造随机订单号去压测。
2. 中间操作：真正干活的那批方法
中间操作是 Stream 里最庞大的一类方法，也是大家口中“Stream 好用”的核心来源。它们不产生最终结果，只负责对数据做加工。加工方式无非几种：过滤、转换、展平、去重、排序、截断。
2.1 filter：最简单也最常用的过滤
filter 接收一个 Predicate 函数式接口，返回 boolean，为 true 的元素才保留。写法很直观：
List<User> users = loadUsers(); List<User> adults = users.stream() .filter(user -> user.getAge() >= 18) .collect(Collectors.toList());我需要提一个很多人没意识到的点：filter 里的条件如果涉及多个字段，不要写成一行非常长的 Lambda，那会严重降低可读性。我习惯把复杂的判定逻辑抽成一个私有的 Predicate 常量，或者单独的方法：
Predicate<User> isAdultAndActive = user -> user.getAge() >= 18 && "ACTIVE".equals(user.getStatus()) && user.getScore() > 60; List<User> result = users.stream() .filter(isAdultAndActive) .collect(Collectors.toList());这样有三个好处：过滤规则可以被复用、链式调用里 filter 后面紧跟的代码一目了然、单元测试可以直接针对 Predicate 写。做代码评审时看到 filter 里塞五六行逻辑的，我一般都会建议拆出来。
2.2 map 和 flatMap：转换与展平要分清
map 是最常用的转换操作。它把一个元素映射成另一个元素，一对一：
List<String> names = users.stream() .map(User::getName) .collect(Collectors.toList()); List<Integer> lengthList = names.stream() .map(String::length) .collect(Collectors.toList());map 的重点在于“元素类型变了”。从 User 变成 String，从 String 变成 Integer，这一路换过去非常顺滑。方法引用在这里特别好用，.map(User::getName) 比 .map(user -> user.getName()) 干净得多。
flatMap 就稍微难理解一点。它的作用是展平，也就是把多个流合并成一个流。典型场景是处理嵌套集合：
// 一个用户有多张订单 List<List<Order>> nestedOrders = users.stream() .map(User::getOrders) .collect(Collectors.toList()); // 如果你想要所有用户的全部订单合并成一个列表（展平） List<Order> allOrders = users.stream() .flatMap(user -> user.getOrders().stream()) .collect(Collectors.toList());可以这样理解：map 是一对一的转换，flatMap 是一对多的拆分合并。每个用户对应多张订单，map 之后的结果是 Stream<List >，相当于每个元素是一个订单列表；flatMap 之后，每个订单列表被拆开、平铺，最终合并成一个 Stream 。数据维度从“用户”降到了“订单”。
flatMap 还有一个常见用法，去空集合：
List<Order> flatOrders = users.stream() .map(User::getOrders) .filter(Objects::nonNull) .flatMap(List::stream) .collect(Collectors.toList());这里 filter(Objects::nonNull) 能过滤掉 null 的订单列表，避免后面 stream() 调用出现 NPE。
2.3 distinct / sorted / limit / skip：去重、排序、截断
这组方法放在一起讲，因为它们通常配合使用，而且都是无状态的中间操作。
distinct 用 equals 方法判断重复元素，去重顺序上保留第一个出现的元素：
List<String> words = Arrays.asList("apple", "banana", "apple", "orange", "banana"); List<String> uniqueWords = words.stream() .distinct() .collect(Collectors.toList()); // 结果: [apple, banana, orange]如果你的元素是自定义对象，记得重写 equals 和 hashCode，否则 distinct 去的是对象引用，基本没用。
sorted 排序有两个重载：一个要求元素实现 Comparable，另一个传 Comparator：
List<Integer> nums = Arrays.asList(3, 1, 4, 1, 5, 9, 2, 6); List<Integer> sorted = nums.stream() .sorted() .collect(Collectors.toList()); // 自定义排序 List<User> sortedUsers = users.stream() .sorted(Comparator.comparing(User::getAge)) .collect(Collectors.toList()); // 多条件排序：先按年龄，再按姓名 List<User> sortedMulti = users.stream() .sorted(Comparator.comparing(User::getAge) .thenComparing(User::getName)) .collect(Collectors.toList());多字段排序是 Stream 里一个高频搜索点。实际项目中我常用的写法是反序加 null 安全：
List<User> sortedUsers = users.stream() .sorted(Comparator.comparing(User::getAge, Comparator.nullsLast(Integer::compareTo)) .reversed() .thenComparing(User::getName, Comparator.nullsLast(String::compareTo))) .collect(Collectors.toList());Comparator.nullsLast 处理排序字段为 null 的情况，reversed 要注意：它会把整个比较器翻转，不是只翻转第一个排序字段。如果你只想让年龄倒序而姓名仍正序，应该这样写：
.sorted(Comparator.comparing(User::getAge, Comparator.nullsLast(Integer::compareTo)).reversed() .thenComparing(User::getName, Comparator.nullsLast(String::compareTo)))这段代码的实际效果是年龄大的在前，年龄相同的按姓名升序排列。这是否符合预期？需要小心。实际上 reversed 作用于整个链式后的比较器，包含 thenComparing 的部分。如果你想只倒序年龄，正确的姿势是对 comparing 部分单独 reversed，再 thenComparing：
.sorted(Comparator.comparing(User::getAge, Comparator.nullsLast(Integer::compareTo)).reversed() .thenComparing(User::getName))关键在于：reversed 是控制整个 Comparator 链的方向，还是只作用于前一个比较器？在 Java 8 的实现里，Comparator.comparing(...).reversed() 返回的是一个反向比较器，在此基础上调用 thenComparing，是给这个反向比较器再添加次级排序规则。也就是说，姓名部分仍按原方向排序，年龄部分反过来。这个细节很容易搞错，所以如果排序规则复杂，我建议先用 Comparator 定义好独立的比较器，再组合使用，逻辑更清晰。
limit 和 skip 负责截断。limit(n) 保留前 n 个，skip(n) 跳过前 n 个：
// 分页效果：每页 20 条，取第 3 页 List<User> page3 = users.stream() .skip(40) .limit(20) .collect(Collectors.toList());skip 和 limit 组合做内存分页没问题，前提是数据量不大。 数据量大时你应该在 SQL 层分页，Stream 分页只是兜底方案。2.4 peek 的调试价值
peek 是一个特殊的方法。它消费元素但不会改变流的结构，一般用来做调试或者记录日志：
List<String> result = Stream.of("one", "two", "three") .filter(s -> s.length() > 2) .peek(s -> System.out.println("过滤后: " + s)) .map(String::toUpperCase) .peek(s -> System.out.println("转换后: " + s)) .collect(Collectors.toList());生产环境提醒一下，peek 里如果写日志，要注意日志级别。我有一次排查线上问题，发现某个接口的日志量突然暴涨，最后定位到是同事在生成环境的 Stream.peek 里打了 info 级别的日志，元素量大时直接把磁盘打满了。peek 不是不能在生产环境用，但取决于它内部的操作是否轻量和安全。
很多人把 peek 和 forEach 搞混。区别在于 peek 是中间操作，惰性执行；forEach 是终止操作，立即触发。如果你想“看一眼元素”，用 peek。如果你想“对每个元素做点事”，用 forEach。
3. 终止操作：让流水线真正跑起来
所有中间操作都不产生结果，只有终止操作才会触发执行流程，产出最终结果或副作用。这个部分是最能体现 Stream 强大之处的内容，尤其是 collect 和 reduce。
3.1 forEach 和 forEachOrdered
forEach 是最简单的终止操作，对每个元素执行一个 Consumer：
users.stream().forEach(user -> System.out.println(user.getName())); // 方法引用写法 users.forEach(System.out::println);在并行流里 forEach 的顺序不保证，forEachOrdered 可以保证顺序。很多人不知道这点。如果你用 parallelStream 并且对输出顺序有要求，记得换成 forEachOrdered：
IntStream.range(1, 10).parallel() .forEach(System.out::print); // 输出顺序不稳定 IntStream.range(1, 10).parallel() .forEachOrdered(System.out::print); // 输出 123456789但我要泼一盆冷水：不要在 forEach 里做复杂业务逻辑。Stream 的语法是函数式的，forEach 里的 Lambda 本质上是在产生副作用。大量在 forEach 里操作外部变量的代码，会让并行流变得非常危险。如果你确实要在遍历时逐个处理数据，传统的 for-each 循环可能更合适，别为了用 Stream 而用 Stream。
3.2 collect：最强大的收尾工具
collect 是 Stream 的核心终结操作，它负责把流里的数据收集到你想要的结果容器里。配合 Collectors 工具类，几乎能搞定日常开发里所有聚合场景。
最基本的三个：
List<User> list = users.stream().collect(Collectors.toList()); Set<String> names = users.stream().map(User::getName).collect(Collectors.toSet()); // 把名字拼接成一个字符串 String joined = users.stream() .map(User::getName) .collect(Collectors.joining(", ", "[", "]")); // 输出: [Alice, Bob, Charlie]Collectors.toMap 需要注意键冲突问题：
// 以 id 为 key Map<Integer, User> userMap = users.stream() .collect(Collectors.toMap(User::getId, Function.identity())); // 如果 key 有重复，必须指定合并规则，否则抛 IllegalStateException Map<Integer, String> nameMap = users.stream() .collect(Collectors.toMap(User::getId, User::getName, (oldVal, newVal) -> newVal));toMap 遇到重复 key 时会抛异常。如果数据源有重复，一定要提前设计好冲突策略。 (lambda 合并旧值新值、保留第一个、取最后一个都可以)分组是 Stream 的拿手好戏。一个 groupingBy 可以替代以前写一整段 map 遍历累加逻辑：
// 按状态分组 Map<String, List<User>> groupByStatus = users.stream() .collect(Collectors.groupingBy(User::getStatus)); // 按状态分组，并统计每个分组数量 Map<String, Long> statusCount = users.stream() .collect(Collectors.groupingBy(User::getStatus, Collectors.counting())); // 按状态分组，再求每个组的平均年龄 Map<String, Double> avgAgeByStatus = users.stream() .collect(Collectors.groupingBy(User::getStatus, Collectors.averagingInt(User::getAge))); // 二级分组：先按状态，再按城市 Map<String, Map<String, List<User>>> groupByStatusAndCity = users.stream() .collect(Collectors.groupingBy(User::getStatus, Collectors.groupingBy(User::getCity)));partitioningBy 是分组的一个特例，按 true/false 分成两组：
Map<Boolean, List<User>> partitioned = users.stream() .collect(Collectors.partitioningBy(user -> user.getAge() >= 18)); List<User> adultsOnly = partitioned.get(true);它比 groupingBy 高效，因为底层只分两个桶，而且返回的 Map 里两个 key 始终存在，不会因为某组为空而缺 key。
自定义 Collector 的场景比较少见，但你需要知道 collect 有三个参数的版本：
List<String> result = stream.collect( ArrayList::new, // 供应商：创建结果容器 List::add, // 累加器：如何把元素放进容器 List::addAll // 组合器：并行时如何合并容器 );3.3 reduce：比 sum 更通用的聚合
reduce 做的是归约操作，把一堆元素合并成一个值。它有很多重载，核心思路是把上一次的计算结果作为下一次的初始值继续参与计算。
求和的经典写法：
// 求和：0 是初始值，sum 是累计值，element 是当前元素 Integer sum = numbers.stream() .reduce(0, (sum, element) -> sum + element); // 更通用的写法：把数字列表拼接成字符串 String result = numbers.stream() .reduce("", (str, num) -> str + "," + num, String::concat);如果你只是想求和，其实直接用 mapToInt 加 sum 更简洁：
int total = users.stream().mapToInt(User::getAge).sum();reduce 的优势在于它更通用。比如你想找列表里最大的元素，可以用：
Optional<Integer> max = numbers.stream() .reduce(Integer::max);注意这里返回的是 Optional。因为如果数据源是空的，reduce 就无从计算。使用 Optional 就是强迫你处理空流的情况，避免出现诡异的默认值。如果你确定流不为空，可以用 orElse 给个兜底：
int maxOrDefault = numbers.stream() .reduce(Integer::max) .orElse(0);3.4 匹配与查找：anyMatch、allMatch、noneMatch、findFirst、findAny
这组方法返回 boolean 或者 Optional，通常用于断言和快速判断。
boolean hasAdult = users.stream().anyMatch(user -> user.getAge() >= 18); boolean allAdults = users.stream().allMatch(user -> user.getAge() >= 18); boolean noneMatch = users.stream().noneMatch(user -> user.getAge() < 0);这三个方法都是短路操作。anyMatch 只要找到一个符合条件的就返回 true，后面的元素就不看了；allMatch 遇到第一个不符合的就返回 false。在处理大列表时性能差异非常明显，这也体现了惰性求值的价值。
findFirst 和 findAny 的区别值得单独说：
Optional<User> first = users.stream().findFirst(); Optional<User> any = users.parallelStream().findAny();findFirst 严格返回第一个匹配的元素，在并行流里需要额外的开销来维持顺序；findAny 在并行流里更快，因为它不关心顺序，返回任何一个匹配元素即可。所以如果你只需要“找一个就行”，优先用 findAny。但需要注意：findAny 在串行流里通常返回第一个，只是规范并不保证这一点。不要依赖这个行为。
findFirst 之前可以先 filter：
Optional<User> firstAdult = users.stream() .filter(user -> user.getAge() >= 18) .findFirst();这段代码还隐藏着短路优化。Filter 不会先把全部元素过滤完再 findFirst，而是每个元素依次经过 filter，一旦遇到满足条件的，findFirst 就返回了，整个流终止。数据量大时，这比你“先过滤成一个完整列表再取第一个”的做法要快得多。
3.5 count、max、min
count 统计元素个数，max 和 min 返回最大最小值：
long count = users.stream().filter(User::isActive).count(); Optional<User> oldest = users.stream() .max(Comparator.comparing(User::getAge)); Optional<Integer> minNumber = numbers.stream() .min(Integer::compareTo);max 和 min 返回 Optional 的原因和 reduce 一样：空流时没有结果。注意 max/min 的参数是 Comparator 而不是元素本身，这一点经常有人搞混。如果没有传 Comparator，则需要元素实现 Comparable，否则编译都过不去。
4. 实战：一个订单系统里 Stream 的常规用法
理论说完了，我直接用一个实际项目里的例子把这些方法串起来。假设你有一个订单列表 Order，字段是 id、userId、amount、status、createTime。当天的业务需求是：筛选出所有金额大于 100 且已支付的订单，按金额倒序，再按创建时间正序，最后统计每个用户的订单总额。
4.1 多字段排序的实现细节
先看排序部分。这里我用的是之前提到的“金额倒序、时间正序”的组合，注意 reversed 的作用范围：
List<Order> orders = loadOrders(); List<Order> sortedOrders = orders.stream() .sorted(Comparator.comparing(Order::getAmount, Comparator.nullsFirst(BigDecimal::compareTo)) .reversed() .thenComparing(Order::getCreateTime)) .collect(Collectors.toList());这段代码的执行逻辑是：先按金额比较器反向（金额大的在前），金额相同时按创建时间正向（时间早的在前）。需要注意 null 处理。如果 amount 为 null，直接比较会抛 NPE。Comparator.nullsFirst 让 null 排在前面，再整体 reversed 后，null 就排到后面了，实际效果是金额非空的排在前面，很符合业务直觉。
然后看按状态过滤和金额过滤：
List<Order> validOrders = orders.stream() .filter(order -> "PAID".equals(order.getStatus())) .filter(order -> order.getAmount() != null && order.getAmount().compareTo(BigDecimal.valueOf(100)) > 0) .collect(Collectors.toList());把两个过滤条件拆成两个 filter 调用，代码更清晰。如果你愿意，也可以合并成一个，但那样 filter 里的条件会变长，可读性下降。我倾向于用两个 filter，因为每个条件都有独立的修改和调整空间。注意这里用了 "PAID".equals(...) 的写法，把常量放在前面，避免 order.getStatus() 为 null 时抛 NPE。这种细节在 Stream Lambda 里特别重要，因为平时的 if 判断你可能习惯了 status.equals("PAID")，但数据为 null 时会直接翻车。
4.2 分组统计用户订单总额
接下来是分组求和，这是 Stream 最能打的场景之一：
Map<Long, BigDecimal> totalAmountByUser = validOrders.stream() .collect(Collectors.groupingBy( Order::getUserId, Collectors.mapping(Order::getAmount, Collectors.reducing(BigDecimal.ZERO, BigDecimal::add)) ));这里面的 collect 链路有点多：groupingBy 按用户分组，mapping 把每个订单的金额取出来，reducing 把这些金额累加。最终得到每个用户的总消费额。
如果你觉得写起来复杂，可以分步走：
Map<Long, List<BigDecimal>> amountByUser = validOrders.stream() .collect(Collectors.groupingBy(Order::getUserId, Collectors.mapping(Order::getAmount, Collectors.toList()))); Map<Long, BigDecimal> totalAmountByUser = new HashMap<>(); amountByUser.forEach((userId, amounts) -> totalAmountByUser.put(userId, amounts.stream().reduce(BigDecimal.ZERO, BigDecimal::add)));两种方式结果一样。第一种更简洁，第二种更容易调试。实际项目里我会先写第二种，确认结果正确后再改写成第一种。不是装，是排查问题的时候分步变量比链式调用更容易观察中间结果。
4.3 toMap 时的坑与正确的合并策略
接着你可能想构建一个订单 id 到订单对象的映射，方便后续快速索引：
Map<String, Order> orderMap = validOrders.stream() .collect(Collectors.toMap(Order::getId, Function.identity()));这里有个隐性问题：如果 id 有重复，这段代码会在运行期抛 IllegalStateException。生产环境里数据可能因为脏数据、历史原因出现问题，比如同一个订单被重复录入。稳妥的做法：
Map<String, Order> orderMap = validOrders.stream() .collect(Collectors.toMap(Order::getId, Function.identity(), (o1, o2) -> o1));第三个参数是个合并函数，这里选择保留第一个出现的订单。你也可以用 (o1, o2) -> o2 保留新的，或者拼一个错误日志：
Map<String, Order> orderMap = validOrders.stream() .collect(Collectors.toMap(Order::getId, Function.identity(), (o1, o2) -> { log.warn("重复订单id: {}", o1.getId()); return o1; }));这样既不会崩，又能看到警告。生产环境代码里，这类隐性防御太重要了。我在评审时看到裸的 toMap 一般会直接打回：没有合理处理 key 冲突的 toMap 就是个隐患。
4.4 把 Stream 结果收集到不可变容器
收集结果之后，你往往要返回给调用方。为了防止后续代码意外修改这个集合，我习惯在 collect 之后包一层不可变容器：
List<Order> result = validOrders.stream() .sorted(...) .collect(Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList));collectingAndThen 可以先收集，再对结果做一次转换。但这也会带来一个潜在问题：如果调用方尝试修改返回的 List，会抛 UnsupportedOperationException。调用方可能不习惯这种限制，所以在接口文档里要说明清楚。这算是防御性编程的一个取舍。
5. 性能与并行流：什么时候该用 parallelStream
很多人一听到性能就说用并行流。这里我劝各位冷静一下。并行流用好了是性能神器，用不好就是事故现场。
5.1 惰性求值与短路优化
Stream 的中间操作是惰性的，这意味着链式调用不会立刻执行。最终在一次遍历中完成所有中间操作，这是它性能好的基础。你写的：
list.stream() .filter(a) .map(b) .limit(10) .collect(toList())底层实现：元素逐个进入流水线，filter 放行后经过 map，然后被 limit 计数，直到收集齐 10 个就停止。集合里剩下的几万个元素根本不会被处理。这种短路优化，是你手写 for 循环很难优雅实现的。
短路操作主要三类：limit、anyMatch/allMatch/noneMatch、findFirst/findAny。它们的共同点是一旦达到目标，整个流就终止。所以如果你要在大集合上做条件判断，优先考虑 these 方法，而不是先过滤成一个完整集合再去判断。
5.2 并行流的正确打开方式
parallelStream 或者 stream().parallel() 可以开启并行处理。底层用的是 ForkJoinPool 的公共线程池。这是最容易踩坑的地方：并行度受公共线程池大小限制，默认是 CPU 核数减一。如果你在 Web 应用里多处同时用 parallelStream，相互之间会争抢线程，甚至可能和 ForkJoinPool 的其他任务互相阻塞。
并行流适合的场景有几个特征：数据量大、元素之间无共享可变状态、处理操作耗时长。典型的例子是 CPU 密集型的计算：
long sum = LongStream.rangeClosed(1, 10_000_000) .parallel() .sum();数据量小的时候千万别开并行。开线程、合并结果的开销远大于单线程遍历的耗时。我有一次跑分比较：处理一千个元素时，parallelStream 比 stream 慢 30% 以上。数据量没有几十万级别，你根本不需要并行。
5.3 什么时候坚决不用并行流
有共享可变状态时，不能用。举个例子：
// 错误示范 List<Integer> list = new ArrayList<>(); IntStream.range(1, 10000).parallel() .forEach(i -> list.add(i));ArrayList 非线程安全，多个线程同时 add 轻则数据错乱，重则抛 ArrayIndexOutOfBoundsException。这个场景应该用 collect：
List<Integer> list = IntStream.range(1, 10000) .parallel() .boxed() .collect(Collectors.toList());另外，操作顺序敏感的场景也别用并行。比如 sorted 在并行流里需要合并多个子结果，开销很大。findFirst 在并行流里为了保持顺序，也可能得不偿失。并行流不是银弹，它是需要你了解底层机制之后才能用好的工具。如果你不清楚它怎么工作，宁可先写串行流，等确实有性能瓶颈，再分析能不能用并行优化。性能优化第一原则是测量，不是猜测。
6. 常见问题与避坑实录
Stream 用久了，总会遇到一些坑。我把自己和同事在生产环境里踩过的问题整理成一个速查表，每个都配了解决思路。
6.1 Stream 已关闭或已被使用
报错信息很典型：java.lang.IllegalStateException: stream has already been operated upon or closed
原因很简单，Stream 是不可复用的。每次执行完终止操作，这个流就消费完了。你拿着同一个 Stream 变量再用，就会报这个错。很多人写代码时把 stream 存在变量里，然后想在不同分支里分别调用，或者两次 collect，结果就翻车。
// 错误用法 Stream<String> stream = list.stream(); long count = stream.count(); // 第一次使用，OK List<String> collect = stream.collect(toList()); // 报错！正确的做法是每次都用数据源重新创建流：
long count = list.stream().count(); List<String> collect = list.stream().collect(toList());Stream 设计成一次性的，是有意的。这样框架才能安全地复用内部资源，做各种优化。你就别再试图复用 Stream 对象了，每次新建，成本极低。
6.2 collect 时出现空指针
这是 Stream 里最常见的 NPE 来源。比如：
List<Order> validOrders = orders.stream() .filter(order -> order.getAmount().compareTo(BigDecimal.ZERO) > 0) .collect(Collectors.toList());如果某个订单的 amount 是 null，这一行会直接抛 NPE。解决思路很直白，把 null 判断前置：
.filter(order -> order.getAmount() != null && order.getAmount().compareTo(BigDecimal.ZERO) > 0)还需要注意 collect 里的下游操作。groupingBy 得到的分组 value 默认是 ArrayList，如果你想让 value 是有序的，可以用：
Map<String, List<User>> sortedGroup = users.stream() .collect(Collectors.groupingBy(User::getStatus, Collectors.collectingAndThen(Collectors.toList(), list -> list.stream().sorted(...).collect(Collectors.toList()))));这种链中套链的写法可读性差，一般我会抽方法出来。但分组之后还要排序的需求非常常见，这张写法可以作为一个参考模板。
6.3 收集到 Map 时的 key 冲突
前面已经说过 toMap 的 key 冲突问题。我再补充一个点：如果你想收集成一个保持插入顺序的 Map，用 LinkedHashMap：
Map<String, User> orderedMap = users.stream() .collect(Collectors.toMap(User::getName, Function.identity(), (oldVal, newVal) -> newVal, LinkedHashMap::new));toMap 第四个参数是 Map 的工厂。默认的 HashMap 不保证顺序，如果你的业务依赖 Map 中的顺序，比如要按用户名的某种排序输出，这里必须指定 LinkedHashMap。这个细节在报表生成、导出场景里尤其重要。
6.4 在 forEach 里修改外部集合
这也是高频错误。很多人这么写：
Map<String, Integer> countMap = new HashMap<>(); list.stream() .filter(...) .forEach(item -> countMap.merge(item.getKey(), 1, Integer::sum));在串行流里这样写勉强能用，但一旦换成 parallelStream，countMap 就不是线程安全的，结果会错，甚至死循环。更隐蔽的问题是：这种写法让 Stream 变成了一个带副作用的循环，失去了函数式编程的意义。
正确的做法是用 collect：
Map<String, Long> countMap = list.stream() .filter(...) .collect(Collectors.groupingBy(Item::getKey, Collectors.counting()));如果确实要在遍历时给外部资源写数据（比如写日志、写文件），一定先确认你用的是串行流，并且里边的操作是幂等的。对于并发场景，用 ConcurrentHashMap 也只能说相对安全，因为 Lambda 里的复合操作（read-modify-write）仍然有竞态条件，不能掉以轻心。
6.5 排序字段为 null 时崩溃
这个坑在用户按时间排序时特别常见。createTime 为 null 的脏数据一旦进到 sorted 里，直接 NPE。正确姿势是 nullsFirst 或 nullsLast：
List<Order> sorted = orders.stream() .sorted(Comparator.comparing(Order::getCreateTime, Comparator.nullsLast(Date::compareTo))) .collect(Collectors.toList());nullsLast 的效果是：createTime 不为空的订单按时间正序排，为空的订单放到最后。这对大多数业务场景是合理的。如果你想让空值排在最前面，用 nullsFirst。需要提醒的是，Comparator.nullsLast 本身不会翻转排序方向，它只是定义空值如何参与比较。如果你同时想要倒序，机制要小心——先 nullsLast 再 reversed，顺序就反了。所以当你组合多个排序维度时，建议每加一个 reversed 就停下来想想：我到底翻转的是整个比较器，还是某一个字段？多测几次，比靠脑子想可靠。
6.6 日志打印导致的内存溢出
前面提到过 peek 里打日志把磁盘打满的情况。这里延伸一下：Stream 在数据量大时，任何中间操作都可能成为性能瓶颈。比如：
list.stream() .peek(item -> log.debug("处理中: {}", item.getDetailJson())) .map(...) .collect(...)如果 log 框架没关闭，debug 日志在千万元素级别时会生成海量字符串，直接把堆内存拖垮。排查这类问题通常要看 GC 日志和堆 dump。我的建议是：peek 里的日志要么在本地开发环境用，要么加采样率，要么干脆用条件日志（先判断 log.isDebugEnabled()）。别让调试代码变成生产事故。
还有一个容易被忽视的陷阱：大型对象列表经过多次 map 后，中间产生大量临时对象。这些对象在 GC 前会占用大量内存。Stream 本身不麻烦，麻烦的是你在链路上反复创建大对象。如果内存吃紧，看看能否用原始类型流 IntStream、LongStream 减少装箱开销。
// 用 IntStream 而不是 Stream<Integer>，减少装箱 int sum = orderList.stream() .mapToInt(order -> order.getAmount().intValue()) .sum();mapToInt 返回 IntStream，是基本类型流，元素是 int 而不是 Integer，避免了大量的自动装箱和拆箱。集合里有几千个对象看不出来，但如果订单量几十万上百万，性能差异会很明显。这一点经常被人忽略。
最后再分享一点我的经验
Stream 写多了之后，我最大的体会是：这个 API 的难点不在方法本身，而在思维方式。你习惯 for 循环里一步步去操作数据，那写 Stream 时就会觉得别扭；一旦你接受“声明要什么，而不是怎么实现”，代码质量会有质的提升。我个人现在写业务代码时，凡是集合的过滤、转换、分组、聚合，默认都用 Stream；凡是需要在遍历过程中和外部系统交互（比如调第三方接口、写数据库）的场景，我会老老实实用 for 循环，把可读性和可控性放在第一位。
还有一个实际建议：在 IDE 里把 Stream 系列方法设成代码模板。我自己的模板是输入“st”自动补全.stream().filter().collect(Collectors.toList())，日常写代码效率提升很明显。再一个，如果你刚开始用 Stream，尽量先用串行流，把每个操作符的行为摸清楚，再考虑 parallelStream。不要一上来就追求并发，先把不踩坑放在第一位。
最后分享一个小技巧：排查 Stream 链式调用问题时，不要盯着整个链子看。把链子拆开，每个中间操作单独提取成一个变量，逐步打印中间结果，比你在脑子里模拟快得多。等确认每步都没问题了，再合并成链式写法。这是我自己调试 Stream 的固定流程，几乎每次排错都能用上。
