核心是用专为IO设计的线程池替代默认ForkJoinPool，通过allOf聚合+join取值实现并行执行与结果编排，依赖任务用thenCompose扁平化链式调用，并用anyOf+兜底超时任务统一控制总超时与异常。
用线程池配合CompletableFuture做多接口并行聚合，核心不是“开多个线程”，而是让IO密集型任务真正并发执行、结果可编排、异常不静默、超时不失控。
为什么不能只靠默认线程池
CompletableFuture.supplyAsync() 默认用 ForkJoinPool.commonPool()，它的并行度 ≈ CPU核数 - 1。对RPC、数据库、HTTP这类IO密集型调用，线程大部分时间在等网络响应，CPU空闲，但线程却卡在阻塞态——结果就是大量任务排队，吞吐上不去，响应反而变慢。
- 真实场景中，10个平均耗时300ms的HTTP接口，串行要3秒；用默认commonPool（假设4核），可能只跑2～3个并发，总耗时仍接近1秒以上
- 必须显式传入专为IO设计的线程池，比如：Executors.newFixedThreadPool(20) 或 Spring Boot 中配置的 @Bean("ioExecutor") ThreadPoolTaskExecutor
- 线程数估算参考：预期QPS × 平均单次IO耗时 ÷ 目标P95响应时间（例如：100 QPS × 0.3s ÷ 0.2s ≈ 150，再结合系统资源微调）
并行发起 + 结果聚合的标准写法
多个独立接口（如查用户、查订单、查优惠券），无依赖关系，目标是“全做完再合并”。关键点在于：allOf 不返回结果，只是同步信号；真正取值要靠手动收集 + 遍历 join。
- 先用 List<CompletableFuture<T>> 存下所有异步任务
- 用 CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])) 等待全部完成
- 再遍历原List，逐个调用 .join() 拿结果（注意：join() 不抛受检异常，适合链式调用）
- 最后用 Stream.collect 或手动组装成统一DTO
示例片段：
立即学习“Java免费学习笔记（深入）”；
List<CompletableFuture<User>> futures = Arrays.asList(
CompletableFuture.supplyAsync(() -> userService.getUser(id), ioExecutor),
CompletableFuture.supplyAsync(() -> orderService.getLatestOrder(id), ioExecutor),
CompletableFuture.supplyAsync(() -> couponService.getActiveCoupon(id), ioExecutor)
);
CompletableFuture.allOf(futures.toArray(new CompletableFuture[0])).join();
User user = futures.get(0).join();
Order order = futures.get(1).join();
Coupon coupon = futures.get(2).join();
return new HomePageData(user, order, coupon);
带依赖的任务链怎么写
有些接口必须前序结果才能发起，比如“先查用户ID，再查该用户的积分明细”。这时不能用 thenCombine（它要求两个任务完全独立），而要用 thenCompose —— 它把“返回另一个CompletableFuture”的嵌套逻辑拍平，避免 Callback Hell。
- thenApply：对已完成结果做同步转换（如 String → Integer）
- thenCompose：当前步骤返回的是 CompletableFuture，需继续异步执行（如 User → CompletableFuture<Points>）
- 错误示范：userFuture.thenApply(u -> pointsService.getPoints(u.getId())) → 返回的是 CompletableFuture<Points>，整个链类型变成 CompletableFuture<CompletableFuture<Points>>
- 正确写法：userFuture.thenCompose(u -> pointsService.getPointsAsync(u.getId()))
超时与异常不能只靠单个任务兜底
给每个 CompletableFuture 单独加 orTimeout(2, TimeUnit.SECONDS)，只能控制该接口超时，无法约束整条聚合链的总耗时。更危险的是，某个接口失败后，其余还在跑，浪费资源。
- 推荐做法：用 CompletableFuture.anyOf() 把所有业务任务 + 一个“兜底超时任务”一起提交
- 兜底任务写法：CompletableFuture.delayedExecutor(2, TimeUnit.SECONDS).submit(() -> { throw new TimeoutException("聚合总超时"); })
- 异常统一处理别只用 exceptionally：它不捕获运行时异常（如 NPE）、也不处理上游被 cancel 的情况；改用 handle，能同时拿到结果和异常
- RPC异常（FeignException、DubboTimeoutException）默认不会触发 exceptionally，必须在 supplyAsync 内部 try-catch，或用 handle 兜底
