CompletableFuture 异步编排深度CompletableFuture 是 Java 异步编程的声明式革命—

概述

前文《Optional 的单子特性与反模式》展示了如何通过链式调用安全地处理“现在可能没有”的值。但还有一种更复杂的情况：值“现在还没有，未来会有”——异步调用的结果。JDK 5 的 Future 只能阻塞等待，无法声明式地编排后续操作。JDK 8 的 CompletableFuture 填补了这一空白：它实现了 CompletionStage 接口，让开发者可以用 thenApply/thenCompose/thenCombine 等声明式方法，像搭积木一样编排异步任务。如果说 Optional 是值的“存在性容器”，那么 CompletableFuture 就是值的“时间性容器”。系列①第5篇的 MethodHandle 和系列③第1篇的 invokedynamic，共同构成了 CompletableFuture 链式调用的底层性能保障。

“CompletableFuture 默认用 ForkJoinPool.commonPool() 执行异步任务，为什么 I/O 密集型场景会出问题？”“thenApply 和 thenCompose 都是转换，为什么不能混用？”“allOf 等待所有任务完成后怎么拿到每个任务的结果？”“anyOf 竞速模式下，其他未完成的任务会被取消吗？”“exceptionally 和 handle 都能处理异常，什么时候用哪个？”——这些问题的答案，藏在 CompletableFuture 对 CompletionStage 接口的精确实现和线程池策略的默认选择中。本文将从 CompletionStage 契约出发，通过 supplyAsync 的线程池陷阱、链式编排的方法选型决策树、竞速与全等待的工程案例、异常处理的三层武器对比，完整揭示 CompletableFuture 如何将回调地狱转换为声明式异步编排。

核心要点

CompletionStage 接口：定义 40+ 个编排方法，CompletableFuture 是其唯一实现
默认线程池陷阱：ForkJoinPool.commonPool() 不适合 I/O 密集型任务
thenApply 同步转换 vs thenCompose 异步组合 vs thenCombine 合并双 Future
anyOf 竞速取最快 vs allOf 全等待手动收集结果
exceptionally 异常恢复 vs handle 全路径处理 vs whenComplete 副作用回调
JDK 9 增强：completeOnTimeout/orTimeout/delayedExecutor 超时控制

flowchart TB
    A["1. CompletableFuture 核心能力<br/>CompletionStage 契约与 Future 进化"] --> B["2. 异步执行与线程池<br/>supplyAsync/runAsync 默认策略与陷阱"]
    B --> C["3. 链式编排<br/>thenApply/thenCompose/thenCombine/thenAccept/thenRun"]
    C --> D["4. 竞速与等待<br/>anyOf 多路竞速 / allOf 全等待与结果收集"]
    D --> E["5. 异常处理<br/>exceptionally/handle/whenComplete 语义差异"]
    E --> F["6. JDK 9 增强前瞻<br/>超时控制/延迟执行/失败工厂"]
    F --> G["7. 工程实战<br/>多服务并行调用、超时回退、异步回调查询"]
    G --> H["8. 系列③收尾<br/>函数式编程与 Stream 知识体系总结"]

    classDef default fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b
    class A,B,C,D,E,F,G,H default1

a) 主旨概括：上图展示全文8个模块的递进路径，从 CompletableFuture 的核心契约出发，逐步深入到线程池策略、链式编排、竞速等待、异常处理、版本前瞻与工程实战，最后完成系列③的知识闭环。
b) 逐元素分解：模块1-2建立基础认知，模块3-5构成编排核心三角，模块6展望演进方向，模块7回归生产场景，模块8收尾总结。箭头表示依赖递进关系。
c) 设计原理映射：文章刻意将“任务提交→编排→消费→容错”的完整生命周期分散在各模块中，确保读者形成端到端的认知路径，而非零散 API 记忆。
d) 工程联系与关键结论：CompletableFuture 是 Java 异步编程的声明式革命——它将 Future 的阻塞等待升级为 CompletionStage 的链式编排，用 thenApply/thenCompose 串联异步任务，用 anyOf/allOf 实现竞速与并行，用 exceptionally/handle 优雅处理异常。但默认的 commonPool 是 I/O 密集型场景的陷阱，必须根据任务类型选择合适的线程池。

1. CompletableFuture 核心能力：CompletionStage 契约与 Future 进化

CompletableFuture 是 java.util.concurrent 包在 JDK 8 引入的里程碑式类型。要理解它的威力，必须先看清它的双重身份：它同时实现了 Future 和 CompletionStage 两个接口。Future 代表一个异步计算的结果容器，而 CompletionStage 则定义了一个异步计算阶段，可以在该阶段完成后触发后续操作。这种双重身份使 CompletableFuture 既是异步结果的承载者，又是声明式编排的构建块。

CompletionStage 接口定义了超过40个方法，它们按模式分为几大类：

转换类：thenApply、thenCompose——对上一步结果进行转换
消费类：thenAccept、thenRun——消费结果但不产出新值
合并类：thenCombine、thenAcceptBoth、runAfterBoth——等待两个阶段完成后合并
竞速类：applyToEither、acceptEither、runAfterEither——两个阶段中任一完成即触发
异常处理类：exceptionally、handle、whenComplete——处理异常或执行副作用

每个方法都有三种变体：默认执行（由前驱阶段的线程池决定）、...Async（使用默认 ForkJoinPool.commonPool()）、...Async(executor)（使用指定线程池）。这种设计为开发者提供了精细的线程控制力。

CompletableFuture 内部使用了一个精巧的 Treiber Stack（无锁栈）来管理依赖阶段，核心内部类是 Completion，其子类 UniApply、UniCompose、BiApply 等分别对应不同的编排操作。当阶段完成时，它会尝试将结果 CAS 到 result 字段，然后遍历并触发栈中的所有 Completion 对象。这种无锁设计使得高并发场景下的阶段触发开销极低。

主动完成：CompletableFuture 不仅可以由异步任务自动完成，还可以手动完成。complete(T value) 方法强行将 Future 标记为正常完成并设值；completeExceptionally(Throwable ex) 则标记为异常完成。这两个方法是将传统的回调风格 API 转换为 CompletableFuture 的桥梁。例如，我们可以将一个基于监听器的异步 HTTP 客户端包装如下：

public CompletableFuture<String> asyncHttpCall(String url) {
    CompletableFuture<String> future = new CompletableFuture<>();
    httpClient.execute(url, new Callback() {
        @Override
        public void onSuccess(String result) {
            future.complete(result);
        }
        @Override
        public void onError(Throwable ex) {
            future.completeExceptionally(ex);
        }
    });
    return future;
}

此片段展示了 complete / completeExceptionally 的桥接能力：原本回调风格的 API 被转换成标准的 CompletableFuture，后续可以无缝接入声明式编排链。

与 Future 的对比：JDK 5 的 Future 提供了 get()（阻塞等待结果）、isDone()（判断是否完成）和 cancel()（取消任务）。当我们需要“先查缓存，查不到再查数据库”这种复杂流程时，只能通过反复调用 isDone() 或嵌套 get() 实现，不仅线程利用率低，而且逻辑分散。CompletableFuture 将这类流程变为声明式的链式调用，读写比从混乱的 if-else 提升至清晰的数据流。

下面这张状态机图概括了 CompletableFuture 的生命周期：

flowchart LR
    A((创建)) --> B[Uncompleted]
    B --> C[Completed<br/>Normal]
    B --> D[Completed<br/>Exceptionally]
    B --> E[Cancelled]

a) 主旨概括：CompletableFuture 从创建时的未完成状态出发，最终可能进入正常完成、异常完成或取消三种终态。
b) 逐元素分解：Uncompleted 表示尚未有结果或异常写入；Normal 由 complete(T) 或异步任务正常返回触发；Exceptionally 由 completeExceptionally(Throwable) 或任务抛出异常触发；Cancelled 由 cancel(true) 触发。
c) 设计原理映射：内部通过 result 字段的 CAS 操作实现状态变更，一旦进入终态便不可逆转，保证了结果的最终一致性。
d) 工程联系与关键结论：理解状态机是正确编排异步任务的前提——未完成的阶段不能提供结果，异常完成的阶段会在链式调用中触发异常传播，只有正常完成的阶段才会驱动后续转换。

flowchart TB
    subgraph ConvertSub["转换"]
        A1["thenApply<br/>T → U"]
        A2["thenCompose<br/>T → CompletionStage&lt;U&gt;"]
    end
    subgraph ConsumeSub["消费"]
        B1["thenAccept<br/>Consumer&lt;T&gt;"]
        B2["thenRun<br/>Runnable"]
    end
    subgraph CombineSub["合并"]
        C1["thenCombine<br/>T,U → V"]
        C2["thenAcceptBoth<br/>Consumer&lt;T,U&gt;"]
        C3["runAfterBoth<br/>Runnable"]
    end
    subgraph RaceSub["竞速"]
        D1["applyToEither<br/>T → U"]
        D2["acceptEither<br/>Consumer&lt;T&gt;"]
        D3["runAfterEither<br/>Runnable"]
    end

    classDef subStyle fill:#e0e8f0,stroke:#8ba0aa,stroke-width:1.5px
    classDef nodeStyle fill:#f4f6f9,stroke:#cbd5e1,stroke-width:1.5px,color:#1e293b

    class ConvertSub,ConsumeSub,CombineSub,RaceSub subStyle
    class A1,A2,B1,B2,C1,C2,C3,D1,D2,D3 nodeStyle

a) 主旨概括：CompletionStage 的编排方法分为转换、消费、合并、竞速四大类，覆盖了所有常见的异步流程模式。
b) 逐元素分解：转换类产出一个新的 CompletionStage，携带转换结果；消费类不产出新值，用于触发副作用或最终处理；合并类等待两个前置阶段均完成后执行；竞速类在任一前置阶段完成后就触发。
c) 设计原理映射：这种分类直接映射到函数式编程中的 map、flatMap、consumer、combine、race 等抽象，使异步编排可以像流操作一样声明式组合。
d) 工程联系与关键结论：选择合适的编排方法能避免线程阻塞和资源浪费。例如需要依赖前一步结果再发起异步调用时用 thenCompose 而非 thenApply，避免产生嵌套的 CompletableFuture。

2. 异步执行与线程池：supplyAsync/runAsync 的默认策略与陷阱

CompletableFuture 提供了两个静态工厂方法启动异步计算：

supplyAsync(Supplier supplier)：执行一个带返回值的任务，返回 CompletableFuture
runAsync(Runnable runnable)：执行一个无返回值的任务，返回 CompletableFuture<Void>

它们的默认线程池是 ForkJoinPool.commonPool()。这是一个在整个 JVM 范围内共享的 ForkJoinPool 实例，默认并行度（parallelism）等于 Runtime.getRuntime().availableProcessors() - 1（通常为 CPU 核心数 - 1）。例如在一台 8 核机器上，commonPool() 的并行度是 7。

这个设计对于 CPU 密集型计算是合理的：并行度略低于核心数，可以避免过度争抢 CPU。但问题在于，许多异步任务本质上是 I/O 密集型 的——数据库查询、HTTP 调用、文件读取等。这些操作大部分时间在等待 I/O，线程处于阻塞状态。如果开发者将这类任务直接丢给 commonPool()，就会造成灾难性后果：少量线程被阻塞后，新的异步任务无法获得线程，导致整个 JVM 中所有依赖 commonPool() 的模块（包括并行 Stream、CompletableFuture 默认异步变体）全部饿死。

示例：假设一个 Web 应用使用 CompletableFuture.supplyAsync(() -> dao.query()) 来异步查询数据库。当并发请求到来时，commonPool() 的 7 个线程很快被数据库 I/O 阻塞，此时即使有新的 CPU 密集型任务提交，也无法被执行，最终服务响应超时。这就是著名的 “公共 ForkJoinPool 饥饿” 陷阱。

解决方案：传入自定义线程池。

ExecutorService ioPool = Executors.newFixedThreadPool(20);
CompletableFuture<String> future = CompletableFuture.supplyAsync(() -> {
    // 执行数据库查询等 I/O 操作
    return dao.query();
}, ioPool);

为 I/O 密集型任务分配独立的线程池，避免阻塞 commonPool()。线程池大小可根据《Java 并发编程实战》中的公式估算：N_threads = N_cpu * U_cpu * (1 + W/C)，其中 W/C 是等待时间与计算时间的比率。

除 supplyAsync 外，所有带 Async 后缀且未指定 Executor 的编排方法（如 thenApplyAsync(fn)）也默认使用 commonPool()。因此，在 I/O 密集场景下，建议显式传入 Executor。Spring 框架的 ThreadPoolTaskExecutor 是常用的封装，其底层为 ThreadPoolExecutor，支持队列大小、拒绝策略等细粒度配置。

// 使用 thenApplyAsync 时指定线程池
future.thenApplyAsync(result -> process(result), ioPool);

显式传入线程池可以保证整个编排链都运行在可控的线程资源上，避免混入 commonPool()。

对于真正 CPU 密集型的任务（如数据压缩、加密、复杂计算），继续使用 commonPool() 是合理的选择，因为它能复用 JVM 级别的并行度调控，且避免了线程过多导致的上下文切换开销。最佳实践是：根据任务类型分离线程池，I/O 密集型任务使用自定义的缓存线程池或固定大小线程池，CPU 密集型任务使用 commonPool 或并行度等于核心数的 ForkJoinPool。

3. 链式编排：thenApply / thenCompose / thenCombine / thenAccept / thenRun

链式编排是 CompletableFuture 的灵魂。开发者通过一系列转换和消费方法，将多个异步步骤串联成流水线，整个代码读起来如同同步业务逻辑，但实际运行时异步非阻塞。

3.1 thenApply：同步转换

CompletableFuture<String> future = CompletableFuture
    .supplyAsync(() -> "Hello")
    .thenApply(s -> s + " World");

thenApply 接收一个 Function<? super T, ? extends U>，对前驱阶段的结果进行同步转换，返回新的 CompletableFuture。转换函数 fn 由哪个线程执行？这取决于前驱阶段的完成方式：如果前驱阶段是由某个线程完成的（例如执行 supplyAsync 的线程），那么 fn 会在该线程中直接运行，避免不必要的线程切换。只有当前驱阶段已完成而执行 thenApply 注册时，fn 才会在注册线程中立即执行。

3.2 thenCompose：异步组合，避免双层包装

当转换操作本身就是一个异步调用时，必须使用 thenCompose 而非 thenApply。原因如下：

// 错误：thenApply 导致 CompletableFuture<CompletableFuture<String>>
CompletableFuture<CompletableFuture<String>> nested = 
    future.thenApply(s -> asyncCall(s));   // asyncCall 返回 CompletableFuture<String>

// 正确：thenCompose 解包为 CompletableFuture<String>
CompletableFuture<String> flat = 
    future.thenCompose(s -> asyncCall(s));

thenCompose 的参数类型是 Function<? super T, ? extends CompletionStage>，它接收一个返回 CompletionStage 的函数，并自动将其“展平”（flatMap）。这与 Optional.flatMap 同出一辙，防止出现嵌套容器。

类型转换对比图：

flowchart TD
    subgraph ApplySub["thenApply"]
        A1["CompletableFuture&lt;T&gt;"] -->|"thenApply<br/>T → U"| B1["CompletableFuture&lt;U&gt;"]
    end
    subgraph ComposeSub["thenCompose 避免嵌套"]
        A2["CompletableFuture&lt;T&gt;"] -->|"thenCompose<br/>T → CompletionStage&lt;U&gt;"| B2["CompletableFuture&lt;U&gt;"]
    end
    subgraph ErrorSub["thenApply 错误用法"]
        A3["CompletableFuture&lt;T&gt;"] -->|"thenApply<br/>T → CompletableFuture&lt;U&gt;"| B3["CompletableFuture&lt;CompletableFuture&lt;U&gt;&gt;"]
    end

    classDef subStyle fill:#e0e8f0,stroke:#8ba0aa,stroke-width:1.5px
    classDef nodeStyle fill:#f4f6f9,stroke:#cbd5e1,stroke-width:1.5px,color:#1e293b

    class ApplySub,ComposeSub,ErrorSub subStyle
    class A1,B1,A2,B2,A3,B3 nodeStyle

a) 主旨概括：thenApply 适用于同步转换，thenCompose 适用于依赖前驱结果的异步转换，两者不可互换，否则将产生嵌套的 CompletableFuture。
b) 逐元素分解：thenApply 的 Function 返回普通值，容器不变；thenCompose 的 Function 返回 CompletionStage，容器自动展平；错误地将异步调用交给 thenApply 会得到双层容器。
c) 设计原理映射：thenCompose 本质上实现了 Monad 的 flatMap 操作，使得多个异步步骤可以线性串联，而不会出现容器嵌套。
d) 工程联系与关键结论：任何需要基于上一步结果再次发起异步调用（如 HTTP、数据库）的场景，必须使用 thenCompose。thenApply 仅适用于纯内存的同步转换。

3.3 thenCombine：合并两个独立的 Future

当需要同时执行两个互不依赖的异步任务，并在两者都完成后合并结果时，使用 thenCombine：

CompletableFuture<String> userFuture = CompletableFuture.supplyAsync(() -> getUser());
CompletableFuture<String> orderFuture = CompletableFuture.supplyAsync(() -> getOrders());
CompletableFuture<String> result = userFuture.thenCombine(orderFuture, 
    (user, orders) -> user + ": " + orders);

thenCombine 接收一个 CompletionStage 和一个 BiFunction<T, U, V>，当两个阶段都正常完成后，用 BiFunction 合并结果。两个异步任务并行执行，互不阻塞。

3.4 thenAccept 与 thenRun

thenAccept(Consumer<? super T> action)：消费上一步的结果，不返回新值。常用于最终处理（如写入 HTTP 响应）。
thenRun(Runnable action)：不消费结果，仅在上一步完成后执行一个动作（如清理资源、发送通知）。

future.thenAccept(result -> response.getWriter().write(result));
future.thenRun(() -> System.out.println("任务完成"));

这两个方法标志着编排链的终点：它们不产生新的 CompletionStage（实际返回 CompletableFuture<Void>），而是消费最终结果或执行副作用。

方法选型决策树：若需返回新值 → 转换类；若转换本身是异步 → thenCompose；若需要两个独立结果 → thenCombine；若仅消费 → thenAccept/thenRun。实际开发中，一个典型链路可能是 supplyAsync 发起异步调用 → thenCompose 基于结果二次调用 → thenApply 转换格式 → thenAccept 输出。

4. 竞速与等待：anyOf 多路竞速 / allOf 全等待与结果收集

4.1 anyOf：竞速模式

CompletableFuture<Object> any = CompletableFuture.anyOf(
    CompletableFuture.supplyAsync(() -> queryRedis()),
    CompletableFuture.supplyAsync(() -> queryDB())
);

anyOf 接收一组 CompletableFuture，返回一个新的 CompletableFuture<Object>。只要其中任意一个正常完成（或异常完成），返回的 Future 就会完成。注意返回类型为 Object，因为静态类型系统中无法在编译期确定哪个 Future 会先返回。

典型场景：多路冗余查询——同时查 Redis 和 DB，取最快的结果以降低延迟。需要注意的是，anyOf 不会取消未完成的其他任务，因此那些还在执行的任务会继续消耗资源，直到自行结束。如果需要对未完成的任务进行取消，需要手动持有其他 Future 引用并调用 cancel(true)。

4.2 allOf：全等待模式

CompletableFuture<String> f1 = CompletableFuture.supplyAsync(() -> "A");
CompletableFuture<String> f2 = CompletableFuture.supplyAsync(() -> "B");
CompletableFuture<Void> all = CompletableFuture.allOf(f1, f2);
// 收集结果
CompletableFuture<String> combined = all.thenApply(v -> f1.join() + f2.join());

allOf 返回 CompletableFuture<Void>，不携带合并结果。这是因为多个 Future 的类型可能不同，无法用统一的静态类型表达。开发者需要手动通过 join()（或 get()）获取各 Future 的结果。此处 join() 与 get() 类似，但不抛出受检异常，使 lambda 更简洁。因为 thenApply 中的代码执行时所有 Future 已经完成，join() 会立即返回，不会阻塞。

工程应用：并行调用多个微服务后组装数据。例如订单详情页需要并行获取商品、用户、物流信息，用 allOf 等待所有结果就绪后合并。

flowchart TD
    subgraph anyOf 竞速
        direction TB
        A1[Future 1] --> R1{anyOf}
        A2[Future 2] --> R1
        R1 --> Result1[Object 结果<br/>取最快完成]
    end
    subgraph allOf 全等待
        direction TB
        B1[Future 1] --> R2{allOf}
        B2[Future 2] --> R2
        R2 --> Result2[Void<br/>手动收集结果]
    end

a) 主旨概括：anyOf 是竞速模型，取最先完成的结果；allOf 是同步栅栏，等待所有结果都就绪。
b) 逐元素分解：anyOf 返回 Object，适合“任一成功即可”的场景；allOf 返回 Void，需要后续通过 join 手动组装，适合“全部成功才继续”的场景。
c) 设计原理映射：两者均是函数式并发原语：anyOf 对应逻辑 OR（任一满足），allOf 对应逻辑 AND（全部满足）。
d) 工程联系与关键结论：anyOf 不会取消未完成的任务，需注意资源泄露；allOf 必须手动收集结果，且要处理部分 Future 可能异常完成的情况，否则 join() 会抛出 CompletionException。

5. 异常处理：exceptionally / handle / whenComplete 的语义差异

异步编排中，异常处理直接决定系统的健壮性。CompletableFuture 提供了三层武器，分别适用于不同场景。

5.1 exceptionally：仅处理异常，提供默认值恢复

CompletableFuture<String> safe = future
    .exceptionally(ex -> {
        log.error("异常发生", ex);
        return "default";
    });

exceptionally 的参数是 Function<Throwable, ? extends T>，仅当前驱阶段异常完成时被调用。它无法访问正常结果，也无法改变正常路径的数据流。本质上是“异常恢复”操作——将异常分支重新拉回正常轨道。

5.2 handle：全路径处理，正常和异常均可转换

CompletableFuture<String> handled = future
    .handle((result, ex) -> {
        if (ex != null) {
            return "fallback";
        }
        return result.toUpperCase();
    });

handle 接收 BiFunction<? super T, Throwable, ? extends U>，两个参数中必有一个为 null：正常完成时 result 有值、ex 为 null；异常完成时 result 为 null、ex 有值。因此 handle 可以同时处理两条路径，并将结果转换成新类型。

5.3 whenComplete：副作用回调，不改变结果

CompletableFuture<String> withLog = future
    .whenComplete((result, ex) -> {
        if (ex != null) {
            log.error("失败", ex);
        } else {
            log.info("成功: {}", result);
        }
    });

whenComplete 的参数与 handle 相同，但它不改变结果：返回的 CompletableFuture 的结果或异常与原 Future 完全一致。它纯粹用于执行副作用，如日志、指标收集、资源清理。

异常传播机制：如果在链式调用的某个阶段抛出异常，该异常会沿着依赖链向下游传播，直到遇到 exceptionally 或 handle。若整个链末端仍未被处理，当调用 get() 或 join() 时，会抛出 ExecutionException（get）或 CompletionException（join），包装原始异常。

flowchart TD
    subgraph exceptionally
        E1[异常] -->|exceptionally| E2[返回默认值<br/>恢复正常]
    end
    subgraph handle
        H1[正常] -->|handle| H2[转换结果]
        H3[异常] -->|handle| H4[转换结果或恢复]
    end
    subgraph whenComplete
        W1[正常/异常] -->|whenComplete| W2[记录日志等<br/>不改变结果]
    end

a) 主旨概括：exceptionally 是异常恢复专用；handle 是全能转换器；whenComplete 是纯副作用。
b) 逐元素分解：exceptionally 仅接收异常参数，返回替代值；handle 同时接收结果和异常，可转换输出；whenComplete 接收结果和异常但不改变向下游传递的值。
c) 设计原理映射：这些方法均遵循了函数式设计中的“关注点分离”：恢复、转换、观察三者职责清晰，可组合使用。
d) 工程联系与关键结论：降级策略首选 exceptionally；需要对结果和异常统一处理（如转成统一响应对象）用 handle；记录日志或上报监控必须在 whenComplete 中，以确保不会意外篡改业务数据。

6. JDK 9 增强前瞻：超时控制 / 延迟执行 / 失败工厂

JDK 9 为 CompletableFuture 补充了几个痛点能力，主要围绕超时控制和便捷构建。在 JDK 8 环境下，可以通过一些技巧模拟，但原生的支持更优雅。

completeOnTimeout(T value, long timeout, TimeUnit unit)：如果在给定时间内未完成，就用指定的值强制完成。这相当于给异步任务设置一个软超时——超时后返回降级值，任务本身可能仍在执行，但其结果会被丢弃。
orTimeout(long timeout, TimeUnit unit)：超时未完成则异常完成，抛出的异常为 TimeoutException。这是一个硬超时，适合“超时即失败”的场景。
delayedExecutor(long delay, TimeUnit unit)：返回一个延迟执行任务的 Executor，可用于实现延迟调用。
failedFuture(Throwable ex)：便捷地创建一个已异常完成的 CompletableFuture，常用于降级返回。

在 JDK 8 工程中，模拟超时控制通常需要结合 ScheduledExecutorService 和 completeExceptionally：

public <T> CompletableFuture<T> withTimeout(CompletableFuture<T> future, 
                                            long timeout, TimeUnit unit) {
    ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
    CompletableFuture<T> result = new CompletableFuture<>();
    // 超时后强制异常完成
    scheduler.schedule(() -> result.completeExceptionally(new TimeoutException()), 
                       timeout, unit);
    // 原任务完成后传递给 result
    future.whenComplete((v, ex) -> {
        if (ex != null) result.completeExceptionally(ex);
        else result.complete(v);
    });
    return result;
}

通过手动编织，JDK 8 也能实现超时控制，但 JDK 9 的 orTimeout 内建支持更加简洁且避免了额外的线程池管理。

尽管本文基于 JDK 8，但这些增强在生产中已逐步可用（通过多版本 jar 或升级至 JDK 11+），建议在架构中预留升级空间。

7. 工程实战：多服务并行调用、超时回退、异步回调查询

综合前面所有知识，我们通过一个典型微服务聚合场景来展示 CompletableFuture 的生产实践。假设一个订单详情接口需要并行调用三个服务：商品服务（50ms）、库存服务（30ms）、评价服务（100ms）。要求商品服务必须成功，库存和评价可降级。整体超时 200ms。

public OrderDetailDTO getOrderDetail(String orderId) {
    // 使用自定义线程池，避免阻塞 commonPool
    ExecutorService exec = Executors.newFixedThreadPool(10);
    
    // 商品服务（必须成功）
    CompletableFuture<Product> productFuture = CompletableFuture
        .supplyAsync(() -> productService.getProduct(orderId), exec);
    
    // 库存服务（可降级）
    CompletableFuture<Integer> stockFuture = CompletableFuture
        .supplyAsync(() -> inventoryService.getStock(orderId), exec)
        .exceptionally(ex -> 0); // 降级为0
    
    // 评价服务（可降级）
    CompletableFuture<List<Review>> reviewsFuture = CompletableFuture
        .supplyAsync(() -> reviewService.getReviews(orderId), exec)
        .exceptionally(ex -> Collections.emptyList());
    
    // 组装结果
    CompletableFuture<OrderDetailDTO> resultFuture = productFuture
        .thenCombine(stockFuture, (product, stock) -> 
            new OrderDetailDTO(product, stock, null))
        .thenCombine(reviewsFuture, (dto, reviews) -> {
            dto.setReviews(reviews);
            return dto;
        });
    
    // 超时控制（JDK 8 模拟）
    try {
        return resultFuture.get(200, TimeUnit.MILLISECONDS);
    } catch (TimeoutException e) {
        // 超时返回已组装的部分数据，或触发最终降级
        return buildFallbackDTO(orderId);
    } catch (Exception e) {
        throw new RuntimeException("订单详情聚合失败", e);
    }
}

代码清晰地展示了并行调用、异常降级、结果合并和超时控制。每个 CompletableFuture 如同一个数据管道，声明了数据的来源与转换规则，最终汇聚成聚合结果。

与 Spring WebFlux 的关联：CompletableFuture 是 Spring Framework 的 @Async 返回值，也是 WebFlux 响应式栈与 Servlet 栈之间的桥梁。在 Spring WebFlux 中，Mono 和 Flux 提供了更强大的背压和操作符，但 CompletableFuture 可作为 Mono.fromFuture() 的源，实现命令式异步与响应式的混合。CompletableFuture 的非阻塞编排思想直接影响了 Reactor 的设计，thenApply 对应 map，thenCompose 对应 flatMap，exceptionally 对应 onErrorReturn。掌握 CompletableFuture 是理解响应式编程的关键一步。

多服务并行调用时序图：

sequenceDiagram
    participant Client as 客户端
    participant OrderService as 聚合层
    participant ProductService as 商品服务
    participant InventoryService as 库存服务
    participant ReviewService as 评价服务

    Client->>OrderService: 请求订单详情
    OrderService->>ProductService: supplyAsync 获取商品
    OrderService->>InventoryService: supplyAsync 获取库存
    OrderService->>ReviewService: supplyAsync 获取评价
    ProductService-->>OrderService: 商品信息 (50ms)
    InventoryService-->>OrderService: 库存信息 (30ms)
    ReviewService-->>OrderService: 评价信息 (100ms)
    OrderService->>OrderService: thenCombine 合并结果
    OrderService-->>Client: 订单详情DTO

a) 主旨概括：聚合层通过 CompletableFuture 同时发起三个服务调用，等待全部就绪后合并，最大延迟由最慢的调用决定（100ms），而非顺序调用的总和。
b) 逐元素分解：supplyAsync 并发发起三个调用；exceptionally 提供库存和评价的降级值；thenCombine 串行合并结果；get(timeout) 实现整体超时。
c) 设计原理映射：利用异步非阻塞特性将串行依赖转化为并行等待，显著降低 p99 延迟。异常降级保证核心路径不被非关键数据阻塞。
d) 工程联系与关键结论：在微服务聚合中，CompletableFuture 的声明式编排可将原本复杂的线程协调代码简化到几十行，且异常路径清晰可测。但务必使用自定义线程池，并妥善处理部分失败和超时。

8. 系列③收尾：函数式编程与 Stream 知识体系总结

至此，系列③“函数式编程与 Stream”5篇文章已全部完成。我们从 Java 8 引入的核心武器出发，构建了一条从“如何写函数”到“如何编排异步”的完整知识链：

Lambda 表达式与函数式接口：函数是一等公民，Function<T,R>、Consumer<T>、Supplier<T> 等是砖石。
Stream 流水线与惰性求值：声明式数据处理，构建 源→中间操作→终端操作 的管道，借助 Sink 责任链实现短路与惰性。
Collector 收集器与自定义归约：将流的结果聚合为集合、字符串、分组、分区，Collectors 工厂与自定义 Collector 四方法。
Optional 单子特性与反模式：类型安全的 null 替代，map/flatMap/filter 链式安全访问，禁止用于字段和参数。
CompletableFuture 异步编排（本文）：声明式编排异步任务，thenApply/thenCompose/thenCombine 串联与合并，anyOf/allOf 竞速与等待，三层异常处理。

它们之间层层递进，构成了 Java 函数式编程的四大支柱：

flowchart LR
    L[Lambda 表达式<br/>函数是一等公民] --> S[Stream API<br/>声明式数据处理]
    S --> C[Collector<br/>灵活归约收集]
    C --> O[Optional<br/>安全的值存在性]
    O --> CF[CompletableFuture<br/>时间上的值容器]

a) 主旨概括：整个系列从最基础的 Lambda 表达式出发，逐步构建出 Stream 的流水线思维、Collector 的归约抽象、Optional 的空值安全，最后抵达异步编排的声明式编程范式。
b) 逐元素分解：Lambda 是语法基础，Stream 将其应用于集合处理，Collector 提供了终态聚合，Optional 处理“现在可能没有”的值，CompletableFuture 处理“未来才会有”的值。
c) 设计原理映射：这五个主题共同体现了“声明式编程”的核心思想：描述做什么，而不是一步步怎么做。它们大量借用函数式编程的概念（Monad、Functor、惰性求值），使得 Java 在保持向后兼容的同时融入了现代编程语言的能力。
d) 工程联系与关键结论：掌握这一体系，意味着你不仅能写出更简洁、更安全的 Java 代码，还能在微服务编排、并发处理、数据管道等复杂场景中，用函数式的思维解决命令式难以驾驭的难题。这一能力直接对标 Reactor、Kotlin 协程等先进技术的底层心智模型。

面试高频专题

题目 1：CompletableFuture 和 Future 有什么区别？为什么说 CompletableFuture 是声明式异步编程？

① 一句话回答：Future 只是结果的容器，需阻塞 get() 获取结果，无回调无编排；CompletableFuture 实现了 CompletionStage，可链式声明后续转换、组合和异常处理，是声明式异步编程的核心工具。

② 详细解释：Future 从 JDK 5 引入，暴露 get()、isDone() 和 cancel()。当有多个异步依赖时，必须通过轮询 isDone() 或阻塞嵌套 get() 实现，代码迅速陷入回调地狱。CompletableFuture 通过 thenApply、thenCompose、thenCombine 等方法将后续步骤声明为转换函数，形成数据流图。运行时，框架自行管理线程调度和阶段触发，开发者只需描述“数据到了做什么”。这种声明式方式与 Stream 的 filter-map-collect 一脉相承。

③ 多角度追问

架构：CompletableFuture 内部的无锁栈（Treiber Stack）如何保证高并发下的线程安全？
性能：声明式编排的额外对象分配开销有多大？对 GC 的影响如何优化？
运维：如何监控 CompletableFuture 链中某个阶段的失败率和延迟？

④ 加分回答：CompletableFuture 的设计直接影响了 Java 9 的 Flow API 和后续的响应式框架（Reactor、RxJava）。它本质上是异步计算的 Monad，thenCompose 是 flatMap，thenApply 是 map。了解这一数学基础，能从更抽象的层面理解异步组合。

题目 2：CompletableFuture 的默认线程池是什么？为什么 I/O 密集型任务不能用默认线程池？如何自定义线程池？

① 一句话回答：默认使用 ForkJoinPool.commonPool()，它是一个 JVM 共享的、并行度为 CPU 核心数-1 的线程池，适合 CPU 密集型任务。I/O 密集型任务会阻塞其中少量线程，导致所有依赖该池的异步任务全部饥饿。

② 详细解释：commonPool() 通过系统属性 java.util.concurrent.ForkJoinPool.common.parallelism 配置，默认为 Runtime.availableProcessors() - 1。当执行 I/O 操作时，线程进入 BLOCKED 或 WAITING 状态，不释放 CPU 但仍占用池中的位置。可用线程减少后，新提交的任务必须等待，最终引发超时甚至服务雪崩。解决方案是使用 supplyAsync(supplier, executor) 或 thenApplyAsync(fn, executor) 传入自定义线程池，例如 Executors.newFixedThreadPool(n) 或 ThreadPoolExecutor。

③ 多角度追问

安全：如果不小心在 commonPool() 中执行了阻塞操作，如何快速定位？
性能：自定义线程池的核心线程数、最大线程数和队列长度如何根据业务特点计算？
运维：线上如何动态调整线程池参数而不重启服务？

④ 加分回答：Netty 和 Reactor 的线程模型刻意避开了 commonPool()，使用 EventLoopGroup 来避免阻塞。CompletableFuture 结合自定义线程池是构建高性能网关聚合层的核心手段之一，阿里巴巴的 Sentinel 在异步调用链中也利用了类似模式。

题目 3：thenApply 和 thenCompose 的核心区别是什么？什么情况下 thenApply 会导致 CompletableFuture<CompletableFuture<T>> 的双层包装？

① 一句话回答：thenApply 适用于同步转换（T -> U），thenCompose 适用于异步转换（T -> CompletionStage）。如果将返回 CompletableFuture 的函数传入 thenApply，会得到两层嵌套的 CompletableFuture。

② 详细解释：thenApply 的 Function 返回一个普通值，框架自动将其包装成新的 CompletableFuture。如果 Function 本身返回 CompletableFuture，那么外层 CompletableFuture 的结果类型就是 CompletableFuture，产生类型嵌套。这种嵌套会导致后续编排必须调用 .thenCompose(v -> v) 或手动 join() 才能展开，破坏链式调用的流畅性。thenCompose 内部实现会将返回的 CompletionStage 解包并作为外层 Future 的结果。

③ 多角度追问

源码：UniCompose 如何实现解包？它和 UniApply 的 tryFire 方法有何不同？
调试：如何通过堆栈信息判断是否存在不必要的嵌套？
设计模式：这种设计与 Optional.flatMap 有何异同？能否归纳出容器类型（Monad）的通用组合模式？

④ 加分回答：Monad 的“join”操作正是消除 M<M<T>> 的关键。thenCompose 结合 thenApply 构成了异步 Monad 的 flatMap 与 map，符合函数式编程的代数结构，使得异步流程可被形式化验证。

题目 4：thenCombine 和 thenCompose 都是组合多个 CompletableFuture，它们的场景区别是什么？

① 一句话回答：thenCompose 用于依赖型异步顺序调用（第一个结果决定第二个），thenCombine 用于独立型异步并行调用（两者无依赖，同时执行，合并结果）。

② 详细解释：thenCompose(fn) 的执行时机依赖于前置阶段的完成，函数 fn 接收前置结果，因此第二个任务必须等待第一个任务完成才能发起。thenCombine 接收的另一个 CompletionStage 是独立的，可以与前置阶段同时执行，当两者都完成时执行合并函数。从延迟角度看，thenCompose 的总时间是 T1 + T2，thenCombine 是 max(T1, T2)。如果两个任务互不依赖，使用 thenCombine 可以显著降低总延迟。

③ 多角度追问

编排优化：如何将三个任务中最优的并行与串行混合编排？
异常影响：thenCombine 中如果其中一个 Future 异常完成，合并函数是否还会执行？
源码：BiApply 如何等待两个依赖完成？它内部使用了什么同步机制？

④ 加分回答：在 DAG（有向无环图）任务调度中，thenCompose 对应串行边，thenCombine 对应并行汇合点。基于 CompletableFuture 构建的编排引擎（如 Netflix Conductor）正是利用这些语义实现工作流的声明式定义。

题目 5：anyOf 和 allOf 分别用于什么场景？allOf 等待全部完成后如何获取每个 Future 的结果？

① 一句话回答：anyOf 用于任一成功即可的竞速场景（如多路缓存查询），allOf 用于全部成功才继续的汇聚场景（如并行服务调用）。allOf 返回 Void，需在后续通过 thenApply(v -> f1.join() + f2.join()) 手动收集结果。

② 详细解释：anyOf(CF... cfs) 返回 CompletableFuture<Object>，只要有一个输入 Future 完成，返回的 Future 就完成（结果类型为 Object）。适用于冗余查询、心跳检测等。未完成的其他任务不会被自动取消，可能造成资源浪费。allOf(CF... cfs) 返回 CompletableFuture<Void>，等待所有输入 Future 完成。由于静态类型限制，无法自动合并结果，需手动调用 join() 或 get() 收集。注意，如果任何一个 Future 异常完成，allOf 返回的 Future 仍会正常完成（不携带异常），这意味着手动 join() 时可能抛出异常，必须做好异常处理。

③ 多角度追问

资源管理：如何安全地取消 anyOf 中未完成的任务？
异常行为：allOf 中若部分失败，如何快速失败而不等待其余？
类型安全：如何封装一个类型安全的 allOf 变体，返回 Tuple3<A,B,C>？

④ 加分回答：在响应式编程中，Mono.zip 实现了类似 allOf 的类型安全版本。JVM 生态中，Vavr 库提供了 Future 的 zip 方法，能在编译期保证结果类型。CompletableFuture 缺乏这种能力，但可以通过组合多个 thenCombine 实现类似效果。

题目 6：exceptionally、handle、whenComplete 三者在异常处理上的语义差异是什么？各自适用于什么场景？

① 一句话回答：exceptionally 仅处理异常并返回降级值，handle 无论成败都能转换结果，whenComplete 执行副作用但不改变结果。

② 详细解释：

exceptionally(Function<Throwable, T> fn)：当前驱异常完成时调用，提供默认值，将异常路径恢复为正常路径。正常路径不触发。
handle(BiFunction<T, Throwable, U> fn)：不论成败都会调用，两个参数互斥（一个非 null，另一个为 null）。返回值作为新的结果，可实现转换或恢复。
whenComplete(BiConsumer<T, Throwable> action)：同样不论成败调用，但不改变向下游传递的结果或异常。常用于日志、指标收集、清理资源等。

③ 多角度追问

链式传播：如果在 handle 中又抛出了异常，后续阶段会如何？
调试：如何跟踪一个 CompletableFuture 链中异常的源头？
最佳实践：在一个复杂的编排链中，异常处理应放在哪个位置？

④ 加分回答：这三个方法分别对应函数式编程中的 recover、mapError 和 tap 操作。在 Reactor 中对应 onErrorReturn、handle、doOnError/doOnSuccess。理解这些抽象后，跨库迁移思维成本极低。

题目 7：CompletableFuture 的异常传播机制是怎样的？链式调用中未捕获的异常会怎样？

① 一句话回答：异常会沿着 CompletionStage 链向下游传播，跳过所有转换/消费节点，直到遇到 exceptionally 或 handle 才会被处理；若传播至末端仍未被处理，调用 get()/join() 时会抛出包装的 ExecutionException/CompletionException。

② 详细解释：当某个阶段抛出异常时，它被捕获并封装在 CompletableFuture 内部（AltResult）。后续的 thenApply、thenAccept 等操作检测到前置结果是异常时，会直接将该异常作为自己的结果传递下去，而不执行用户函数。只有当遇到 exceptionally 或 handle 时，这些专用节点才会提取异常并调用用户代码。如果链中没有安装异常处理器，最终客户端通过 get() 或 join() 消费结果时将收到异常。这种设计允许将异常处理集中在链的末端或特定断点，类似于 try-catch 的作用域。

③ 多角度追问

源码：UniApply.tryFire 中如何判断并传播异常？
性能：异常传播过程中的对象分配如何影响性能？
设计：为什么 allOf 不会将异常传播到返回的 Void Future？

④ 加分回答：异常传播是异步 Monad 的“错误通道”（error channel）的具体实现。相比 Golang 的显式 if err != nil，Java 的选择是通过隐式传播减少模板代码，但需要开发者清楚了解异常处理的安装点，否则可能吞掉关键错误。

题目 8：JDK 9 的 completeOnTimeout 和 orTimeout 有什么区别？它们如何解决异步调用的超时问题？

① 一句话回答：completeOnTimeout 是软超时，超时后用给定值正常完成；orTimeout 是硬超时，超时后异常完成（TimeoutException）。两者均从 JDK 9 开始内置支持。

② 详细解释：completeOnTimeout(T value, long timeout, TimeUnit unit) 设定一个超时，如果原 Future 在该时间内未完成，就用 value 强制正常完成，原任务的结果被忽略。这适合可降级的场景。orTimeout 则直接让 Future 异常完成，触发后续 exceptionally 链，适合“超时即失败”的严格场景。在 JDK 8 中，开发者通常借助 ScheduledExecutorService 模拟，但需要仔细处理线程同步和资源释放。JDK 9 的实现使用了 Delayer 和 Timeout 内部类，与 CompletableFuture 的原有 Completion 栈深度集成。

③ 多角度追问

内部实现：orTimeout 如何与现有 Completion 栈集成？超时触发时如何避免竞态？
迁移：在仍使用 JDK 8 的项目中，如何设计一个向前兼容的超时工具类？
测试：如何高效测试超时逻辑而不依赖真实时钟？

④ 加分回答：Reactor 的 Mono.timeout 提供了更丰富的超时策略（如返回不同的 Publisher）。CompletableFuture 的超时增强使它在简单异步场景下拥有不输响应式库的表达力，降低了小型项目引入 Reactor 的必要性。

题目 9：CompletableFuture 的 complete 和 completeExceptionally 方法的作用是什么？如何将传统的回调 API 包装为 CompletableFuture？

① 一句话回答：complete(T value) 和 completeExceptionally(Throwable ex) 用于手动将 CompletableFuture 置为完成状态，是实现回调 API 到 CompletableFuture 转换的桥梁。

② 详细解释：创建一个空的 CompletableFuture 对象后，将其传递给旧式异步 API 的回调中。在 onSuccess 回调里调用 complete(result)，在 onError 回调里调用 completeExceptionally(ex)。由于 CompletableFuture 的状态只能被设置一次，后续的 complete 调用将被忽略，这保证了结果的最终一致性。典型案例如将 Vert.x 或 Netty 的 Future 适配为 CompletableFuture，从而融入业务编排链。

③ 多角度追问

线程安全：多个线程同时调用 complete 会怎样？
取消传播：如何将 cancel() 信号传播回底层的回调 API（如关闭 HTTP 连接）？
泄漏防范：如果回调永不触发，CompletableFuture 会一直占用内存，如何避免？

④ 加分回答：这种适配器模式在系统集成中极其普遍。Spring 的 ListenableFuture 到 CompletableFuture 的转换就是通过 ListenableFutureCallback + complete 实现的。掌握这一技巧，就能平滑地让陈旧组件融入现代异步体系。

题目 10：CompletableFuture 在 Spring WebFlux 和 Reactor 中扮演什么角色？它与 Mono/Flux 有什么关系？

① 一句话回答：CompletableFuture 是命令式异步与响应式之间的桥梁；在 Spring WebFlux 中，可通过 Mono.fromFuture() 将 CompletableFuture 转为 Mono，进而接入完整的响应式流。

② 详细解释：Reactor 是 Spring WebFlux 的默认响应式库，Mono 和 Flux 支持背压、丰富的操作符和调度器。但许多遗留代码或第三方库仍返回 CompletableFuture。Mono.fromFuture(future) 会等待 Future 完成，将其结果作为 Mono 的元素发出。反之，Mono.toFuture() 将 Mono 转换成 CompletableFuture。在架构演进过程中，CompletableFuture 可作为渐进式响应式改造的中间层：先在边缘服务使用 CompletableFuture 替代阻塞调用，再逐步将核心链路替换为完全的 Mono/Flux 流。

③ 多角度追问

背压：CompletableFuture 不支持背压，当数据生产过快时如何处理？
上下文：响应式上下文（如 Reactor Context）能否传递到 CompletableFuture 的线程中？
性能：Mono.fromFuture 会引入线程切换开销吗？

④ 加分回答：Spring Framework 5 引入了 DeferredResult 和 CompletableFuture 的集成，使 Spring MVC 也能利用异步非阻塞提升吞吐量。尽管 WebFlux 是最终方向，但在大规模遗留系统中，CompletableFuture 往往是更实际的优化切入点。

题目 11（系统设计题）：商品详情页聚合服务设计

需求：商品详情页需要聚合四个独立服务的数据：商品基本信息（50ms，必须成功），库存（30ms，可降级为0），价格（40ms，可降级为0.0），评论（100ms，可降级为空列表）。四个服务无依赖，需并行调用；整体超时 200ms；超时后返回已获取的部分数据。

① 一句话回答：使用 CompletableFuture.supplyAsync 并行发起四个调用，对可降级服务附加 exceptionally，通过 thenCombine 多次合并，最后用 get(timeout, unit) 控制超时。

② 详细解释：

自定义线程池：使用 ThreadPoolExecutor（核心线程 10，最大线程 20）避免阻塞 commonPool。
核心路径：商品 Future 不设置降级，如果失败则整体失败（通过 get 抛异常）。
降级路径：库存、价格、评论均添加 exceptionally(ex -> defaultValue)，确保失败不影响整体。
合并：productFuture.thenCombine(stockFuture, ...).thenCombine(priceFuture, ...).thenCombine(reviewFuture, ...) 逐级组合成最终 DTO。
超时控制：resultFuture.get(200, MILLISECONDS) 包裹在 try-catch 中，捕获 TimeoutException 后返回已获取的部分数据（可结合 resultFuture.isDone() 和已有引用）。

③ 多角度追问

如果商品服务也允许降级，设计应如何调整？
如何实现超时后不放弃未返回的结果，而是在它们到达后异步更新缓存或日志？
如何通过 Micrometer 或 Prometheus 监控每个 Future 的耗时和成功率？

④ 加分回答：更优雅的超时部分返回可通过 CompletableFuture 的反射式 complete 或 JDK 9 的 completeOnTimeout 实现：提前构造一个缺省 DTO，超时后用 completeOnTimeout 强制完成，同时让未就绪的 Future 通过 whenComplete 异步写入缓存，做到“降级不丢数据”。这是构建弹性系统的关键技巧。

架构图：

flowchart LR
    Client["客户端"] --> API["聚合API"]
    API -->|"supplyAsync"| PS["商品服务"]
    API -->|"supplyAsync"| IS["库存服务"]
    API -->|"supplyAsync"| PRS["价格服务"]
    API -->|"supplyAsync"| RS["评论服务"]
    PS -->|"result"| Merge["thenCombine 合并"]
    IS -->|"exceptionally 0"| Merge
    PRS -->|"exceptionally 0.0"| Merge
    RS -->|"exceptionally 空"| Merge
    Merge -->|"get(timeout)"| Client

    classDef default fill:#f1f5f9,stroke:#334155,stroke-width:1.5px,color:#1e293b
    class Client,API,PS,IS,PRS,RS,Merge default1

时序图：

sequenceDiagram
    participant API as 聚合层
    participant PS as 商品服务
    participant IS as 库存服务
    participant PRS as 价格服务
    participant RS as 评论服务

    API->>PS: 获取商品 (50ms)
    API->>IS: 获取库存 (30ms)
    API->>PRS: 获取价格 (40ms)
    API->>RS: 获取评论 (100ms)
    PS-->>API: 商品信息
    IS-->>API: 库存信息 / 降级0
    PRS-->>API: 价格信息 / 降级0.0
    RS-->>API: 评论信息 / 降级空列表
    API->>API: thenCombine 组装DTO
    API-->>API: 超时200ms 则返回部分数据

此设计利用了 CompletableFuture 的并行能力，将原本 220ms（50+30+40+100）的顺序调用压缩至 max(50,30,40,100) ≈ 100ms，结合超时策略，确保即使评论服务慢至 150ms 仍能在 200ms 内成功返回数据，实现了延迟与可用性的平衡。

系列结语：五篇文章从 Lambda 的“函数作为值”，到 Stream 的“声明式数据管道”，再经 Collector 的“灵活归约”、Optional 的“安全空值”，最终抵达 CompletableFuture 的“时间性值容器”。这一旅程不只是在学习 API，更是在构建一种看待计算的新视角——将控制流抽象为数据流，将回调地狱转化为声明式编排。当你下次面对复杂的异步逻辑时，不妨问自己：“这能不能变成一个 CompletableFuture 的链？”——答案往往是肯定的。