Java中CompletableFuture必须自定义线程池，因其默认使用ForkJoinPool.commonPool()——线程数少（CPU核数−1）、无隔离、不可控，易引发阻塞与雪崩；应按I/O或CPU密集型任务分池配置，并全程显式传入Executor。
Java 中 CompletableFuture 默认使用的是 ForkJoinPool.commonPool()，这是一个 JVM 全局共享的线程池，不是为业务场景设计的“专属执行器”。它线程数少、无隔离、不可控，生产环境直接用极易引发阻塞和雪崩。自定义线程池不是可选项，而是必须项。
默认线程池：ForkJoinPool.commonPool() 的真实面貌
调用 supplyAsync(() -> ...) 或 runAsync(() -> ...) 且不传 Executor 时，就自动落入这个池子。它的关键事实包括：
- 线程数量 = CPU 核心数 − 1（8 核机器只有 7 个线程）
- 所有未指定线程池的 CompletableFuture、并行流（
stream().parallel()）共用同一组线程 - 线程是守护线程，主线程退出后任务可能被强制中断
- 专为短时、计算密集型任务优化，不适合任何含 I/O、HTTP、DB 查询的操作
为什么必须自定义线程池
因为默认池不具备业务适配能力：
- 一个慢 SQL 或超时 HTTP 请求卡住 1 个线程，整个 commonPool 就少 1/7 的并发能力
- 支付、订单、风控等模块混跑在一个池里，A 模块抖动会拖垮 B 模块响应
- 无法设置拒绝策略、队列容量、空闲存活时间等关键参数，出问题只能被动扛
- 日志、监控、链路追踪难以按业务归因——全是 “common-pool-3” 这类无意义名称
如何正确自定义线程池（附推荐配置）
核心原则：按任务类型分池，显式传入每个异步方法，并在后续回调中延续同一池。
立即学习“Java免费学习笔记（深入）”；
-
I/O 密集型任务（如远程调用、数据库查询、文件读写）：
推荐核心线程数 ≈ 下游平均 QPS × 平均 RT（秒），例如 QPS=200、RT=200ms → 建议 core=40；最大线程数设为 core×2；队列用有界阻塞队列（如 LinkedBlockingQueue(2000)）；拒绝策略建议CallerRunsPolicy或AbortPolicy -
CPU 密集型任务（如加解密、图像处理、复杂计算）：
核心线程数 ≈ CPU 核心数（如 8 核设为 8），最大线程数与核心数一致；队列宜小（如 100～500），避免任务积压抢占 CPU -
命名与管理：
务必通过ThreadFactoryBuilder（如 Guava）或自定义 ThreadFactory 设置有意义的线程名，例如"order-query-pool-%d"；Spring 环境下建议声明为@Bean统一管理生命周期
代码层面的关键写法
不只是首次创建要传线程池，所有后续异步回调也必须显式指定，否则会退化回 commonPool：
- ✅ 正确写法（全程指定同一池）：
CompletableFuture.supplyAsync(() -> queryOrder(), ioPool)<br> .thenApplyAsync(order -> enrichUser(order), ioPool)<br> .thenComposeAsync(enriched -> callRiskApi(enriched), ioPool); - ❌ 错误写法（中间漏传，掉回 commonPool）：
.thenApply(order -> enrichUser(order)) // 缺少 executor 参数，已退化！
