Java 8 的 parallelStream 和 supplyAsync 默认共用 ForkJoinPool.commonPool()，存在资源争抢、阻塞传播和监控盲区风险；其线程数默认为 CPU 核心数减 1，且全局共享，无法按业务隔离，应通过自定义 ForkJoinPool 或 ThreadPoolExecutor 实现任务级线程池隔离。
Java 8 的 parallelStream 和未指定线程池的 CompletableFuture.supplyAsync 默认都走 ForkJoinPool.commonPool() —— 这是一个 JVM 级别的单例线程池，不是每个任务独享的。它看似高效，实则暗藏资源争抢、阻塞传播和监控盲区三大风险。
commonPool 的默认行为与真实瓶颈
它的并行度（worker 线程数）默认为 Runtime.getRuntime().availableProcessors() - 1，比如 16 核机器只有 15 个线程；且该值在 JVM 启动时读取一次，无法运行时动态调整。更关键的是，所有模块的 parallelStream、supplyAsync、甚至某些框架内部的并行操作，全部挤在这个池子里。
- 计算密集型任务（如批量数值处理）会长期占满 CPU，导致其他任务得不到调度
- IO 密集型任务（如 HTTP 调用、DB 查询）一旦阻塞，线程就空等，把有限的工作线程“锁死”
- 两个任务类型混跑时，IO 任务拖慢计算任务，或计算任务饿死 IO 任务，互相拉胯
为什么不能直接改 commonPool？
虽然可通过系统属性 -Djava.util.concurrent.ForkJoinPool.common.parallelism=20 调整线程数，但这只是“扩池”，不解决根本问题：
- 仍是全局共享，A 模块的慢查询仍会拖垮 B 模块的实时统计
- 线程数设高了，CPU 上下文切换开销上升，反而降低吞吐
- 无法按业务维度做熔断、限流、监控打标，故障定位困难
真正有效的隔离方案：绕过 commonPool
不修改默认池，而是让特定任务主动提交到专属线程池。有两类主流做法：
立即学习“Java免费学习笔记（深入）”；
-
自定义 ForkJoinPool：适合仍需分治递归逻辑的任务，例如大数据量的 map-reduce 类计算
ForkJoinPool customPool = new ForkJoinPool(8);<br>long sum = customPool.submit(() -> list.parallelStream().mapToInt(Integer::intValue).sum()).join();
-
普通 ThreadPoolExecutor：更适合 IO 密集型场景，可配置队列策略、拒绝策略、线程存活时间
ExecutorService ioPool = Executors.newFixedThreadPool(32);<br>CompletableFuture.supplyAsync(() -> callRemoteApi(), ioPool);
日常开发中的关键检查点
上线前建议快速确认以下几项，避免线上“静默卡顿”：
- 搜索代码中所有
.parallelStream()和supplyAsync(...)，看是否漏了线程池参数 - 通过 JMX 或代码打印
ForkJoinPool.commonPool().getActiveThreadCount()和getQueuedTaskCount()，观察高峰期是否长期积压 - 对含网络/文件/数据库调用的流操作，一律禁用默认 parallelStream，改用显式线程池 + 超时控制
