并行流在小数据量（如<1000元素）时反而更慢，因线程开销大；应先filter后sorted以减少排序数据量；数值计算宜用IntStream等原始类型流，避免Integer装箱导致GC压力。
Java Stream API用起来很顺手，但某些写法会在运行时悄悄拖慢系统——尤其在高负载或大数据量场景下。识别这些性能预警指标，比事后调优更有效。
数据量小却硬上并行流
当集合元素少于1000个，还调用parallelStream()或stream().parallel()，大概率会变慢。线程创建、任务拆分、结果合并的开销远超计算收益。JMH实测显示：处理500个字符串的map + filter链，并行流平均比顺序流慢30%～50%。
- 判断依据：终端操作耗时突然升高，且CPU用户态时间占比低、上下文切换次数明显上升
- 建议：对
size() 的集合，默认走顺序流；若必须并行，改用自定义<code>ForkJoinPool并限制并行度
重复使用同一原始流
Stream只能消费一次。若把同一个流对象反复传给多个collect()或count()，会抛IllegalStateException；而开发者常误用“重用”逻辑，比如缓存流引用再多次调用，实际触发的是重复构建+重复执行，造成冗余计算。
- 典型误写：
Stream<T> s = list.stream().filter(...); s.collect(...); s.count(); - 建议：需要多次计算时，用
Supplier<Stream<T>>封装流创建逻辑，或先toList()落地再复用
有状态中间操作出现在长流水线前端
sorted()、distinct()、limit()等有状态操作需缓存全部或部分数据才能继续下游，若放在filter之前，会让本可提前过滤掉的无效元素也进入排序/去重阶段，白白放大内存与时间开销。
立即学习“Java免费学习笔记（深入）”；
- 反例：
stream().sorted().filter(x -> x > 100).map(...) - 正例：
stream().filter(x -> x > 100).sorted().map(...)（先筛再排） - 额外提示：
sorted()时间复杂度为O(n log n)，大数据集慎用；如只需前N个，改用limit(N)配合自然顺序或预排序数据源
装箱/拆箱密集型数值计算
用Stream<Integer>处理百万级整数求和、统计，会因频繁自动装箱产生大量短生命周期对象，引发GC压力。同样逻辑换成IntStream，吞吐量可提升2～5倍，内存分配减少90%以上。
- 预警信号：年轻代GC频率陡增，堆中
Integer实例占比异常高 - 建议：数值运算优先选用
IntStream.range()、Arrays.stream(int[])、mapToInt()等原始类型流API
