supplyAsync不指定线程池时默认使用ForkJoinPool.commonPool()，该池是JVM级共享、无隔离、无拒绝策略的全局资源，易因IO任务阻塞导致线程耗尽、任务堆积、级联超时甚至OOM。
不指定线程池时，supplyAsync 会默认使用 ForkJoinPool.commonPool()——这不是一个“普通线程池”，而是一个 JVM 级别共享、无隔离、难管控的全局资源。它的风险不是理论推演，而是高频引发 P0 级事故的现实隐患。
默认用 commonPool 的三大硬伤
共享性导致资源污染：parallelStream、其他模块的 CompletableFuture、甚至某些框架内部异步逻辑（如 Spring 的部分回调）都可能悄悄往里面塞任务。一个模块提交 20 个耗时 2 秒的数据库查询，就能让另一个模块刚发起的 100 个日志打印任务排队等 5 秒以上。
线程数严重不匹配 IO 场景：commonPool 默认线程数 = CPU 核数 − 1（8 核机器仅 7 个线程）。而真实业务中，supplyAsync 常用于调用 HTTP、DB、LLM 等阻塞型操作——这类任务不消耗 CPU，但需要大量并发等待能力。7 个线程撑不住 50 路并发请求，必然堆积、超时、级联失败。
无拒绝策略 + 无界队列 = OOM 温床：commonPool 内部使用的是无界 LinkedBlockingQueue，且没有可配置的拒绝策略。当突发流量涌入、下游响应变慢时，任务持续入队，内存持续增长，最终触发 Full GC 或直接 OOM。
什么情况下尤其危险？
- 任务含任何阻塞调用（
Thread.sleep、JDBC 查询、RestTemplate 调用、文件读写） - 多个业务共用同一 JVM（如微服务聚合部署），且未做线程池隔离
- 混用 parallelStream 和 CompletableFuture（二者底层都吃 commonPool）
- 异步链中大量使用
thenApplyAsync/thenAcceptAsync却未传入线程池
选型建议：按任务特征配池，不碰 commonPool
CPU 密集型任务（如加解密、图像处理、复杂计算）：可用自定义 ForkJoinPool，并行度设为 Runtime.getRuntime().availableProcessors()，启用 FIFO 模式提升吞吐。
IO 密集型任务（绝大多数业务场景）：必须用 ThreadPoolExecutor，推荐 newFixedThreadPool(n) 或带监控的定制池，n 通常设为 20–100（视平均响应时间与并发目标而定），避免无限扩容。
混合型或关键路径任务：不同阶段拆开隔离——DB 操作用 dbPool，HTTP 调用用 httpPool，纯计算用 computePool。每个 supplyAsync 和后续的 thenApplyAsync 都显式传入对应池实例，杜绝隐式依赖。
一句话落地原则
只要你的 supplyAsync 里有哪怕一行可能阻塞的代码，就绝不能省略第二个线程池参数；生产环境所有 CompletableFuture 异步方法，都应视为“必须显式指定执行器”的强约束。
