并行流并非默认高效，其性能瓶颈源于默认复用ForkJoinPool.commonPool()的三大缺陷：固定并行度、全局共享及I/O零容忍；IO密集、小数据量简单操作、非均匀负载场景下常比串行更慢；应依任务类型选用自定义ForkJoinPool、ThreadPoolExecutor或CompletableFuture，并规避线程不安全与顺序敏感操作。
并行流不是“开箱即用就一定快”的魔法，它默认复用 ForkJoinPool.commonPool() 这个全局共享线程池——这恰恰是多数性能问题的根源。真正影响性能的，往往不是数据量或 CPU 核数，而是任务类型与线程池特性的错配。
默认线程池的三大硬伤
所有未显式指定线程池的 parallelStream() 都走同一个 commonPool，它有三个不可忽视的约束：
-
固定并行度：默认为
Runtime.getRuntime().availableProcessors() - 1，JVM 启动后无法动态调整，哪怕你机器有 64 核，它也只起 63 个 worker 线程 - 全局共享：Service A 的 HTTP 调用、Service B 的日志聚合、定时任务里的统计，全挤在一个池子里抢资源
-
I/O 零容忍：一旦某个
.map(this::callApi)因网络超时阻塞 2 秒，整个池子的线程可能被占满，其他计算型任务只能排队等待
哪些场景下 parallelStream 反而更慢？
不是所有“看起来能并行”的操作都适合并行流。以下情况实测常出现性能倒挂（串行比并行快）：
-
IO 密集型操作：如
.map(this::readFile)、.filter(item -> http.get(...).isOk())，线程大量时间在等待，而非计算 -
小数据量 + 简单逻辑：比如对几千条字符串做
.map(String::toUpperCase)，拆分/合并开销远超收益 - 非均匀任务负载：列表中混杂了处理耗时差异极大的元素（如一个要解析 10MB JSON，另一个只是判空），导致部分线程长期空转
安全又高效的替代方案
不是否定并行流，而是按需选型：
立即学习“Java免费学习笔记（深入）”；
-
计算密集型任务（如数值运算、图像像素处理）：可保留
parallelStream()，但建议用自定义ForkJoinPool隔离，例如：ForkJoinPool custom = new ForkJoinPool(12);<br>custom.submit(() -> list.parallelStream().map(...).collect()).join();
-
IO 密集型任务（如远程调用、DB 查询）：改用
ThreadPoolExecutor，线程数设为预期并发量（如 50~200），避免偷懒复用commonPool -
混合型或关键路径任务：直接放弃
parallelStream()，用CompletableFuture.supplyAsync(..., executor)显式控制线程来源和超时
写法上必须避开的雷区
即便换了线程池，若流内操作本身不安全，照样出问题：
-
禁止在 lambda 中修改外部集合：如
resultList.add(x)、map.put(k, v)→ 改用.collect(Collectors.toList())或.collect(Collectors.toConcurrentMap()) -
禁用顺序敏感操作：如
.limit(5)、.findFirst()在并行下结果不确定 → 若需顺序，先.collect(Collectors.toList())再取索引或遍历 -
别信“同步包装”万能：如
Collections.synchronizedList(new ArrayList())虽不抛异常，但内部锁粒度大，实际变成串行执行，还多一层代理开销
