我见过不少 Spring Boot 项目把 CompletableFuture 当成“免费加速器”：三个下游并发查一下，接口平均耗时确实降了，但高峰一来 p99 反而炸了。最后查下来，不是下游突然慢，而是一堆 supplyAsync、thenApplyAsync 没传 Executor，全挤进了 ForkJoinPool.commonPool。
Oracle 的 CompletableFuture 文档明确写了，无显式 Executor 的 async 方法会使用默认 executor，通常就是 commonPool。Spring 的 @Async 也支持通过注解值选择指定 executor。真正的生产问题不在于 API 会不会用，而是异步任务有没有边界。
事故是怎么来的
那次接口本来是串行查用户、订单、优惠券，后来改成三个 CompletableFuture 并发。压测低并发很好看，上线高峰却出现大量长尾。CPU 不高，数据库也没报警，但线程 dump 里能看到 commonPool worker 被阻塞任务占满。
问题在于 commonPool 是共享资源。你以为只是这个接口在用，实际项目里 parallelStream、别的 CompletableFuture、某些库内部异步都可能碰它。一个业务把它打满，影响面就不可控。
第一条规矩：业务异步必须显式 Executor
我一般会按业务域拆线程池，比如 userAsyncExecutor、orderAsyncExecutor、reportAsyncExecutor。线程名要能看出归属，队列容量、拒绝策略、active count、queue size 都要进监控。
@Bean
ThreadPoolTaskExecutor orderAsyncExecutor() {
var executor = new ThreadPoolTaskExecutor();
executor.setThreadNamePrefix("order-async-");
executor.setCorePoolSize(16);
executor.setMaxPoolSize(64);
executor.setQueueCapacity(500);
executor.initialize();
return executor;
}
第二条规矩：异步链路要有超时和异常收口
CompletableFuture 最怕“有一个分支慢，全链路傻等”。外层接口有超时还不够，分支任务也要贴近下游预算。Java 9 之后可以用 orTimeout、completeOnTimeout；在更复杂的业务里，我会配合 Resilience4j 的 TimeLimiter 或 Bulkhead。
异常处理也要讲清楚：哪些可以降级，哪些必须失败，哪些要带业务 id 打日志。不要在 exceptionally 里随手返回空对象，否则线上看起来成功，数据却悄悄错了。
第三条规矩：MDC 和 TraceContext 不会自动替你飞过去
异步任务换线程后，日志里的 requestId、traceId 很容易丢。我的做法是在 executor 外包一层 TaskDecorator，把提交任务时的 MDC 拷贝到执行线程，执行完再清理。注意是清理，不然线程复用会串上下文。
上线检查清单
- 所有 supplyAsync、runAsync、thenApplyAsync 是否传了明确 Executor？
- @Async 是否指定了业务线程池，而不是吃默认配置？
- 线程池 active、queue、rejected 是否接入监控和告警？
- 每个分支任务是否有超时、降级和异常日志？
- MDC、traceId、用户上下文是否正确传递并清理？
- 下游连接池和线程池容量是否匹配，是否存在异步放大流量？
最后聊两句
CompletableFuture 是好工具，但它不是把同步代码包一层就万事大吉。异步会把问题从“慢”变成“难定位”，所以线程池隔离、超时、上下文和监控必须一起上。
我的建议很简单：业务代码里看到 async 没传 executor，就先当成潜在事故点 review。把边界补齐之后，CompletableFuture 才是真正能上线的并发编排工具。
MySQL 不可见索引实战：想删索引又怕翻车，先做一次生产级预演 
