Appearance
CompletableFuture 实战：异步编排、结果合并、异常处理和线程池边界
很多项目里已经不满足于“把任务扔到线程池”这么简单了，还会继续遇到：
- 多个异步任务并行执行
- 某个任务依赖上一个任务结果
- 多个结果最终合并
- 异步链路里异常怎么处理
这时 CompletableFuture 就很有价值。
先说结论
CompletableFuture 最适合解决的是：
- 异步任务编排
- 结果转换与合并
- 串行和并行依赖表达
但它最容易出问题的地方也很集中：
- 默认线程池用错
- 链路里异常被吞掉
- 阻塞操作放进异步线程导致线程池打满
一、它比 Future 多解决了什么
传统 Future 的问题是：
- 只能拿结果
- 不擅长做链式编排
- 异常处理和结果组合都比较别扭
CompletableFuture 解决的是：
- 异步任务完成后的下一步怎么写
- 多个异步结果怎么合并
- 异常链路怎么统一处理
二、最常见的 4 类用法
1. 异步执行一个任务
java
CompletableFuture.supplyAsync(() -> queryUser(), executor);适合：
- 把同步任务包装成异步结果
2. 对结果继续加工
java
future.thenApply(user -> user.getName());适合：
- 上一步有结果，下一步只是做转换
3. 依赖上一步结果再发起异步任务
java
future.thenCompose(user -> CompletableFuture.supplyAsync(() -> queryOrders(user.getId()), executor));适合：
- 第二个任务依赖第一个任务结果
4. 合并多个异步任务
java
futureA.thenCombine(futureB, (a, b) -> merge(a, b));适合：
- 两个异步任务独立执行，最后合并结果
三、后端里最典型的应用场景
例如商品详情页聚合：
- 查商品基本信息
- 查库存
- 查价格
- 查营销信息
这些请求本身互相独立，就很适合并行拉起，最后合并结果。
这种场景里，CompletableFuture 的价值很直接：
- 降低整体等待时间
四、线程池为什么一定要明确
这是最容易踩坑的地方之一。
如果你直接使用不带线程池参数的 supplyAsync()，默认会走：
ForkJoinPool.commonPool()
这在很多业务系统里不是最理想的选择，因为：
- 它是全局共享池
- 你不容易控制业务隔离
- 如果里面跑阻塞 IO，表现可能很差
更稳妥的做法通常是：
- 给业务异步任务明确配置专用线程池
五、异常处理要重点看什么
常见方法包括：
exceptionallyhandlewhenComplete
一个简单区分
whenComplete：更偏观察结果，不负责兜底转换exceptionally：有异常时给默认值handle：无论成功失败都统一转换结果
如果你只是想把异常链路统一收口，通常 handle 会更灵活。
六、几个高频组合操作
1. 等全部完成
java
CompletableFuture.allOf(f1, f2, f3)适合：
- 等多个任务都完成后再继续
2. 谁先完成用谁
java
CompletableFuture.anyOf(f1, f2, f3)适合：
- 多路兜底
- 竞速请求
七、几个非常常见的坑
1. 以为用了异步就一定更快
如果任务本身是：
- 强依赖串行
- 下游资源不足
- 线程池过小
那异步不一定带来收益。
2. 在线程池里继续做阻塞 IO
如果线程池本来就不大，又在里面堆数据库、HTTP、缓存阻塞调用，很容易把池子打满。
3. 链式调用里异常没处理
结果表面上看是“没结果”，实际是中间某步已经异常结束了。
4. 最后又 join() 回同步
这不是不能做，但要清楚：
- 你只是把内部过程异步化了，最终出口仍然是阻塞等待
八、和线程池的关系怎么理解
可以这样记：
ThreadPoolExecutor负责执行资源管理CompletableFuture负责异步流程编排
它们不是替代关系，而是配合关系。
一句话总结
CompletableFuture 真正有价值的地方，不是“把代码写成链式”，而是让异步依赖关系更清晰。
前提是你要把线程池边界、异常处理和阻塞行为控制好，否则异步链路只会把问题藏得更深。