公共池污染是架构误用而非配置问题，ForkJoinPool.commonPool()作为JVM级全局资源，混入阻塞任务会导致线程耗尽、队列膨胀、GC加剧及P99延迟恶化，须通过自定义线程池隔离I/O与CPU密集型任务。
公共池污染不是配置问题，是架构误用。ForkJoinPool.commonPool() 是 JVM 级全局共享资源，一旦混入阻塞型任务（如数据库查询、HTTP 调用、文件读写），就会让整个应用的异步能力陷入瘫痪。
为什么阻塞任务会直接拖垮 commonPool
commonPool 默认线程数 = CPU 核心数 − 1（8 核机器只有 7 个线程），且全部为守护线程、使用无界队列、无拒绝策略。当多个模块不约而同往里塞阻塞任务时：
- 每个阻塞操作（比如一次 800ms 的 Redis 查询）会让一个工作线程卡住，无法参与工作窃取
- 7 个线程全被 I/O 占满后，新提交的 CPU 密集型 parallelStream（如实时风控计算）只能排队等待
- 队列持续增长 → 堆内存飙升 → GC 频繁 → STW 时间拉长 → 接口 P99 延迟跳变式恶化
- 主线程退出时，所有未完成的 supplyAsync 任务静默丢弃，连异常都捕获不到
典型污染场景识别
不用等线上告警，这几个信号出现任意一个，就说明污染已在发生：
- jstack 输出中大量 ForkJoinPool.commonPool-worker-* 线程处于 TIMED_WAITING 或 BLOCKED 状态，堆栈含 HttpClient、JDBC、FileInputStream 等 I/O 调用
- parallelStream() 处理小数据集（如千条以内）却耗时超 2 秒，且 CPU 使用率不高
- CompletableFuture.supplyAsync() 返回结果时间波动极大，有时快有时慢得离谱
- 监控看到 commonPool 队列长度持续 > 1000，且 activeThreads 长期维持在最大值
如何隔离污染、保护关键路径
核心原则：重要业务不碰 commonPool，自己配池、自己管队列、自己设兜底。
- 替代 parallelStream()：用自定义 ForkJoinPool（asyncMode=true 更适合 I/O）或 ThreadPoolExecutor + CompletableFuture.supplyAsync()
- HTTP/DB 类异步调用统一走专用 IO 线程池，例如：
Executors.newFixedThreadPool(20, new ThreadFactoryBuilder().setNameFormat("io-pool-%d").build()) - 在 Spring Boot 中可通过
@Async("ioTaskExecutor")显式绑定，避免隐式落入 commonPool - 加一层轻量包装：封装工具类，强制所有 supplyAsync() 调用必须传入非 null Executor，否则编译报错或启动失败
验证修复是否生效的实操方法
改完不是结束，要闭环验证：
- 本地启动时加参数：
-Djava.util.concurrent.ForkJoinPool.common.parallelism=1，观察主流程是否仍可接受——如果直接卡死，说明还有隐式依赖没清理干净 - 在关键异步入口打日志：
log.debug("executed on: {}", Thread.currentThread().getName());，确认输出中不再出现 commonPool-worker-* - 压测时用 JFR 录制，重点关注
ForkJoinPool-queuedTaskCount和activeThreads是否稳定在合理区间
