Java Stream效率疑问：为何flatMap(Optional::stream)并非比filter+map低效？

为什么flatMap(Optional::stream)不存在预想的高开销 #

不少开发者看到“为每个Optional生成独立流再做扁平映射”的描述，会默认这个操作的成本很高：毕竟如果每个流都是带独立管道、Spliterator、状态机的重量级对象，频繁创建销毁确实会带来可观的开销。但从JDK的实际实现来看，这套逻辑的开销被压缩到了几乎可以忽略的水平：

• 空Optional调用stream()时，直接复用Stream.empty()的全局静态单例，不会产生任何新的堆对象分配。
• 持有值的Optional调用stream()时，返回的是基于极简单元素Spliterator的轻量包装：没有独立的流管道、没有生命周期管理逻辑，本质就是对持有值的薄封装，成本和把值放进一个长度为1的数组没有本质差异。
• flatMap的底层实现不会把这些子流当成独立管道逐个初始化、关闭：它只是在遍历源流的每个元素时，直接从对应的子流包装里把内部的元素拉取出来，传给同一个下游处理管道，中间没有流节点组装、资源回收的额外开销。

你担心的“多流结构带来的后台成本”，实际上在实现层面根本不存在。

两种实现的优劣对比 #

我们把两种等价实现放在一起对比：

• 实现1：optionals.flatMap(Optional::stream)
• 实现2：optionals.filter(Optional::isPresent).map(Optional::get)

性能差异 #

两种写法的核心处理逻辑完全等价：对每个Optional元素判断是否存在值，对有值的元素提取内部的T类型值传到下游，空值直接跳过。经过JIT的内联优化后，两者的指令数差异仅在纳秒级，只有在每秒处理千万级以上元素的极端压测场景下才能测出可量化的性能差，普通业务代码完全感知不到区别。

写法选择 #

• flatMap(Optional::stream)是Java 9官方文档推荐的写法：它把“判空、取值”的逻辑收敛在Optional自身的方法里，不需要手动拆分两步操作，链式调用的连贯性更好，后续追加其他流操作时不需要调整代码结构。
• filter(Optional::isPresent).map(Optional::get)是Java 8时期的通用兼容写法：对不熟悉Java 9流特性的开发者来说逻辑更直白，没有“嵌套流”的心理负担，和存量Java 8代码库的兼容性更好。

什么时候filter+map会更优 #

只有在对延迟极致敏感的低延迟系统中，你可以通过基准测试清晰测量出纳秒级的性能差时，filter+map因为少了单元素流的薄包装开销，会有极其微小的优势。但这个优势远达不到“本质更优”的程度，更多是极致性能场景下的取舍。

内容的提问来源于stack exchange，提问作者ATW