Java Stream API的流转换操作会因对象创建、有状态操作、装箱/擦除及并行适配引入性能损耗；应合并filter、避免sorted/distinct滥用、优先使用基本类型流、谨慎启用并行。
Java Stream API 的流转换操作（如 filter、map、sorted、distinct 等）在提升代码可读性的同时，确实会引入不同程度的性能损耗。这些损耗并非来自“写法不优雅”，而是由底层机制、数据特征和操作类型共同决定的。关键在于识别哪些转换真正拖慢了执行，以及如何有针对性地规避。
中间操作本身不执行，但构建成本真实存在
虽然 filter、map 等中间操作是惰性的，不会立刻遍历数据，但每次调用都会创建新的 Stream 实例，并封装一个操作节点。链式调用越长，流水线对象越多，内存开销和对象创建压力就越明显。
- 连续多个
filter可合并为单个条件判断，减少节点数量 - 避免无意义的中间操作，例如
.map(x -> x)或冗余的.stream().stream() - 对百万级数据，10 层中间操作比 3 层在初始化阶段多分配约 30% 的临时对象
有状态操作是性能主要瓶颈
像 sorted()、distinct()、limit()（配合无序流时）、skip() 这类操作需要持有全局或部分数据视图，无法边流边处理，必须缓存、排序或去重，带来显著内存与时间开销。
-
sorted()时间复杂度为 O(n log n)，且需一次性加载全部元素——大数据量下极易触发 GC 或 OOM -
distinct()底层依赖HashSet，对大对象或未重写hashCode()的类，哈希冲突会加剧性能衰减 - 若只需前 N 个最大值，用
StreamSupport.stream(spliterator, false).sorted().limit(N)不如先用PriorityQueue预筛选更高效
装箱与类型擦除带来的隐性损耗
泛型 StreamIntStream、LongStream）则绕过装箱。混用会导致严重性能损失：
立即学习“Java免费学习笔记（深入）”；
- 将
IntStream错误转成Stream<integer></integer>再toArray()，比直接IntStream.toArray()慢 4–5 倍 - 使用
mapToInt替代map+Integer::intValue，可避免每元素一次自动拆箱 - 收集到数组时，优先用特化方法：
int[] arr = intStream.toArray()，而非stream.mapToInt(...).boxed().toArray(Integer[]::new)
并行转换未必加速，反而可能拖累
调用 parallel() 后，所有中间操作都需适配并发模型。但并非所有转换都能受益：
-
sorted()在并行流中仍需全局归并，线程间协调开销常超过计算收益 -
distinct()并行版需跨分段合并哈希表，小数据集下比串行还慢 - 若源数据结构是
LinkedList或Stream.iterate()，分割效率极低，并行几乎无效 - 建议阈值：仅当数据量 ≥ 10 万且操作为 CPU 密集型（如字符串解析、数值计算）时再启用并行
