并行流并非自动提速，需同时满足单元素处理≥1ms、数据量≥10⁵、高效分片源、无状态操作、纯CPU任务，并经JMH基准测试验证；否则易拖慢性能。
Java Stream API 的并行流（parallelStream() 或 stream().parallel()）不是“开箱即用就更快”的魔法开关。它是否提速，取决于任务类型、数据规模、硬件配置和代码写法。盲目启用反而拖慢执行，尤其在小数据或含I/O的操作中。
并行流真正起效的硬性条件
只有同时满足以下几点，并行流才大概率带来可观收益：
- 单元素处理逻辑平均耗时 ≥ 1 毫秒（例如：哈希计算、正则匹配、数值变换）
- 集合大小 ≥ 10⁵（十万）条，且推荐从 10⁶ 起实测才有明显区分度
- 数据源支持高效分片：优先用
ArrayList、数组；避免LinkedList、TreeSet等链式或无序结构 - 操作链以无状态为主：
filter、map、flatMap安全；慎用sorted、distinct、forEachOrdered - 纯 CPU 密集型任务：不含远程调用、文件读写、数据库查询等阻塞操作
必须用 JMH 做基准测试，不能手写 System.nanoTime()
简单计时会被 JIT 预热、GC 暂停、测量抖动严重干扰，结果不可信。JMH 可自动控制预热轮次、隔离 GC、固定 JVM 参数：
- 固定堆内存（如
-Xmx2g）和垃圾回收器（如-XX:+UseParallelGC） - 禁用监控 agent 和无关 profiler
- 复用同一份测试数据，避免每次 new ArrayList() 引入构造开销
- 至少覆盖三档规模：10⁴（验证是否拖慢）、10⁶（观察拐点）、10⁷（压测极限）
- 在同一台机器上对比不同核心数（如 4 核 vs 16 核）下的耗时曲线
常见拖慢并行流的写法
这些看似合理，实则破坏并行效率甚至引发错误：
立即学习“Java免费学习笔记（深入）”；
- 在
forEach中往普通ArrayList添加元素：线程竞争导致同步阻塞或数据丢失 - 混用
System.out.println()或日志打印：I/O 阻塞使线程挂起，吞吐骤降 - 对
Stream.iterate()或自定义低效Spliterator调用parallel()：无法有效拆分，退化为单线程 - 默认使用
ForkJoinPool.commonPool()：被 Spring、CompletableFuture 等框架抢占线程，任务排队等待 - 未加
unordered()却不需要保序：并行流默认维持插入顺序，合并阶段额外排序开销
提升实际效果的实用调优手段
不改业务逻辑，仅靠几处关键调整，就能显著改善并行流表现：
- 创建专用线程池：
new ForkJoinPool(8)（按 CPU 核心数 ×1.2～1.5 设置），再用customPool.submit(() -> stream.collect(...)).join() - 对数字运算优先用原始类型流：
IntStream.range(0, n).parallel().sum()比Stream.iterate(...).mapToInt(...)快 2～3 倍 - 过滤前置：把
filter放在map前，减少后续操作的数据量 - 收集器选型：用
Collectors.toConcurrentMap()替代Collectors.groupingBy()，避免同步瓶颈 - 确认无共享状态后，加
.unordered()：跳过顺序合并逻辑，提速 10%～25%
