背景与问题

在 Java 服务端开发里，只要链路里同时依赖多个外部系统，异步编排几乎就绕不过去。

一个很典型的场景是：用户打开商品详情页，服务端要同时查商品基础信息、库存、价格、营销活动、推荐结果。这里如果全都串行执行，接口耗时很容易被拖到几百毫秒甚至秒级；但如果一股脑儿把任务扔进线程池，又会很快碰到另外几个问题：

• 线程池打满，系统抖动
• 某个子任务失败后，主流程表现不可控
• 日志里只有“超时了”，根本不知道卡在哪
• 用了 CompletableFuture，但实际上性能没上去
• 业务一复杂，回调套回调，可维护性急剧下降

我自己早期写异步编排时，最容易犯的错就是：把 CompletableFuture 当成“更高级的多线程语法糖”。结果上线后发现，真正决定系统稳不稳的，不只是“能不能并发”，而是：

1. 线程池是否按任务类型隔离
2. 异常和超时是否被显式治理
3. 结果聚合是否清晰、可取消、可降级
4. 每个异步阶段能不能被观测到

所以这篇文章我会从架构落地角度讲这件事，不只讲 API 怎么用，而是重点讲：

• CompletableFuture 的执行模型
• 线程池如何设计
• 常见编排模式怎么写
• 异常、超时、降级怎么做
• 可观测性怎么补齐
• 在什么边界下，异步反而不该乱用

方案对比与取舍分析

在讲实现前，先把几种常见方案摆在一起。

1. 串行调用

优点：

• 代码简单
• 调试直接
• 事务边界更清晰

缺点：

• 总耗时约等于各子任务耗时之和
• 外部依赖多时，尾延迟非常明显

适合：

• 依赖之间有强顺序
• 耗时都很短
• 请求量不高

2. 原生 Future + 线程池

优点：

• 能并发执行
• 比较接近底层

缺点：

• 结果合并麻烦
• 异常处理不统一
• 编排复杂度高

适合：

• 任务非常简单
• 只需要 submit/get

3. CompletableFuture + 自定义线程池

优点：

• 支持链式编排
• 支持任务聚合、合并、竞速
• 异常处理模型相对完整
• 能更清晰表达依赖关系

缺点：

• API 多，容易误用
• 默认线程池有坑
• 不注意超时和监控时，问题会隐藏得很深

适合：

• 典型服务端聚合场景
• 中高并发、依赖较多的业务接口
• 需要落地工程治理的系统

4. 响应式方案（如 Reactor）

优点：

• 更适合高并发、流式处理
• 对背压支持更强

缺点：

• 学习成本高
• 与传统同步代码混用时复杂度增加

适合：

• 全链路响应式
• 对吞吐、资源利用率要求更高的系统

这篇文章聚焦第 3 种：它是很多 Java 中大型业务系统最常见、也最容易“看起来会用，实际上埋坑”的方案。

核心原理

1. CompletableFuture 到底解决了什么问题

可以把它理解成两件事的组合：

• Future：表示“未来会完成的结果”
• CompletionStage：表示“当前阶段完成后，后续怎么继续执行”

也就是说，它不只是“拿异步结果”，而是“描述一张任务依赖图”。

比如：

• A、B、C 并行执行
• A 和 B 都完成后，做 D
• C 失败时走降级
• 任意任务超时都返回默认值
• 最后把 D 与 C 的结果组装成响应

这类逻辑如果用传统 Future 来写，控制流会很别扭；而 CompletableFuture 很适合表达这种阶段式编排。

2. 常见 API 的职责分层

创建异步任务

• supplyAsync(Supplier, Executor)：有返回值
• runAsync(Runnable, Executor)：无返回值

单任务后置处理

• thenApply：同步转换结果
• thenApplyAsync：异步转换结果
• thenAccept：消费结果，无返回值
• thenRun：不关心上一步结果，只做后续动作

多任务组合

• thenCombine：两个任务都完成后合并
• allOf：全部完成
• anyOf：任意一个完成

异常相关

• exceptionally：失败时给默认值
• handle：无论成功失败都处理
• whenComplete：做记录，但不改变结果

3. thenApply 和 thenApplyAsync 的区别

这是非常多人会混淆的点。

• thenApply：可能由上一个阶段完成的线程直接执行
• thenApplyAsync：会提交到线程池执行

这意味着：

• 如果转换逻辑很轻量，thenApply 通常更省线程切换
• 如果转换逻辑比较重，或者不能阻塞当前完成线程，应该考虑 thenApplyAsync

很多线上“线程池明明没满但吞吐很差”的问题，就出在链路里混用了大量不合适的同步/异步阶段。

4. 默认线程池为什么不建议直接依赖

如果不传 Executor，很多异步阶段会走 ForkJoinPool.commonPool()。

这在 demo 中没问题，但在服务端生产环境里风险很大：

• 线程池是全局共享的
• 难以隔离不同业务
• 遇到阻塞 I/O 时，ForkJoinPool 并不一定合适
• 排查问题时很难定位是谁把公共线程池打满了

结论很直接：生产环境里，建议显式传入自定义线程池。

异步编排流程图

flowchart LR
    A[收到请求] --> B[提交商品信息任务]
    A --> C[提交库存任务]
    A --> D[提交价格任务]
    A --> E[提交营销任务]

    B --> F[基础信息转换]
    C --> G[库存降级处理]
    D --> H[价格超时兜底]
    E --> I[营销异常记录]

    F --> J[结果聚合]
    G --> J
    H --> J
    I --> J

    J --> K[返回响应]

线程池与任务边界关系图

classDiagram
    class RequestThread {
      +receive()
      +dispatch()
    }

    class IOExecutor {
      +corePoolSize
      +maxPoolSize
      +queueCapacity
    }

    class CPUExecutor {
      +corePoolSize
      +maxPoolSize
    }

    class CompletableFuture {
      +supplyAsync()
      +thenCombine()
      +exceptionally()
    }

    class DownstreamService {
      +queryProduct()
      +queryStock()
      +queryPrice()
    }

    RequestThread --> CompletableFuture
    CompletableFuture --> IOExecutor
    CompletableFuture --> CPUExecutor
    CompletableFuture --> DownstreamService

实战代码（可运行）

下面我用一个“商品详情聚合服务”示例，演示一个相对完整的写法：

• 基础信息、库存、价格并发查询
• 库存失败时降级为 false
• 价格超时时给默认值
• 聚合阶段统一组装
• 日志打印每个阶段耗时
• 显式使用自定义线程池

代码可直接放在 JDK 11+ 环境运行。
如果你是 JDK 8，没有 orTimeout/completeOnTimeout，后面我会讲替代方案。

import java.math.BigDecimal;
import java.time.LocalDateTime;
import java.util.Random;
import java.util.concurrent.*;
import java.util.function.Supplier;

public class CompletableFutureOrchestrationDemo {

    private static final ExecutorService ioExecutor = new ThreadPoolExecutor(
            8,
            16,
            60L,
            TimeUnit.SECONDS,
            new ArrayBlockingQueue<>(200),
            new NamedThreadFactory("io-pool"),
            new ThreadPoolExecutor.CallerRunsPolicy()
    );

    private static final ExecutorService cpuExecutor = new ThreadPoolExecutor(
            4,
            8,
            60L,
            TimeUnit.SECONDS,
            new LinkedBlockingQueue<>(100),
            new NamedThreadFactory("cpu-pool"),
            new ThreadPoolExecutor.AbortPolicy()
    );

    public static void main(String[] args) {
        ProductAggregateService service = new ProductAggregateService();

        for (long productId = 1; productId <= 5; productId++) {
            try {
                ProductDetail detail = service.getProductDetail(productId);
                System.out.println("FINAL RESULT => " + detail);
            } catch (Exception e) {
                System.err.println("REQUEST FAILED, productId=" + productId + ", ex=" + e.getMessage());
            }
            System.out.println("--------------------------------------------------");
        }

        ioExecutor.shutdown();
        cpuExecutor.shutdown();
    }

    static class ProductAggregateService {

        private final ProductService productService = new ProductService();
        private final InventoryService inventoryService = new InventoryService();
        private final PriceService priceService = new PriceService();

        public ProductDetail getProductDetail(long productId) {
            long begin = System.currentTimeMillis();

            CompletableFuture<ProductInfo> productFuture =
                    timedSupplyAsync("query-product", () -> productService.queryProduct(productId), ioExecutor)
                            .thenApplyAsync(product -> {
                                product.setName(product.getName() + " [assembled]");
                                return product;
                            }, cpuExecutor);

            CompletableFuture<Boolean> stockFuture =
                    timedSupplyAsync("query-stock", () -> inventoryService.hasStock(productId), ioExecutor)
                            .exceptionally(ex -> {
                                log("query-stock fallback, productId=" + productId + ", ex=" + ex.getMessage());
                                return false;
                            });

            CompletableFuture<BigDecimal> priceFuture =
                    timedSupplyAsync("query-price", () -> priceService.queryPrice(productId), ioExecutor)
                            .completeOnTimeout(new BigDecimal("99.99"), 300, TimeUnit.MILLISECONDS)
                            .exceptionally(ex -> {
                                log("query-price fallback, productId=" + productId + ", ex=" + ex.getMessage());
                                return new BigDecimal("99.99");
                            });

            CompletableFuture<ProductDetail> detailFuture =
                    productFuture.thenCombine(stockFuture, (product, hasStock) -> {
                        ProductDetail detail = new ProductDetail();
                        detail.setProductId(product.getId());
                        detail.setProductName(product.getName());
                        detail.setHasStock(hasStock);
                        return detail;
                    }).thenCombine(priceFuture, (detail, price) -> {
                        detail.setPrice(price);
                        return detail;
                    }).whenComplete((result, ex) -> {
                        long cost = System.currentTimeMillis() - begin;
                        if (ex != null) {
                            log("aggregate failed, productId=" + productId + ", cost=" + cost + "ms, ex=" + ex.getMessage());
                        } else {
                            log("aggregate success, productId=" + productId + ", cost=" + cost + "ms");
                        }
                    });

            return detailFuture.join();
        }
    }

    static <T> CompletableFuture<T> timedSupplyAsync(String taskName, Supplier<T> supplier, Executor executor) {
        return CompletableFuture.supplyAsync(() -> {
            long begin = System.currentTimeMillis();
            String threadName = Thread.currentThread().getName();
            try {
                log("task start, name=" + taskName + ", thread=" + threadName);
                T result = supplier.get();
                log("task success, name=" + taskName + ", cost=" + (System.currentTimeMillis() - begin) + "ms");
                return result;
            } catch (Exception e) {
                log("task error, name=" + taskName + ", cost=" + (System.currentTimeMillis() - begin) + "ms, ex=" + e.getMessage());
                throw e;
            }
        }, executor);
    }

    static void log(String msg) {
        System.out.println(LocalDateTime.now() + " | " + msg);
    }

    static class ProductService {
        public ProductInfo queryProduct(long productId) {
            sleep(100 + new Random().nextInt(100));
            return new ProductInfo(productId, "product-" + productId);
        }
    }

    static class InventoryService {
        public boolean hasStock(long productId) {
            sleep(80 + new Random().nextInt(120));
            if (productId % 3 == 0) {
                throw new RuntimeException("inventory service unavailable");
            }
            return true;
        }
    }

    static class PriceService {
        public BigDecimal queryPrice(long productId) {
            int delay = 100 + new Random().nextInt(350);
            sleep(delay);
            if (productId % 5 == 0) {
                throw new RuntimeException("price service failed");
            }
            return new BigDecimal("199.00");
        }
    }

    static void sleep(long millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
            throw new RuntimeException("thread interrupted");
        }
    }

    static class ProductInfo {
        private long id;
        private String name;

        public ProductInfo(long id, String name) {
            this.id = id;
            this.name = name;
        }

        public long getId() {
            return id;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }

    static class ProductDetail {
        private long productId;
        private String productName;
        private boolean hasStock;
        private BigDecimal price;

        public void setProductId(long productId) {
            this.productId = productId;
        }

        public void setProductName(String productName) {
            this.productName = productName;
        }

        public void setHasStock(boolean hasStock) {
            this.hasStock = hasStock;
        }

        public void setPrice(BigDecimal price) {
            this.price = price;
        }

        @Override
        public String toString() {
            return "ProductDetail{" +
                    "productId=" + productId +
                    ", productName='" + productName + '\'' +
                    ", hasStock=" + hasStock +
                    ", price=" + price +
                    '}';
        }
    }

    static class NamedThreadFactory implements ThreadFactory {
        private final String prefix;
        private int index = 1;

        NamedThreadFactory(String prefix) {
            this.prefix = prefix;
        }

        @Override
        public synchronized Thread newThread(Runnable r) {
            Thread t = new Thread(r);
            t.setName(prefix + "-" + index++);
            return t;
        }
    }
}

代码拆解：为什么这样设计

1. I/O 任务和 CPU 任务分线程池

示例里我拆成了两个池：

• ioExecutor：用于远程调用、数据库、缓存等 I/O 型任务
• cpuExecutor：用于数据转换、规则计算、聚合加工

这样做的目的很现实：避免慢 I/O 把计算任务拖死，或者计算任务反过来挤占 I/O 资源。

如果所有任务都丢到一个池里，线上高峰时只要某个下游变慢，整个服务就可能出现“雪崩式排队”。

2. 用 thenCombine 表达“结果汇合”

很多人会这么写：

CompletableFuture.allOf(a, b, c).join();
A ra = a.join();
B rb = b.join();
C rc = c.join();

这没错，但当任务之间存在明显的二元合并关系时，thenCombine 更直观。它会把依赖关系写进代码结构里。

3. 异常兜底要贴近任务本身

库存失败直接降级为 false，价格失败或超时给默认价，这种逻辑最好写在子任务旁边，而不是全部等到最外层统一处理。

原因是：

• 业务意图更清楚
• 不会影响其他任务继续执行
• 聚合阶段拿到的是“可用结果”而不是一堆异常状态

4. whenComplete 更适合做埋点，不适合做补偿

whenComplete 会拿到结果和异常，但不会吞掉异常。
所以它很适合做：

• 记录耗时
• 打日志
• 打 metric
• 补 tracing tag

但如果你希望在失败时返回默认值，应该用 exceptionally 或 handle。

容量估算：线程池不是拍脑袋配的

线程池参数没有放之四海而皆准的“标准值”，但可以有一个工程化估算思路。

1. I/O 密集型任务

如果任务大部分时间都在等待网络、磁盘、远程服务，那么线程数通常可以比 CPU 核数高很多。

一个常见经验公式：

线程数 ≈ CPU核数 * 目标CPU利用率 * (1 + 等待时间 / 计算时间)

例如：

• 8 核机器
• 目标 CPU 利用率 0.8
• 平均等待时间 80ms
• 平均计算时间 20ms

则：

8 * 0.8 * (1 + 80/20) = 32

那 I/O 线程池可以从 24~32 这个量级开始压测验证。

2. CPU 密集型任务

如果任务主要是 JSON 解析、规则引擎计算、加解密、复杂对象转换，那么线程数通常不宜超过 CPU 核数太多。

一般建议：

CPU线程数 ≈ CPU核数 或 CPU核数 + 1

3. 队列长度怎么定

队列并不是越大越好。

• 队列太大：请求会悄悄排队，尾延迟飙升
• 队列太小：容易触发拒绝策略

在接口场景里，我更倾向于：

• 有限队列
• 结合拒绝策略
• 监控线程池活跃数、排队数、拒绝数

这样问题会尽早暴露，而不是堆积到系统不可恢复。

常见坑与排查

这一部分基本都是实战里最常见的坑。

1. 忘了传自定义线程池

现象

• 压测时吞吐不稳定
• 偶发请求超时
• 线程 dump 里看到很多 ForkJoinPool.commonPool-worker-*

原因

用了：

CompletableFuture.supplyAsync(() -> query());

没有传 Executor，默认走公共线程池。

建议

显式传入线程池：

CompletableFuture.supplyAsync(() -> query(), ioExecutor);

2. 在异步链里调用阻塞式 join/get

现象

• 明明是异步编排，却出现线程长时间阻塞
• 链路性能比串行还差

典型错误

CompletableFuture<User> userFuture = ...
CompletableFuture<Order> orderFuture = ...

CompletableFuture<Result> resultFuture = userFuture.thenApply(user -> {
    Order order = orderFuture.join(); // 阻塞等待
    return build(user, order);
});

问题

这会把“组合关系”写成“同步等待”，破坏异步优势。

正确方式

CompletableFuture<Result> resultFuture =
        userFuture.thenCombine(orderFuture, this::build);

3. 异常被包装，看不懂根因

join() 抛的是 CompletionException，get() 抛的是 ExecutionException。
真正的业务异常通常在 getCause() 里。

排查方式

try {
    future.join();
} catch (CompletionException e) {
    Throwable cause = e.getCause();
    cause.printStackTrace();
}

我自己排线上问题时，一般会要求日志明确打印：

• 外层异常类型
• 根因异常类型
• 任务名称
• 请求 ID
• 下游服务名

否则几乎没法快速定位。

4. 超时只作用在 Future，没作用在下游调用

现象

你写了：

future.orTimeout(300, TimeUnit.MILLISECONDS);

接口确实 300ms 返回了，但下游调用线程还没停，还在继续跑。

原因

CompletableFuture 超时控制的是“结果完成时间”，不等于自动中断底层 I/O 操作。

如果底层是 HTTP/RPC/数据库调用，还需要分别配置：

• 连接超时
• 读超时
• 请求超时

结论

Future 超时是上层兜底，不是下游超时配置的替代品。

5. 线程池拒绝策略选错

常见误区

很多人默认无脑用 CallerRunsPolicy。

它的特点是：线程池满了，提交任务的线程自己执行任务。
在 Web 场景里，这个“提交线程”往往就是请求处理线程。

结果就是：

• 本来想靠异步提速
• 线程池一满，主请求线程反而被拖去执行耗时任务
• 接口 RT 更不稳定

建议

• 对关键接口，优先让问题显式暴露，考虑 AbortPolicy
• 如果使用 CallerRunsPolicy，一定要明确知道对调用方线程的影响
• 拒绝计数必须监控

6. allOf 后直接 join，丢失单任务上下文

典型写法

CompletableFuture.allOf(f1, f2, f3).join();

如果其中一个失败，整体就失败了，但你不一定知道是哪一个失败、为什么失败。

更稳的方式

• 每个子任务自己记录任务名和耗时
• 关键任务单独加 exceptionally/handle
• 聚合时保留上下文字段

可观测性设计：别让异步链路变成黑盒

很多团队会做异步编排，但没有把可观测性同步设计进去。结果就是：代码看起来很优雅，出了问题完全抓瞎。

我建议至少覆盖三层。

1. 日志：每个阶段都要带任务名和请求上下文

最少要有：

• requestId / traceId
• taskName
• threadName
• start/end
• cost
• success/fail
• fallback 标记

如果使用 MDC，要注意线程切换会导致上下文丢失。
这时候可以：

• 在线程池封装时复制 MDC
• 或者显式把 requestId 作为参数透传

2. Metrics：监控“线程池健康度”和“任务质量”

建议打这些指标：

线程池维度

• pool_active_count
• pool_queue_size
• pool_rejected_count
• pool_completed_task_count

任务维度

• async_task_latency
• async_task_timeout_count
• async_task_exception_count
• async_task_fallback_count

接口维度

• 聚合总耗时
• 下游占比
• 慢任务 TopN

3. Trace：把异步阶段挂到同一条调用链

如果你接了 SkyWalking、Zipkin、Jaeger、OpenTelemetry，一定要确认异步线程切换后的 trace 上下文是否还能串起来。

很多时候链路断掉，不是因为没有埋点，而是上下文没有跨线程传播。

下面这个时序图可以帮助理解一个完整请求中发生了什么。

sequenceDiagram
    participant Client
    participant API as Aggregate API
    participant Pool as IO ThreadPool
    participant P as ProductService
    participant I as InventoryService
    participant R as PriceService

    Client->>API: 请求商品详情
    API->>Pool: 提交商品任务
    API->>Pool: 提交库存任务
    API->>Pool: 提交价格任务

    Pool->>P: queryProduct()
    Pool->>I: hasStock()
    Pool->>R: queryPrice()

    P-->>API: ProductInfo
    I-->>API: true/异常
    R-->>API: Price/超时

    API->>API: thenCombine 聚合
    API-->>Client: 返回 ProductDetail

安全/性能最佳实践

这里我把真正能落地的建议收敛成一组清单。

1. 线程池隔离优先于“一个大池通吃”

至少按下面维度拆：

• I/O 与 CPU 分离
• 核心链路与非核心链路分离
• 高风险下游单独隔离

如果某个三方接口经常抖动，最好单独给它一个小线程池，不要污染整个聚合服务。

2. 必须有超时、降级、限流三件套

异步不是万能加速器，它只是把“等待”并发化。
如果下游不稳定，异步只会更快地把线程池耗光。

建议：

• 每个远程调用设置底层超时
• 聚合层设置 Future 超时
• 关键依赖设置降级值
• 入口配限流/熔断

3. 轻逻辑用同步阶段，重逻辑再切异步

不要为了“看起来很异步”把每一步都写成 xxxAsync。
线程切换本身就有成本。

经验上：

• 轻量格式转换：thenApply
• 需要独立线程执行的耗时操作：thenApplyAsync

4. 谨慎在公共请求线程上做补偿逻辑

例如：

• 重试
• 大对象序列化
• 复杂降级构造
• 大量日志拼接

这些逻辑如果写在不合适的阶段，可能把本来很快的链路拖慢。

5. 控制对象大小，避免异步链路放大内存占用

异步任务一多，经常会把大量上下文对象挂在闭包里：

thenApply(result -> {
    // 捕获了一个很大的 request/context 对象
})

这会导致：

• 生命周期变长
• 堆内存占用增加
• Full GC 风险上升

建议：

• 只传必要字段
• 避免把整个大对象闭包捕获进去
• 聚合结果尽早释放中间态

6. 不要滥用异步处理极短任务

如果一个任务本身只要 1~2ms，而且没有外部等待，那么把它异步化往往得不偿失。

适合异步编排的通常是：

• 可并行
• 有明显等待时间
• 结果最终需要汇总

不适合异步的通常是：

• 强依赖顺序
• 逻辑极短
• 上下文切换成本大于任务本身

7. 安全角度：注意上下文泄漏与敏感信息传播

异步链路里容易出现两个安全问题：

上下文串线

如果使用 ThreadLocal 存用户上下文，而线程复用后没有清理，就可能出现请求间污染。

建议：

• 显式传参优先
• 使用线程池包装器做上下文复制与清理
• 避免把安全敏感数据长期放在线程上下文中

日志泄漏

异步异常日志很容易为了排查方便，直接把请求对象整体打印出来。
但里面可能包含：

• token
• 手机号
• 身份证号
• 地址等隐私数据

建议：

• 日志脱敏
• 只打印必要业务键
• 对异常日志字段做审计

JDK 8 环境下的超时处理补充

如果你还在 JDK 8，没有 orTimeout 和 completeOnTimeout，可以用 ScheduledExecutorService 自己做超时补全。

示例：

import java.util.concurrent.*;

public class TimeoutHelper {

    private static final ScheduledExecutorService scheduler =
            Executors.newScheduledThreadPool(1);

    public static <T> CompletableFuture<T> completeOnTimeout(
            CompletableFuture<T> future, T defaultValue, long timeout, TimeUnit unit) {

        scheduler.schedule(() -> future.complete(defaultValue), timeout, unit);
        return future;
    }
}

使用方式：

CompletableFuture<String> future =
        CompletableFuture.supplyAsync(() -> {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
            return "ok";
        });

TimeoutHelper.completeOnTimeout(future, "fallback", 200, TimeUnit.MILLISECONDS);

System.out.println(future.join());

当然，这种方式同样只是在 Future 层面兜底，不会自动中止底层阻塞调用。

一套更实用的落地建议

如果你准备在项目里推进 CompletableFuture 异步编排，我建议按下面顺序落地：

1. 先识别可并行的下游调用
2. 按任务类型拆线程池
3. 每个子任务显式定义超时与降级
4. 聚合层统一做结果合并
5. 每个阶段补日志、指标、trace
6. 压测验证线程池容量与拒绝策略
7. 用故障演练验证超时、异常、线程池满载时的表现

这个顺序很重要。
因为异步编排的收益从来不只是“代码写成链式”，而是整条链路在异常情况下还能可控。

总结

CompletableFuture 真正有价值的地方，不是让代码变得“更异步”，而是让我们可以用比较清晰的方式描述：

• 哪些任务并行
• 哪些任务依赖
• 哪些失败可降级
• 哪些超时要兜底
• 最后如何汇合成结果

但在生产环境里，CompletableFuture + 线程池 绝不是单纯的语法问题，而是一个完整的架构设计问题。你至少要同时考虑：

• 线程池隔离
• 超时与异常治理
• 拒绝策略
• 监控与链路追踪
• 内存与上下文传递
• 边界条件下的降级行为

如果你只记住几条最重要的建议，我会给下面这份精简版：

1. 永远显式传线程池，不要依赖默认公共池
2. I/O 和 CPU 任务分池
3. 优先用组合 API，不要在链路里乱 join()
4. 每个子任务单独处理异常、超时和降级
5. 异步阶段必须可观测：日志、指标、trace 缺一不可
6. 先压测再上线，别拍脑袋设线程池参数

最后补一句边界判断：
如果你的业务链路很短、下游很少、耗时也不高，那没必要为了“架构高级感”强上异步编排。异步最适合的是多依赖聚合、耗时可并行、对尾延迟敏感的场景。用对了，它是提效利器；用错了，它会把问题藏得更深。