commonPool会成为全应用性能单点，因其是JVM级全局共享池，所有未指定Executor的parallelStream/supplyAsync等均共用同一固定线程数（CPU数-1）的无界队列，导致I/O阻塞拖垮CPU密集任务、内存溢出、无拒绝策略及监控盲区。
为什么 commonPool 会成为全应用的性能单点
因为 ForkJoinPool.commonPool() 是 JVM 级别的全局共享线程池，所有未显式指定 Executor 的 parallelStream()、CompletableFuture.supplyAsync()、CompletableFuture.runAsync() 都默认往里塞任务。它不是“某个模块的默认池”，而是“整个 JVM 的默认池”。
这意味着：一个定时任务用 parallelStream() 处理百万条日志，一个 HTTP 接口用 supplyAsync() 调第三方 API，一个后台报表导出又在跑递归分治计算——它们全挤在同一个 7 线程（8 核机器）的池子里。谁卡住，谁就拖垮别人。
- 线程数固定为
Runtime.getRuntime().availableProcessors() - 1，无法随负载动态伸缩 - 工作队列是无界队列，任务堆积时内存持续上涨，可能触发
OutOfMemoryError - 线程全是守护线程，主线程一退出，正在执行的异步任务直接被丢弃，连日志都来不及打
commonPool 在 CPU 密集型和 I/O 密集型混合场景下的典型表现
它天生为 CPU 密集型分治任务（如大数组排序、矩阵运算）优化，靠工作窃取减少空闲。但一旦混入 I/O 操作（HTTP 调用、DB 查询、文件读写），问题立刻暴露：
- I/O 线程长时间阻塞，导致其他 CPU 密集型任务拿不到线程，吞吐骤降
- 没有拒绝策略，下游服务响应变慢 → 请求持续涌入 → commonPool 队列暴涨 → GC 压力上升 → 全应用 STW 加剧
- 监控上看不到“哪个模块占用了线程”，只能看到
ForkJoinPool.commonPool-worker-*的线程 CPU 占满，排查成本极高
去年某电商促销系统就因此出现“订单计算延迟 5 秒+，但商品详情接口超时率飙升至 40%”的现象，根源就是两者共用 commonPool，I/O 阻塞把计算线程全锁死了。
如何快速验证你的应用是否已被 commonPool 拖累
不用等线上事故，几个简单动作就能判断：
- 启动时加 JVM 参数
-Djava.util.concurrent.ForkJoinPool.common.parallelism=2，观察关键接口 P99 是否明显恶化 —— 如果恶化，说明当前并行度已接近瓶颈 - 用
jstack <pid>搜commonPool，看是否有大量线程处于WAITING (parking)或TIME_WAITING状态，同时堆栈里有supplyAsync或parallelStream - 在关键异步路径加一行日志：
log.info("Thread: {}", Thread.currentThread().getName());，如果日志里反复出现ForkJoinPool.commonPool-worker-*，基本可以确认被污染
注意：commonPool 不会在 JMX 或 Spring Boot Actuator 的线程池指标里单独暴露，它不走标准 ThreadPoolExecutor 生命周期管理，这点极易被忽略。
替换 commonPool 的最小可行方案
不是要你立刻重构全量异步调用，而是先守住关键路径：
- 对 I/O 类操作，一律改用自定义
ThreadPoolExecutor：CompletableFuture.supplyAsync(() -> fetchData(), ioExecutor) - 对计算密集型批量处理，用独立
ForkJoinPool实例：new ForkJoinPool(16)，避免干扰 commonPool - Spring 环境下，给
@Async显式配taskExecutor，别依赖默认值 - 千万别用
ForkJoinPool.commonPool().setParallelism(n)动态调参 —— 这个方法是空实现，JDK 里直接return
真正麻烦的从来不是“怎么换”，而是“哪些地方用了却没意识到”。commonPool 的隐蔽性，恰恰让它成了最危险的默认值。
