如何利用 CompletableFuture 的 exceptionallyCompose 实现带异步重试的容错链路

在构建高并发的 Java 服务时，远程调用失败几乎是必然会发生的事情。当某个下游接口超时或返回异常，如果直接在调用线程里做阻塞式重试，很容易把业务线程池打满。CompletableFuture 提供的 exceptionallyCompose 方法，能够在上游任务异常结束时，异步地开启一段新的补偿或重试逻辑，从而把容错动作本身也变成非阻塞的链路节点。

exceptionallyCompose 与 exceptionally 的本质区别

很多人在写异步容错时，习惯用 exceptionally 来捕获异常并返回默认值。但 exceptionally 的函数式参数是 Function<Throwable, T>，它只能同步地给出一个结果对象，无法再发起一个新的异步任务。也就是说，如果你希望在失败后去调用另一个远程服务，或者延迟一段时间再重试，exceptionally 就不够用了。

exceptionallyCompose 的签名是 CompletableFuture<U> exceptionallyCompose(Function<? super Throwable, ? extends CompletionStage<U>> fn)。它的参数在异常发生时，返回一个 CompletionStage，通常是另一个 CompletableFuture。这意味着补偿逻辑可以是异步的、带线程切换的、甚至再次具备异常传播能力。从组合角度看，它相当于把异常分支也纳入了异步编排图。

// exceptionally 只能同步给默认值
CompletableFuture<String> f1 = remoteCall()
    .exceptionally(ex -> "default");

// exceptionallyCompose 可以异步切换数据源
CompletableFuture<String> f2 = remoteCall()
    .exceptionallyCompose(ex -> backupRemoteCall());

基于 exceptionallyCompose 的异步重试实现

要实现带异步重试的容错链路，核心思路是：当主调用异常时，在 exceptionallyCompose 里判断异常类型，若属于可重试异常，则使用不同的线程池或延迟调度发起重试任务；若重试依然失败，可再次用 exceptionallyCompose 嵌套下一层重试，或者最终用 exceptionally 给出降级值。

下面的例子展示了一层异步重试。主调用在 ioPool 中执行，失败后切换到 retryPool 做单次重试，两次都失败则返回缓存值。注意重试本身也是 CompletableFuture，因此不会阻塞最初的业务线程。

ExecutorService ioPool = Executors.newFixedThreadPool(10);
ExecutorService retryPool = Executors.newFixedThreadPool(4);

public CompletableFuture<String> callWithRetry() {
    CompletableFuture<String> main = CompletableFuture.supplyAsync(() -> {
        // 模拟主调用，可能抛异常
        if (Math.random() < 0.5) {
            throw new RuntimeException("main call failed");
        }
        return "ok";
    }, ioPool);

    return main.exceptionallyCompose(ex -> {
        System.out.println("主调用异常，发起异步重试");
        return CompletableFuture.supplyAsync(() -> {
            // 模拟重试调用
            if (Math.random() < 0.5) {
                throw new RuntimeException("retry failed");
            }
            return "ok-from-retry";
        }, retryPool);
    }).exceptionally(ex -> "cached-value");
}

多层重试与超时控制

如果业务要求更健壮，可以用递归或循环方式构造多层重试，每层使用 exceptionallyCompose 衔接。同时必须加上超时，否则某次重试若永远不返回，整条链路就会挂起。Java 9 之后的 orTimeout 或自定义调度都能派上用场。

下面的代码演示了带超时和两次异步重试的模板。每次重试前通过 ScheduledExecutorService 做短暂延迟，避免对故障服务造成瞬时冲击。超时后异常会自然流入下一层 exceptionallyCompose，保证链路始终可控。

ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(2);

public CompletableFuture<String> resilientCall(int attempt) {
    if (attempt > 2) {
        return CompletableFuture.completedFuture("final-fallback");
    }
    CompletableFuture<String> current = CompletableFuture.supplyAsync(() -> {
        if (Math.random() < 0.7) {
            throw new RuntimeException("fail attempt " + attempt);
        }
        return "success";
    }, ioPool).orTimeout(800, java.util.concurrent.TimeUnit.MILLISECONDS);

    return current.exceptionallyCompose(ex -> {
        System.out.println("attempt " + attempt + " 失败，准备异步重试");
        CompletableFuture<String> delay = new CompletableFuture<>();
        scheduler.schedule(() -> delay.complete(null), 300, java.util.concurrent.TimeUnit.MILLISECONDS);
        return delay.thenCompose(v -> resilientCall(attempt + 1));
    });
}

线程池隔离与避坑建议

使用 exceptionallyCompose 时，重试或补偿逻辑务必运行在独立的线程池。若复用主业务池，当下游大面积故障时，重试流量会和正常请求竞争线程，导致系统整体雪崩。通过显式传入 Executor，能把故障域限制在小池子里。

另一个常见误区是忽略异常类型的区分。网络超时、业务校验失败、反序列化异常需要的处理方式完全不同。建议在 exceptionallyCompose 内部先用 instanceof 判断，只对特定异常做重试，其余直接走降级，避免无意义重试放大负载。

小结

exceptionallyCompose 让异常分支拥有了异步编排能力，是构建非阻塞容错链路的利器。配合独立线程池、超时控制与异常分类，可以写出既安全又易于维护的重试逻辑。相比传统的 try-catch 加 sleep，这种方式对系统吞吐更友好，也更符合响应式编程的思维方式。

CompletableFutureexceptionallyCompose异步重试修改时间：2026-08-05 19:42:27