Java Stream性能优化需依数据规模、操作类型和环境动态选择：小数据用串行，大数据且计算密集才用并行；优先原始类型流、精简流水线、避免I/O阻塞、合理选终端操作。
Java Stream API 的性能平衡，核心在于不盲目追求“声明式优雅”，也不退回纯手工循环，而是根据数据规模、操作类型和运行环境做动态取舍。关键不是“用不用Stream”，而是“怎么用才不拖慢系统”。
按数据量决定串行还是并行
小数据（通常少于1万条）走串行更稳。并行流启动线程、切分数据、合并结果，这些开销在轻量任务里反而占大头。比如对几百个字符串做简单过滤或转大写，用 list.stream() 就够了；换成 parallelStream() 可能慢20%以上。
大数据且计算密集时，并行才有意义。但得满足两个前提：源结构支持高效分割（ArrayList、数组优先，避开LinkedList、TreeSet），单个元素处理耗时明显（比如含复杂数学运算或JSON解析）。
- 不确定时，用 JMH 做基准测试，对比
stream()和parallelStream()在目标数据集上的耗时 - 避免在 Web 请求中无差别启用 parallelStream()，高并发下容易挤占 ForkJoinPool.commonPool()，拖慢其他请求
用对流类型，绕开装箱拆箱
处理整数、长整型等基础数值时，别用 Stream<Integer>。每次 map、reduce 都要自动装箱/拆箱，百万级数据下 GC 压力和 CPU 缓存失效会明显上升。
立即学习“Java免费学习笔记（深入）”；
改用原始类型流：IntStream、LongStream 或 DoubleStream。它们直接操作栈上或连续内存中的原始值，没有对象创建开销。
- 从数组起步：用
Arrays.stream(ints)得到 IntStream，而不是Arrays.asList(ints).stream() - 生成范围：用
IntStream.range(0, n)替代Stream.iterate(0, i -> i + 1).limit(n)，后者是顺序迭代，无法并行且易溢出
精简流水线，合并逻辑而非堆操作
Stream 的中间操作（filter、map 等）是惰性的，但每加一个，就多一层 Stage 对象和链表跳转。连续调用多个 filter，实际可能遍历多次；而把条件合并进一个 filter，只遍历一次。
例如，筛选“非空且长度大于5且以a开头”的字符串，写成：
.filter(s -> s != null && s.length() > 5 && s.startsWith("a"))
比分开写三个 filter 更快，也更省内存。
- 避免在 map 中做 I/O 或数据库调用——这会让并行流卡死在阻塞上，应改用 CompletableFuture + 自定义线程池
- 需要排序+去重时，先 distinct 再 sorted 比反过来快（distinct 后数据量减少，排序成本下降）
终端操作选得准，结果收得稳
终止操作不只是“收尾”，它决定了整个流水线的执行策略。比如 findFirst() 是短路操作，找到第一个就停；count() 必须扫完整个流。
同样，收集结果时：Collectors.toList() 线程不安全，用在并行流里没问题；但若需保序或高并发写入，考虑 Collectors.toCollection(() -> new CopyOnWriteArrayList()) 或 toConcurrentMap。
- 只要一个值，优先用
findAny()（并行下比 findFirst 开销低），除非业务强依赖顺序 - 求和、计数等聚合，用
mapToInt().sum()或count()，别用reduce()手写，JVM 对前者有专门优化
