Stream性能优化关键在理解底层机制：小数据量避免parallelStream，CPU密集型才适合并行；优先用原始类型流、专用收集器、预设容量集合，警惕装箱、副作用和闭包捕获。
Stream API用得顺手，不代表性能就一定好。面试中常被问到“为什么用了Stream反而变慢”，关键不在会不会写，而在懂不懂底层机制和调优逻辑。
别盲目并行——先看数据规模和操作类型
parallelStream()不是银弹。小数据量（比如几百条）用并行流，线程调度和拆分合并的开销反而远超收益；CPU密集型操作（如map里做复杂计算）才适合并行，而I/O或同步阻塞操作（如调用远程接口、加锁处理）并行后可能更慢甚至出错。
- 建议：单次处理
- 测试时对比parallelStream()和stream()的耗时，用System.nanoTime()实测，别靠感觉
- 注意：并行流默认使用ForkJoinPool.commonPool()，若业务已有自定义线程池，需显式指定，避免资源争抢
链式操作要精简——中间操作不执行，但影响遍历次数
filter、map、sorted这些中间操作是惰性的，但组合不当会引发多次遍历或额外排序。比如先sorted再filter，等于对全量数据排序后再筛；而filter放前面，能大幅减少后续操作的数据量。
- 原则：尽早过滤（filter前置）、避免重复遍历（不用toList()再stream()）
- 慎用sorted()：无索引场景下是O(n log n)，且必须等上游全部完成才能开始，破坏流水线；能用TreeSet预排序或数据库order by就别在Stream里排
- distinct()底层依赖HashSet去重，大数据量时内存和哈希冲突成本高，可考虑先分组聚合或用外部缓存替代
收集器选对了，性能差一截
collect(Collectors.toList())看着简单，但底层是动态扩容ArrayList，高频小对象易触发多次数组复制；Collectors.toMap()遇到key重复直接抛异常，线上容易崩。
- 明确容量时，用Collectors.collectingAndThen(Collectors.toList(), list -> new ArrayList(list))不如直接用new ArrayList(initialCapacity) + forEach手动add
- 需要去重+保持顺序？用Collectors.toCollection(LinkedHashSet::new)比distinct()更可控
- 聚合统计优先用Collectors.summingInt、averagingDouble等专用收集器，比mapToInt().sum()少一次装箱/拆箱
警惕隐式装箱和引用逃逸
int值用mapToLong()比map(x -> (long)x)快，因为后者触发自动装箱生成Long对象；Stream.of(array)传入基本类型数组会自动装箱成Object[]，应改用Arrays.stream(intArray)。
- 原始类型优先用IntStream/LongStream/DoubleStream，避免Integer/Long对象创建和GC压力
- lambda中引用外部局部变量，若该变量后续被修改，可能引发意料外的闭包捕获行为；尽量用final或只读变量
- 不要在Stream里做日志打印、HTTP调用等副作用操作，既难测试又破坏函数式语义，还可能因并行导致日志乱序或重复请求
不复杂但容易忽略——调优不是堆API，而是理解数据流怎么走、资源怎么耗、瓶颈在哪卡。
