在项目开发里，异步处理和多线程是提升效率的常用手段。比如用户领取奖品后异步发送推送，或是将原本顺序执行、总耗时为各步骤之和的业务逻辑，改成多线程并行执行以缩短耗时。这时，CompletableFuture常被选为工具，但它隐藏着不少容易踩的坑，稍不注意就可能导致线上故障。
一、CompletableFuture基础认知
1.1 核心API解析
CompletableFuture提供了四种提交任务的方法，关键区别在于是否有返回值以及是否指定线程池：
runAsync(Runnable runnable)：无返回值，不指定线程池，使用默认线程池。runAsync(Runnable runnable, Executor executor)：无返回值，可指定自定义线程池。supplyAsync(Supplier<U> supplier)：有返回值，不指定线程池，使用默认线程池。supplyAsync(Supplier<U> supplier, Executor executor)：有返回值，可指定自定义线程池。
1.2 默认线程池ForkJoinPool特性
ForkJoinPool是CompletableFuture的默认线程池，基于“工作窃取”算法，每个工作线程有自己的双端任务队列，线程空闲时会窃取其他线程的任务执行，以提高CPU利用率。不过它有明显适用场景限制：
- 适合CPU密集型任务，像递归计算、大规模数据并行处理等。
- 不适合IO密集型任务，而项目中常见的数据库查询、RPC调用等多为IO密集型操作。
- 线程数量与CPU核心数相关，当CPU核心数减1大于1时才使用默认线程池，否则为每个任务创建新线程。例如4核CPU最多只有3个核心线程，线程资源十分有限。
二、项目中常见的CompletableFuture陷阱
2.1 默认线程池线程不足致超时
某开发人员为加快代码执行，将原本顺序执行的A、B、C三个业务逻辑，改成用三个CompletableFuture并行执行，本地测试耗时从900ms缩短到300ms，便直接上线。可上线后第二天，接口频繁超时，部分耗时甚至超过10秒。
排查发现，项目中大量使用CompletableFuture.supplyAsync且未指定线程池，依赖默认的ForkJoinPool。以8核CPU机器为例，默认线程池仅7个线程，面对大量并发请求时，线程资源被快速耗尽，后续任务只能排队等待，最终引发接口雪崩，出现无限超时。
这一问题的核心原因是未做线程池隔离，过度依赖默认线程池。解决办法是必须为CompletableFuture配置自定义线程池，避免与其他业务争抢默认线程池资源。
2.2 自定义线程池配置不当反降效
经历过默认线程池的坑后，该开发人员开始为CompletableFuture配置自定义线程池，代码如下：
ExecutorService es = Executors.newFixedThreadPool(5);
public void test1() {
CompletableFuture.runAsync(() -> a(1), es);
CompletableFuture.runAsync(() -> b(1), es);
CompletableFuture.runAsync(() -> c(1), es);
}本以为能解决问题，可没过几天，线上再次出现大量接口超时。原来SpringMVC的Tomcat默认线程池有200个线程，而自定义线程池仅5个线程。当并发请求攀升到200个时，5个线程根本无法应对，任务排队等待线程释放，导致接口响应速度大幅下降，甚至拖垮整个服务。
这提醒我们，自定义线程池时，线程数量需结合业务并发量合理配置，不能盲目设置过少，也不能忽视系统整体资源承载能力。
2.3 线程池共用引发死锁
有开发人员认为，将自定义线程池核心线程数调大就能避免问题，比如调到200。但这种做法不可取，过多线程会严重消耗CPU资源，影响系统稳定性。更严重的是，线程池共用还可能引发死锁。
如下代码中，自定义线程池有5个线程，test方法循环提交5个任务到线程池，每个任务又会调用a方法，而a方法会再次通过CompletableFuture向同一个线程池提交任务并调用get()等待结果：
ExecutorService es = Executors.newFixedThreadPool(5);
public void test() {
for (int i = 0; i < 5; i++) {
CompletableFuture.runAsync(() -> a(), es);
}
}
public void a() {
CompletableFuture<Integer> f = CompletableFuture.supplyAsync(() -> 1, es);
try {
f.get();
} catch (Exception e) {}
}此时，线程池的5个线程全被test方法的任务占用，a方法提交的任务无法获取线程执行，f.get()会一直阻塞，test方法的任务也无法完成，最终形成死锁。
解决此问题的关键是业务间线程池隔离，不同业务场景应配置独立的线程池，避免共用线程池导致资源争抢和死锁。
三、CompletableFuture使用建议
- 优先考虑同步执行：在业务代码中，若不是对性能有极致要求，能不使用多线程就不使用。多线程带来的复杂度、故障排查难度等副作用，往往超过其提升的效率。
- 强制线程池隔离：使用CompletableFuture时，必须配置自定义线程池，严禁使用默认的ForkJoinPool，且不同业务需使用独立线程池，避免相互影响。
- 合理配置线程池参数：根据业务类型（CPU密集型或IO密集型）、并发量等因素，科学设置线程池核心线程数、最大线程数、队列容量等参数。例如IO密集型任务线程数可适当多些，CPU密集型任务线程数不宜过多，一般不超过CPU核心数的2倍。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接
文章评论