Java Stream流核心实战：从集合处理到声明式编程

1. Stream流到底解决了什么问题

我最早接触Stream流的时候，其实是很不以为然的。原因很简单：以前用for循环加if判断，集合操作也就几行代码，为什么非要去学一套新的API？但直到我接手一个业务模块，里面全是层层嵌套的for循环处理订单数据，各种临时集合并来并去，代码读得人头皮发麻，我才意识到Stream流真正的价值。它不是为了替代for循环而存在的，而是为了把“怎么遍历”和“做什么处理”彻底分开，让我们把注意力放在数据本身，而不是机械地写迭代逻辑。如果你每天都在和List、Map打交道，并且被代码里的循环嵌套和临时变量折磨过，那Stream流绝对值得你花半小时认真搞懂。

1.1 传统集合操作的三座大山

在没有Stream之前，我们处理集合数据基本上就是三板斧：for循环、临时变量、if判断。比如我有一个用户列表，要筛选出年龄大于18岁的用户，按年龄升序排序，最后只要前三个人的名字。传统写法大概是这样：

List<User> allUsers = loadUsers(); List<User> temp = new ArrayList<>(); for (User user : allUsers) { if (user.getAge() > 18) { temp.add(user); } } temp.sort(new Comparator<User>() { @Override public int compare(User o1, User o2) { return Integer.compare(o1.getAge(), o2.getAge()); } }); List<String> result = new ArrayList<>(); for (int i = 0; i < Math.min(3, temp.size()); i++) { result.add(temp.get(i).getName()); }

这段代码表面上看没什么问题，但仔细想想，它的可读性和可维护性都很差。嵌套的for循环让逻辑变得支离破碎，临时变量temp在中间扮演着“传递者”的角色，你得从头到尾读一遍才能明白这条数据到底经历了什么。如果需求从“取前三个”变成“跳过前两个再取三个”，或者再加一个性别条件，修改起来很容易出现漏改或者改错的地方。更麻烦的是，这种代码一旦出现在多个地方，几乎无法复用，只能复制粘贴再改改，久而久之代码腐烂的速度会非常快。

1.2 声明式编程带来的思维转变

Stream流则让我们换了一种思考方式：我们不关心数据是怎么被遍历的，只关心我希望对数据做什么。还是上面那个需求，用Stream写出来是这样：

List<String> result = allUsers.stream() .filter(u -> u.getAge() > 18) .sorted(Comparator.comparing(User::getAge)) .limit(3) .map(User::getName) .collect(Collectors.toList());

这段代码就像一句流畅的自然语言：筛选出年龄大于18的，按年龄排序，取前三个，提取姓名，收集成列表。每一行都只负责一件事，没有临时变量，没有迭代索引，没有循环控制。这就是声明式编程的核心思想——你告诉系统“做什么”，而不是“怎么做”。

这种思维转变的影响是深远的。当你习惯了Stream之后，你会发现自己写业务代码时会主动去思考“数据链路”，而不是一上来就写for循环。而且Stream提供了一整套标准化的操作算子，筛选、排序、去重、映射、分组、聚合都可以像搭积木一样组合。它不是为了炫技，而是为了让代码更像一份“可执行的业务说明书”。对于维护者来说，看到Stream代码，基本一眼就能明白数据处理流程，这比从一堆循环里“考古”舒服太多了。

1.3 Stream和集合的本质区别

初学者最容易混淆的一点是：Stream到底是不是一种新的集合？答案：不是。Stream不存储数据，它是对数据源的一层“视图”或者说是“流水线描述”。集合管的是数据的内存布局和存取，Stream管的是数据的计算和转换。打个比方，集合就像仓库里的货物，Stream就是一条自动化的传送带，货物在上面经过筛选、加工、分拣，最后到达终点。传送带本身不产生货物，它只是描述“货物怎么流转”。

这个本质区别带来了几个重要特性：第一，Stream只能被消费一次，就像传送带上的货物，走过去就没了，不能回头。第二，Stream有“惰性求值”的特性，只有当你需要最终结果时，前面的所有操作才会真正执行。第三，Stream可以是无限的，只要你提供的生成器能一直产出数据，Stream就能一直工作，而集合必须在内存里装下所有元素。理解这些特性，是后续用好Stream的基础。

2. 三步走：Stream使用的核心框架

用Stream处理数据，不管需求多复杂，都逃不开一个固定套路：创建Stream、中间操作、终止操作。这三步一个都不能少，少了一步就不是完整的Stream使用流程。我见过不少同事一开始搞不清中间操作和终止操作的区别，结果代码写了一半，要么没输出，要么报错，或者流被提前关闭。所以这一节我们先把框架搭起来，后面再往里填细节。

2.1 第一步：拿到Stream（数据源）

Stream流不会凭空产生，它必须基于一个数据源。数据源可以是集合、数组、文件行、甚至是一个生成函数。最常见的来源是集合：

List<String> list = Arrays.asList("a", "b", "c"); Stream<String> stream = list.stream(); // 串行流 Stream<String> parallelStream = list.parallelStream(); // 并行流

数组可以用Arrays.stream()或者Stream.of()。注意Stream.of接收的是一个可变参数，所以可以传数组，也可以直接传多个元素：

String[] arr = {"a", "b", "c"}; Stream<String> stream1 = Arrays.stream(arr); Stream<String> stream2 = Stream.of("a", "b", "c"); Stream<String> stream3 = Stream.of(arr);

除了这些“现成”的数据源，Stream还支持无限流，用Stream.iterate和Stream.generate来创建。比如产生一个从0开始的递增整数序列，配合limit就能得到一个有限长度的流：

Stream<Integer> numbers = Stream.iterate(0, n -> n + 1).limit(10);

这里要注意，如果直接stream.forEach一个不限制长度的无限流，程序会一直跑下去直到内存溢出，这就是为什么无限流必须配合limit之类的短路操作使用。

2.2 第二步：中间操作（构建流水线）

拿到Stream之后，就可以给它接上各种“加工环节”，这些加工环节就是中间操作。中间操作的特点是：它们返回的仍然是一个Stream，所以可以链式调用。常见的有filter（过滤）、map（映射）、flatMap（扁平化）、sorted（排序）、distinct（去重）、limit（截取前N个）、skip（跳过前N个）。

中间操作本身不会触发计算，它只是在记录“将要做什么”。你可以把它想象成你在给装修公司列需求清单：先贴瓷砖，再刷墙，再装灯。清单列多少项都行，但只要工人没开始干活，房间就还是老样子。代码里也是这样，你写了十个中间操作，如果不接一个终止操作，这十个操作一个都不会执行。

理解这一点特别重要。我见过有人写代码时在中间操作里调用了System.out.println，想打印看看数据，结果发现控制台什么都没有，还以为代码写错了。其实不是写错了，而是整个流还没被“激活”。

2.3 第三步：终止操作（触发计算）

终止操作是流水线的“终点”，它标志着整个Stream处理流程的结束。终止操作会触发之前所有的中间操作真正执行，并且产出一个最终结果。这个结果可以是一个集合、一个数字、一个布尔值，甚至是没有返回值的foreach。

最常见的终止操作是collect，它负责把流中的数据收集成一个集合或其他容器。还有count计数、reduce归约、anyMatch/allMatch/noneMatch匹配判断、findFirst/findAny查找、forEach遍历。每一个终止操作都会让整个流“跑起来”，跑完之后这个流就报废了，不能再用。

这里有一个隐藏的坑：如果你不小心对一个已经执行过终止操作（也就是消费过）的Stream再次调用终止操作，会抛出IllegalStateException: stream has already been operated upon or closed。因为流就像一次性的传送带，货物已经全部走完了，你不可能再让它跑一遍。所以要重复使用同一份数据做多个不同统计，最保险的做法是每次从数据源重新生成Stream，而不是复用同一个Stream变量。

2.4 惰性求值：为什么中间操作不立即执行

很多人第一次接触Stream时都觉得奇怪：既然中间操作不执行，那我链式写一堆还有什么意义？这就引出了Stream最核心的机制——惰性求值。惰性求值的好处是极大的性能优化空间。Stream可以把多个操作合并成一次遍历，而不是像传统写法那样，筛一次、排一次、截一次，每步都产生一个中间集合。

我们来看一个例子：集合里有10000个元素，需要筛选出符合条件的100个，然后取前10个。如果使用Stream，中间操作会串成一个管道，数据元素逐个通过管道，而不是先把所有符合条件的元素筛出来放进一个新列表，再从头遍历排序。这样内存占用更小，执行效率也更高。

但惰性求值也带来了一个“副作用”：中间操作里的逻辑不会按你写代码的时间顺序执行，而是在终止操作真正触发时，数据元素才会逐个流过管道。这意味着，如果你在中间操作里写了带有副作用的代码（比如修改外部变量、打印日志），你无法提前预知它什么时候执行，也容易踩到并发或者性能的坑。所以一个实践原则是：中间操作保持“纯净”，只做数据变换，不要在里面做任何对外部世界有影响的事情，除非你明确知道自己在干什么。

3. 手把手实战：从零写一个Stream处理流程

理论讲得再多，不如落地写一个完整实例。这一节我们就用实际场景，把Stream使用步骤走一遍。我会把每一步的代码、输出和思考都展示出来，方便你照着敲也能得到同样结果。

3.1 场景定义：筛选用户并统计

假设我们有两个类，一个普通用户类和一个VIP用户类，现在有一个包含全部用户的列表，需要做这么几件事：筛选出年龄大于18岁的普通用户；按照年龄从小到大排序；跳过前2个，取接下来的3个；提取姓名；最终收集成一个List。同时，我们还想统计一下这些被选中的用户年龄总和。

这个场景综合了筛选、排序、跳过、截取、映射、收集、归约多个操作，足以演示Stream的标准流程。我们先定义用户类：

public class User { private String name; private int age; public User(String name, int age) { this.name = name; this.age = age; } public String getName() { return name; } public int getAge() { return age; } @Override public String toString() { return "User{name='" + name + "', age=" + age + "}"; } }

然后准备测试数据：

List<User> users = new ArrayList<>(); users.add(new User("张三", 16)); users.add(new User("李四", 22)); users.add(new User("王五", 19)); users.add(new User("赵六", 30)); users.add(new User("孙七", 25)); users.add(new User("周八", 17)); users.add(new User("吴九", 28));

3.2 创建Stream的几种姿势

我们已经有了List<User>，创建串行流最简单的方式就是users.stream()。但如果你的数据源不是集合而是数组，或者你想把多个独立的元素合并成一个流，就需要用到其他创建方式。

这里补充一个实用技巧：当你想测试一段Stream代码，又不想搭建完整的数据源时，直接用Stream.of("a", "b", "c")是最快的。但要注意，Stream.of可以传一个数组，却不会把数组里的元素展开成多个元素（如果你传入的是整个数组，它只会当成单个元素）。想要展开数组，得用Arrays.stream(arr)。这两个API的行为差别，我在刚学时踩过坑，这里特别提醒一句。

回到我们的场景，直接users.stream()就行。如果你想要并行流，可以调用users.parallelStream()，或者对已经创建的users.stream()调用.parallel()方法。并行流我们后面会专门讲，现在先用串行流保持逻辑简单。

3.3 组装操作链的要点

现在的核心代码就是一条链：

List<String> names = users.stream() .filter(u -> u.getAge() > 18) .sorted(Comparator.comparing(User::getAge)) .skip(2) .limit(3) .map(User::getName) .collect(Collectors.toList());

这里我有一个经验：操作链的顺序不是随便写的，它直接影响结果和性能。比如skip和limit的顺序、filter和sorted的顺序，都需要想清楚。你说“跳过前2个”，是说跳过“筛选后的前两个”，还是“所有用户中的前两个”？这个歧义必须靠操作顺序来消除。上面代码是先筛选出年龄大于18的，然后按年龄排序，排序之后整条流已经是有序的，然后跳过前2个，截取接下来的3个，再提取姓名。

如果你是先skip再filter，结果就会完全不一样，因为你先跳过了原始列表的前两个用户，再筛选年龄，这通常不是业务想要的结果。所以我一直建议大家把filter这类“筛选性”操作尽量往前放，一方面可以提前减少数据量，另一方面也符合业务逻辑顺序。

3.4 终止操作与结果收集

collect(Collectors.toList())是终止操作，它把流中的元素收集到一个List里。除了toList，Collectors工具类还提供了toSet、toMap、joining、groupingBy等等。这里先演示最简单的收集。

如果我们还想统计选中用户的年龄总和，可以用reduce或者mapToInt配合sum：

int totalAge = users.stream() .filter(u -> u.getAge() > 18) .sorted(Comparator.comparing(User::getAge)) .skip(2) .limit(3) .mapToInt(User::getAge) .sum();

注意这里用mapToInt把用户转成年龄的整型流，然后调用sum()，这是终止操作。也可以写map(User::getAge).reduce(0, Integer::sum)，但mapToInt直接返回IntStream，更高效。

最后把两段代码合在一起，运行结果输出：先筛选出年龄大于18的用户，分别是李四22、王五19、赵六30、孙七25、吴九28。排序后是王五19、李四22、孙七25、吴九28、赵六30。跳过前2个（即王五和李四），剩下孙七25、吴九28、赵六30。取前3个，提取姓名，得到[孙七, 吴九, 赵六]，年龄总和是83。这个结果可以对照着Excel手算一遍，验证逻辑完全一致。

4. 常用操作深度解析与避坑清单

掌握了通用步骤，接下来我们深入抠一抠每个常用操作的细节。这些细节在官方文档里都有，但很多坑是文档里不会写的，只有真跑过一遍才知道。

4.1 map和flatMap，别再傻傻分不清

map和flatMap是Stream里出现频率极高的两个操作，也特别容易搞混。map是“一对一”的映射，每个输入元素都产生一个输出元素，流的长度不变，只是元素类型变了。比如把User变成String，就是把用户对象映射成姓名。

flatMap是“一对多”的扁平化映射，每个输入元素可以产生零个、一个或多个输出元素，这些输出元素会被“摊平”到同一个流中。最典型的场景是：你有一个单词列表，想把它拆分成一个个字母。如果只用map，你会得到一个“流中的流”，每个单词对应一个字母流；而flatMap可以把这些字母流合并成一个单一的字母流。

举一个具体的例子：

List<String> words = Arrays.asList("hello", "world"); // 用map得到的是Stream<Stream<String>> words.stream().map(w -> Arrays.stream(w.split(""))) .forEach(s -> s.forEach(System.out::print)); // 用flatMap得到的是Stream<String> words.stream().flatMap(w -> Arrays.stream(w.split(""))) .forEach(System.out::print);

我建议你在本地跑一遍这两个代码，观察输出差异。你会直观地看到flatMap把多个流“拍平”成了一个流。在实际开发中，处理嵌套集合（比如List<List<String>>、树形结构展平）时，flatMap几乎是唯一优雅的解法。

4.2 filter、limit、skip的配合使用

filter是最基础的筛选操作，它接收一个Predicate函数式接口，返回布尔值，只让满足条件的元素通过。但是filter和limit配合时，有一个性能细节值得注意：limit(n)在找到n个元素后会“短路”，不再继续消耗流中的元素。这意味着，如果你在一个很大的列表上先filter再limit，只要前面拿到了足够数量的元素，后面的元素根本不会被遍历。这个特性在处理无限流时是救命的设计。

skip和limit是反义兄弟，skip(n)会丢弃前n个元素，然后继续处理剩余元素。两者经常配合实现“分页”效果，比如每页20条，第3页就是skip(40).limit(20)。但要注意，skip和limit在并行流下的行为是不确定的，因为并行执行时无法确定元素的顺序。如果你需要严格的分页顺序，请先将流变为串行流，或者提前排序。

还有一个经验教训：filter条件中如果有副作用，比如打印日志，那么limit导致的“短路”可能会让你观测到的日志数量比预期少，这是正常的，不要把它当bug来排查。

4.3 collect收集器的进阶玩法

collect是Stream里最强大的终止操作，它接收一个Collector。很多初学者只知道Collectors.toList()，其实Collectors里藏着大量好用且易错的方法。

先说toMap，这个坑最多。Collectors.toMap(Function keyMapper, Function valueMapper)在遇到重复key时会直接抛IllegalStateException: Duplicate key。比如你有一个用户列表，你想把用户ID映射到用户对象，理论上ID是唯一的，但如果数据里有脏数据导致ID重复，整个Stream就直接炸了。解决方案是提供第三个参数，合并策略：

Map<String, User> map = users.stream() .collect(Collectors.toMap(User::getName, u -> u, (oldValue, newValue) -> newValue));

这个第三个参数的含义是：当key冲突时，用哪个值。上面写法是“保留新值”。你也可以写成(a, b) -> a保留旧值，或者(a, b) -> { throw ... }来表示发现重复就报错。

groupingBy分组是另一个高阶玩法，它可以把流中的元素按某个属性分组，得到一个Map<K, List<T>>。比如按年龄分组，就能得到“19岁的列表”“22岁的列表”等等。它还可以配合下游收集器做二次操作，比如统计每组的数量Collectors.counting()、求每组的最大年龄Collectors.maxBy(...)。这种写法比手写for循环加if判断要简洁太多。

partitioningBy是groupingBy的特例，它把结果分成两组，key永远是true和false。这个特别适合“满足条件/不满足条件”的二分场景，比如通过年龄判断是否成年，一个方法直接得出两组数据，效率极高。

4.4 并行流parallelStream：性能双刃剑

看到parallelStream这个名字，很多人会下意识觉得“并行肯定比串行快，那我全用并行”。这是一个典型的性能误区。并行流底层使用了一个共享的ForkJoinPool线程池，默认线程数是CPU核心数减1。如果你的数据量只有几百上千，并行流带来的线程切换开销可能比串行还慢，实测中很多场景并行流性能是负优化。

并行流另一个大坑是线程安全。如果在map或filter里访问了共享的可变变量（比如一个普通的ArrayList），并行流会并发写入，导致数据错乱甚至抛出并发异常。我见过一个线上事故，就是用parallelStream().forEach(list::add)向一个非线程安全的List里添加数据，结果数据量不对，查了很久才发现是并行写入的锅。这种场景应该用Collectors.toList()来收集结果，它内部会保证线程安全。

还有一点，并行流里使用findAny通常比findFirst快，因为在并行模式下findAny不需要保证顺序，可以更快地返回一个结果。如果你是取“任意一个匹配元素”，findAny更合适；如果业务要求“第一个”，那只能用findFirst，并且要考虑串行化保证顺序。

5. 真实项目中的Stream最佳实践

这一节我们不谈API语法，聊一聊在真实Java项目里，Stream到底该怎么用才不至于把自己和同事坑了。毕竟写代码不是考试，优雅和可维护才是第一位的。

5.1 集合转Map的三大坑

第一个坑就是前面提到的重复key。第二个坑是value为null导致NPE。当你用Collectors.toMap映射value，如果某个元素的value是null，HashMap本身是允许null值的，但Collectors.toMap在内部会先对value调用Objects.requireNonNull，所以遇到null会直接抛NullPointerException。这个行为非常隐蔽，因为你的数据是动态的，今天没问题，明天某条数据的一个字段为空，线上就炸了。应对方案是过滤掉null值，或者用Map<String, Optional<...>>来包装value。

第三个坑是HashMap初始化容量。虽然Collectors.toMap会帮你创建一个HashMap，但它没有像new HashMap<>(expectedSize)那样指定容量。如果生成的Map非常大，底层数组会发生多次扩容，影响性能。如果你能预估Map的大小，建议使用重载版本，提供Supplier<Map>参数，比如：

Collectors.toMap(User::getName, u -> u, (a, b) -> a, HashMap::new)

这个HashMap::new参数看起来不起眼，实际在高并发和大数据量场景下，提前指定容量能省下不少扩容开销。

5.2 分组与分区的实际应用

groupingBy在统计报表类的需求里非常好用。比如你有10000笔订单，想统计每个城市的订单数量，用Stream一行搞定：

Map<String, Long> cityOrderCount = orders.stream() .collect(Collectors.groupingBy(Order::getCity, Collectors.counting()));

这个可读性极高，维护者一眼就知道“按城市分组，统计数量”。如果再想求每个城市的订单总额，可以Collectors.summingDouble(Order::getAmount)。还能组合多个指标，用Collectors.summarizingDouble得到平均值、最大值、最小值等一次性全部统计。

partitioningBy特别适合做数据拆分。比如一台捞鱼机，你想把合格品和不合格品分开装箱，partitioningBy(x -> x.isQualified())就返回两个List。真实业务中，比如用户分群、规则命中与否，都可以用它，代码比if循环短太多。

不过要注意，groupingBy并不保证得到LinkedHashMap的顺序。如果你依赖分组结果的顺序（比如按时间先后），需要额外使用LinkedHashMap::new作为mapFactory参数，或者在分组后对entry排序。

5.3 自定义Collector实现复杂归约

当内置Collector不够用的时候，就需要自己写Collector了。这听起来很吓人，其实核心就是实现collect方法中的累加逻辑。Collector接口的四个方法：supplier提供初始容器，accumulator定义如何把元素累加到容器，combiner定义两个容器怎么合并（并行流用），finisher定义最终转换结果。

举个例子，你想把用户的姓名拼接成一个"张三,李四,王五"格式的字符串，同时希望去掉重复名字。用Collectors.toList加distinct加joining其实已经能实现。但如果你想把每个人的名字按照年龄分组后再拼接，就可以自定义收集器避免中间列表的浪费。虽然实际项目中很少需要手写Collector，但理解它的原理对你理解Collectors内部发生了什么很有帮助，排查复杂问题时能多一层判断力。

5.4 性能测试与Stream使用红线

Stream不是银弹。在性能敏感的场景，比如每秒处理百万条记录的核心链路，使用Stream前最好先做基准测试。我自己的实测经验是：简单的过滤和映射操作，Stream比传统for循环大约有10%~20%的性能损失，但这个损失通常可以忽略不计。一旦操作链变长，Stream利用“循环融合”的优势开始显现，它可能反而比多次for循环更快，因为数据可以在一趟遍历里完成全部处理。

但有一条红线必须守住：不要在Stream的中间操作里调用远程接口或者数据库查询。因为中间操作是惰性的，你可能以为它在某个时间点执行，实际却是数据流到最后才触发，很容易造成N+1查询，或者无意识地批量触发外部调用。如果非要和外部的数据交互，请先通过终止操作把数据收集成有限集合，再在集合上循环调用。

还有一条经验：大量嵌套的flatMap会让代码变得很难读。如果一个流程的层级超过三层，我会毫不犹豫地拆分方法或者改用普通循环。Stream的优雅是建立在适度抽象上的，过度抽象就会变成可读性的灾难。

6. 调试与异常排查经验实录

Stream流看起来简洁，但调试起来真不一定轻松。因为中间操作不打印，你很难看到每个环节到底发生了什么。这里分享几个我用过很多次的排查技巧，希望能帮你省下几小时的弯路。

6.1 用peek偷看数据流

peek是一个中间操作，它对每个元素执行一个动作，但又不会改变流的数据。最常见的用途就是打印日志：

users.stream() .peek(u -> System.out.println("原始: " + u)) .filter(u -> u.getAge() > 18) .peek(u -> System.out.println("筛选后: " + u)) .collect(Collectors.toList());

你可以在链路的任何位置插入peek，看这个位置上数据长什么样。peek接收的是Consumer，你还可以在里面做断言、打点，甚至统计元素数量。但记住peek不是为生产代码设计的，它适合临时调试，用完就删。还有一点，peek在并行流里执行顺序是不确定的，打印出来的日志顺序会很乱，这是正常现象，别在上面花时间纠结。

6.2 常见异常及应对

我整理了一个异常速查表，几乎覆盖了Stream开发中最容易碰到的几种异常：

遇到这些异常时，先别急着改代码，先检查你的数据源是不是有脏数据，很多异常其实是数据质量导致的，而不是Stream用错了。

6.3 逻辑错误排查：流不可复用的问题

有一种错误特别隐蔽：代码逻辑没错，但是结果不对。比如你想对一个用户列表先做一次统计，再做一次查询，写了类似这样的代码：

Stream<User> stream = users.stream().filter(u -> u.getAge() > 18); long count = stream.count(); List<String> names = stream.map(User::getName).collect(Collectors.toList());

第二行执行完毕后，count()作为一个终止操作已经把stream消费掉了，第三行再使用这个stream，必然抛出IllegalStateException。这种问题在局部看代码时很容易发现，但一旦嵌入到复杂业务方法里，就会变成“好像没报错，但是结果不对”的隐蔽谜题。我常用的排查手段是：把Stream的创建放到每个操作之前，用“每次新建Stream”作为铁律。上面代码应该改成：

long count = users.stream().filter(...).count(); List<String> names = users.stream().filter(...).map(...).collect(...);

虽然重复创建了Stream，但代码诚实可靠，不会在运行期出幺蛾子。如果你真的需要在一个流上执行多个操作，可以考虑用IntStream收集结果到局部变量，或者提前把处理结果存到一个容器里，再反复读这个容器。

最后再分享一个小技巧：在处理集合的时候，如果你发现自己用了很多次.get()和.set()操作，可能意味着你的数据结构选错了。Stream不是万能药，它只是数据处理的一部分，合理的领域模型和行为设计往往比精巧的流式写法更重要。真正的高手会把Stream用在刀刃上，让代码既简洁又清晰，而不是为了秀操作滥用一堆高级算子。保持对代码的敬畏，工具越多就越要克制，这个道理在Stream身上，一样适用。