Java Steam

Java Streams 很好，但别把它当万能锤子

基于 Devoxx 演讲《If Streams Are So Great, Let’s Use Them Everywhere… Right??》整理。
演讲者：Maurice Naftalin、José Paumard。
核心问题：既然 Java Streams 这么优雅，我们是不是应该把它用到所有地方？

1. 开篇：Stream 不是语法糖，而是一种表达方式

Java 8 引入 Stream API 之后，很多集合处理代码一下子变得清爽了。

以前我们会写：

List<String> names = new ArrayList<>();
for (User user : users) {
    if (user.isActive()) {
        names.add(user.getName());
    }
}

现在可以写成：

List<String> names = users.stream()
        .filter(User::isActive)
        .map(User::getName)
        .toList();

后一种代码明显更像是在描述“我要什么”，而不是一步一步命令机器“怎么做”。这就是 Stream 的魅力：它把集合处理从过程式循环，提升成声明式数据流水线。

但这场演讲想讨论的不是“Stream 好不好”，而是另一个更真实的问题：

当 Stream 代码开始变复杂时，它还比循环更好吗？

这个问题非常关键。因为很多团队不是不用 Stream，而是开始把 Stream 当成一种代码洁癖：只要出现 for 循环，就觉得不够现代；只要能链式调用，就硬要写成
Stream。结果本来五行能看懂的循环，变成了十几行嵌套 collector、flatMap、reducing 的函数式迷宫。

代码写成这样，确实现代了，但同事的血压也现代化了。

2. 演讲的核心观点

这场演讲的主线可以总结成一句话：

**Streams 适合表达清晰、线性、无副作用的数据转换；但一旦逻辑需要复杂状态、异常控制、多层嵌套或强烈依赖执行顺序，传统循环往往更直接、更可靠。
**

也就是说，Stream 不是循环的全面替代品，而是集合处理场景中的一种高级表达工具。

它擅长这些事情：

过滤：filter
映射：map
扁平化：flatMap
分组：groupingBy
聚合：counting、summingInt、reducing
排序、去重、截断：sorted、distinct、limit

但它不擅长这些事情：

复杂分支流程
多个可变状态同时推进
checked exception 密集的 IO 逻辑
需要提前返回多个位置的业务流程
为了链式调用而嵌套过深的收集器
依赖共享变量、副作用、外部状态修改的逻辑

Stream 的问题通常不是“能不能写”，而是“写出来之后值不值得”。

3. 为什么 Stream 让代码更清晰

Stream 最大的优势，是把集合处理拆成了几个很清楚的阶段：

数据从哪里来。
中间经历哪些转换。
最后收集成什么结果。

例如，找出所有有效订单的订单号：

List<String> orderNos = orders.stream()
        .filter(Order::isValid)
        .map(Order::getOrderNo)
        .toList();

这段代码的阅读顺序非常自然：

从 orders 开始；
保留有效订单；
取订单号；
收集为列表。

这种场景下，Stream 的优势非常明显。它减少了临时变量，也避免了循环里混杂多种意图。

如果用一句工程化的话来说：

当一段集合处理逻辑可以被表达为“输入集合 -> 若干转换 -> 输出结果”时，Stream 往往是好选择。

4. Stream 的边界：复杂 Collector 会快速降低可读性

Stream 真正容易失控的地方，通常不是 filter 和 map，而是复杂收集器。

比如下面这种代码：

Map<String, Integer> totalQuantityByShop = orders.stream()
        .collect(Collectors.groupingBy(
                Order::getShopCode,
                Collectors.flatMapping(
                        order -> order.getItems().stream(),
                        Collectors.reducing(
                                0,
                                OrderItem::getQuantity,
                                Integer::sum
                        )
                )
        ));

这段代码能工作，但阅读成本已经明显变高。它把分组、展开、映射、归约全部塞进一个表达式里。对于熟悉 Stream 的人来说可以读懂，但读懂不等于好维护。

这时可以考虑换成更朴素的写法：

Map<String, Integer> totalQuantityByShop = new HashMap<>();

for (Order order : orders) {
    for (OrderItem item : order.getItems()) {
        totalQuantityByShop.merge(
                order.getShopCode(),
                item.getQuantity(),
                Integer::sum
        );
    }
}

这段循环不“炫”，但意图很直白：

遍历订单；
遍历订单明细；
按店铺累加数量。

这里的关键不是“Stream vs for 谁更高级”，而是：

当 Stream 的组合成本超过它节省的样板代码时，就该停手。

5. `flatMap` 很强，但嵌套过深会变成阅读负担

flatMap 是 Stream API 里非常重要的操作。它适合把“一对多”的关系压平成一个连续流。

例如，一个订单里有多个商品明细：

1
2
3

List<OrderItem> items = orders.stream()
        .flatMap(order -> order.getItems().stream())
        .toList();

这个场景很适合 flatMap。

但如果你开始写多层 flatMap：

List<Sku> skus = companies.stream()
        .flatMap(company -> company.getShops().stream())
        .flatMap(shop -> shop.getOrders().stream())
        .flatMap(order -> order.getItems().stream())
        .map(OrderItem::getSku)
        .distinct()
        .toList();

这段代码仍然可以接受，因为每一层都是清晰的层级展开。

真正危险的是 flatMap 里继续套复杂条件、异常处理和临时状态：

List<Result> results = sources.stream()
        .flatMap(source -> source.load().stream()
                .filter(this::isValid)
                .flatMap(data -> transform(data).stream()
                        .filter(Result::isEnabled)))
        .toList();

这种代码的问题是，读者必须在脑子里维护多层上下文。函数式写法本来是为了降低认知负担，但嵌套过深后，反而会把逻辑折叠成一团。

判断标准很简单：

如果你需要反复数括号，或者需要把 lambda 拆开才能解释清楚，这段 Stream 大概率已经过度设计。

6. `mapMulti`：某些场景下比 `flatMap` 更自然

演讲中提到一个很有价值的点：有些“一对零或一对多”的转换，用 flatMap 写起来并不舒服，尤其是每个元素最多产生少量结果时。

从 Java 16 开始，Stream 提供了 mapMulti。它和 flatMap 的目标相似，都是把一个元素转换成 0 个、1 个或多个元素，但写法上更偏“推送结果”。

例如，解析一批字符串，只保留合法整数：

List<Integer> numbers = lines.stream()
        .<Integer>mapMulti((line, downstream) -> {
            try {
                downstream.accept(Integer.parseInt(line));
            } catch (NumberFormatException ignored) {
                // 忽略无法解析的行
            }
        })
        .toList();

如果用 flatMap，往往需要返回 Stream.empty() 或 Stream.of(value)：

List<Integer> numbers = lines.stream()
        .flatMap(line -> {
            try {
                return Stream.of(Integer.parseInt(line));
            } catch (NumberFormatException ignored) {
                return Stream.empty();
            }
        })
        .toList();

两者都能实现，但 mapMulti 避免了为每个元素创建一个小 Stream。更重要的是，它在“某个元素可能产出 0 到 n 个结果”的场景里，表达会更直接。

适合考虑 mapMulti 的场景：

每个输入元素通常只产生少量输出；
用 flatMap 需要频繁创建 Stream.empty() 或 Stream.of(...)；
转换逻辑里有轻量分支；
你想避免为了形式上的函数式写法制造额外对象。

不过也别反过来滥用 mapMulti。如果逻辑本身就是清晰的一对多集合展开，flatMap 仍然是更常见、更容易理解的选择。

7. 异常处理：Stream 不喜欢 checked exception

Java Stream 和 checked exception 的关系一直有点别扭。

比如你想在 Stream 里读取文件或调用一个会抛出 checked exception 的方法：

1
2
3

List<Result> results = paths.stream()
        .map(path -> readFile(path))
        .toList();

如果 readFile 抛出 IOException，这段代码就不能直接写。你通常需要在 lambda 里包 try-catch：

List<Result> results = paths.stream()
        .map(path -> {
            try {
                return readFile(path);
            } catch (IOException e) {
                throw new UncheckedIOException(e);
            }
        })
        .toList();

这样能跑，但 Stream 的可读性开始下降。

对于异常逻辑复杂的场景，可以考虑三种策略：

把异常包装成领域结果，例如 ReadResult.success(...) / ReadResult.failure(...)。
把读取逻辑放在普通循环中，显式处理失败路径。
在 Stream 前先完成 IO，Stream 只处理纯数据转换。

经验上，Stream 更适合“纯计算”和“数据转换”。如果一段逻辑本质上是 IO、重试、补偿、日志、告警、降级，那它天然更接近流程控制，用循环通常更诚实。

8. 副作用：Stream 最怕“偷偷改外部变量”

Stream 的一个基本假设是：中间操作最好是无副作用的。

不推荐这样写：

List<String> activeNames = new ArrayList<>();

users.stream()
        .filter(User::isActive)
        .forEach(user -> activeNames.add(user.getName()));

这段代码还不如直接写循环。更好的写法是：

List<String> activeNames = users.stream()
        .filter(User::isActive)
        .map(User::getName)
        .toList();

尤其要小心并行流。下面这种写法在并行流里风险很高：

List<String> names = new ArrayList<>();

users.parallelStream()
        .filter(User::isActive)
        .forEach(user -> names.add(user.getName()));

ArrayList 不是线程安全的，并行写入会导致数据错乱甚至异常。

Stream 的正确姿势是：

不要在流水线里偷偷修改外部状态，而是把结果交给终止操作来收集。

9. 并行流：不是加个 `parallelStream()` 就能提速

parallelStream() 很诱人。它看起来像是免费性能优化：

1
2
3

List<Result> results = list.parallelStream()
        .map(this::calculate)
        .toList();

但并行流是否更快，取决于很多因素：

数据量是否足够大；
每个元素的计算是否足够重；
是否有共享状态；
是否依赖顺序；
数据源是否容易拆分；
收集结果时合并成本是否很高；
当前服务是否已经有线程池、Web 请求线程、虚拟线程等并发模型。

例如，groupingBy 在并行流下可能需要合并多个中间 Map，这个合并成本并不一定便宜。官方文档也提醒过，某些收集器在并行管道中需要执行
key 合并，如果不需要保持顺序，groupingByConcurrent 可能更适合并行场景。

所以并行流的原则是：

先测量，再使用。不要把 parallelStream() 当性能按钮。

在后端业务系统里，尤其是 Spring Boot 服务中，还要额外小心：业务请求本身已经并发，内部再开并行流，可能导致公共 ForkJoinPool
被打满，最终不是提速，而是让整台服务一起“开会”。

10. 什么时候应该用 Stream

适合使用 Stream 的场景：

逻辑是线性的：过滤、转换、收集；
没有复杂副作用；
没有复杂异常处理；
不需要在多个位置提前退出；
不需要维护多个可变状态；
读起来像一句清楚的数据处理说明；
团队成员能轻松读懂。

典型例子：

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

这段代码就很适合 Stream。它表达的是“按状态分组并计数”，没有多余噪音。

11. 什么时候应该回到循环

更适合使用循环的场景：

有多层嵌套分支；
需要多个中间变量协同变化；
需要复杂异常处理；
需要频繁 break、continue、提前返回；
Stream 链已经超过团队可读性阈值；
需要精细控制性能、内存或执行顺序；
业务语义比数据转换更重要。

例如：

SettlementResult result = new SettlementResult();

for (Bill bill : bills) {
    if (bill.isCanceled()) {
        result.addSkipped(bill);
        continue;
    }

    try {
        SettlementAmount amount = calculate(bill);
        result.addSuccess(bill, amount);
    } catch (BusinessException e) {
        result.addFailed(bill, e.getMessage());
    }
}

这种代码用循环就很好。它不是单纯的数据转换，而是一段业务流程。强行 Stream 化，只会让正常分支、跳过分支、异常分支混在一起。

12. 一个实用判断法：三问法

以后写集合处理代码时，可以问自己三个问题：

第一问：这段逻辑能不能用一句话描述？

如果能，比如“过滤有效用户并取出手机号”，适合 Stream。

如果不能，比如“遍历账单，跳过作废单，计算金额，失败要记录原因，成功要累计多个维度”，更适合循环。

第二问：Stream 写法是否比循环更短、更清楚？

不是“更短”就一定更好。真正应该比较的是：

是否减少了无意义样板代码；
是否提升了业务意图表达；
是否降低了阅读成本。

如果 Stream 只是少了几行代码，但多了三层嵌套 lambda，那不算赢。

第三问：以后出 bug 时，好不好断点调试？

这条非常现实。

Stream 不是不能调试，但复杂流水线的调试体验通常不如循环直接。特别是线上问题排查时，循环里的每一步状态都很明确，而复杂 Stream
链经常需要拆开才能看。

所以对于核心资金、结算、库存、风控这类逻辑，可读性和可调试性要优先于写法漂亮。

13. 团队规范建议

结合这场演讲的观点，可以把团队里的 Stream 使用规范定成这样：

谨慎

多层 flatMap。
嵌套 groupingBy 加 mapping、flatMapping、reducing。
在 Stream 中处理 checked exception。
在 Stream 中写复杂业务分支。
使用 peek 做业务逻辑。
在 forEach 中修改外部集合。
未经压测直接使用 parallelStream()。

不推荐

为了消灭 for 循环而强行 Stream 化。
在 Stream 中修改外部可变状态。
在核心业务流程里写难以调试的长链式表达式。
把所有逻辑塞进一个 collect。
在团队大多数人读不懂的情况下炫技。

14. 总结：好的代码不是函数式或命令式，而是合适

这场演讲最有价值的地方，不是教我们多写 Stream，也不是劝我们回到循环，而是提醒我们：

编程范式是工具，不是信仰。

Stream 的确能让很多集合处理代码更优雅、更清晰。但它的优势成立有前提：逻辑要适合被表达成数据流水线。

当逻辑变成复杂业务流程时，循环并不低级。相反，循环可能是更诚实的表达方式。

真正成熟的 Java 代码，不是满屏 Stream，也不是拒绝 Stream，而是知道什么时候使用它，什么时候放下它。

可以记住这条原则：

如果 Stream 让业务意图更清楚，就用它；如果 Stream 只是让代码看起来更高级，就别用。

这大概也是这场演讲标题里那个 “Right??” 的意思：
Streams 很好，但“到处用”这件事，真不一定对。

参考资料

YouTube 视频：《If Streams Are So Great, Let’s Use Them Everywhere… Right??》
https://youtu.be/GwKRRsjfBOA
Devoxx Belgium 2023 演讲简介：
https://devoxx-most-played.vercel.app/
Class Central 对该演讲的课程摘要：
https://www.classcentral.com/course/youtube-if-streams-are-so-great-let-s-use-them-everywhere-right-by-maurice-naftalin-jose-paumard-350615
Tech Talk Replay 对该演讲的摘要：
https://techtalkreplay.com/devops/devoxx_belgium_2024.html
Oracle Java Stream API 文档：
https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/stream/Stream.html
Oracle Java Collectors 文档：
https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collectors.html
Oracle Java Tutorials：Parallelism：
https://docs.oracle.com/javase/tutorial/collections/streams/parallelism.html

Java

#Java #杂谈

Java Steam

https://allendericdalexander.github.io/2026/06/11/java/utils/java-streams-should-we-use-them-everywhere/

作者

AtLuoFu

发布于

2026年6月11日

许可协议

Java Optional 上一篇

人工智能简述：从 ChatGPT 到 AI 时代下一篇

Java Steam

Java Streams 很好，但别把它当万能锤子

1. 开篇：Stream 不是语法糖，而是一种表达方式

2. 演讲的核心观点

3. 为什么 Stream 让代码更清晰

4. Stream 的边界：复杂 Collector 会快速降低可读性

5. flatMap 很强，但嵌套过深会变成阅读负担

6. mapMulti：某些场景下比 flatMap 更自然

7. 异常处理：Stream 不喜欢 checked exception

8. 副作用：Stream 最怕“偷偷改外部变量”

9. 并行流：不是加个 parallelStream() 就能提速

10. 什么时候应该用 Stream

11. 什么时候应该回到循环

12. 一个实用判断法：三问法

第一问：这段逻辑能不能用一句话描述？

第二问：Stream 写法是否比循环更短、更清楚？

第三问：以后出 bug 时，好不好断点调试？

13. 团队规范建议

推荐

谨慎

不推荐

14. 总结：好的代码不是函数式或命令式，而是合适

参考资料

5. `flatMap` 很强，但嵌套过深会变成阅读负担

6. `mapMulti`：某些场景下比 `flatMap` 更自然

9. 并行流：不是加个 `parallelStream()` 就能提速