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

今天来聊聊 Ja va 并发编程里一个常见，但又特别容易踩的坑。很多人为了实现异常后的异步重试，会自然想到 exceptionallyCompose 这个名字——听起来确实很合理，对吧？但实话实说，它压根不是标准 Ja va 的 API。无论你用的是 JDK 8、11 还是 21，都找不到这么个方法。那个所谓的 exceptionallyComposeAsync，其实是 .NET for Android 平台对 Ja va API 的非标准绑定，只在 Android 上通过 C# 调用才能用，纯 Ja va 项目里写出来编译都过不了。

那么问题来了：想要在 Ja va 中实现“异常发生后触发异步重试”的容错链路，到底该怎么办？答案很明确——得绕开这个不存在的方法，用原生的组合能力来落地。

先弄明白：exceptionally 到底差在哪

exceptionally 接收的是一个 Function，意思是它只接受你同步返回一个 T 类型的值——字符串也好，对象也罢，哪怕是 null。但它不会接受返回 CompletableFuture 的函数。代码看起来就是这样：

// ❌ 编译失败：类型不匹配
future.exceptionally(ex -> CompletableFuture.supplyAsync(() -> "retry"));

// ✅ 正确：只能返回 String，不能返回 CompletableFuture
future.exceptionally(ex -> "fallback");

看到问题了吗？你没法在异常发生后，直接在 exceptionally 里启一个新异步任务去做重试。如果你真想实现这个效果，必须找到一个替代品——其实就是 handle 加上 thenCompose 的组合。

实战方案：用 handle 捕获异常，自己触发异步重试

在所有 CompletableFuture 的方法里，handle 是唯一一个既能拿到结果、又能拿到异常，同时还能让你返回 CompletableFuture 的入口点。它接收一个 BiFunction，注意这里的返回值 U 可以是一个 CompletableFuture<...>，只要你愿意在内部手动包装一下就行。真正的异步重试，必须由你亲手构造一个新的 CompletableFuture，别指望框架自动帮你“重放”。

典型模式长这样：

CompletableFuture withRetry = CompletableFuture.supplyAsync(() -> {
    if (Math.random() < 0.7) throw new RuntimeException("fail on purpose");
    return "success";
}).handle((result, ex) -> {
    if (ex != null) {
        // 异常时，启动重试（最多 2 次）
        return retryAsync(() -> supplyAsyncWithLogic(), 2);
    }
    return CompletableFuture.completedFuture(result);
}).thenCompose(Function.identity()); // 展开嵌套的 CompletableFuture

这里面的 retryAsync 是你自己实现的工具方法，核心逻辑包含三部分：判断是否达到最大重试次数、捕获每次执行的异常但不抛出、使用 delayedExecutor 或 ScheduledExecutorService 来控制退避间隔。听起来复杂，但实现起来并不难。

一个容易翻车的细节：组合操作后的异常会静默丢失

这里必须提醒大家一点。CompletableFuture.allOf 返回的是一个 CompletableFuture，它不会携带任何子任务的异常信息。即便某个子 future 执行失败了，allOf 本身也不会失败——除非你显式调用 join() 或 get() 去把它撞出来。

同样的情况也发生在 thenCombine 上。只要任何一个入参 future 失败，整个链路的 future 就会进入异常状态。但如果你不在链尾加上 exceptionally 或 handle，异常就悄无声息地滞留在内部，直到你通过 join() 去获取它，且原始堆栈可能已经被包装成了 CompletionException。

所以，在真实的业务链路中，每个可能失败的分支都应该尽早兜底处理：

CompletableFuture task1 = fetchUser();
CompletableFuture task2 = fetchOrder();

CompletableFuture combined = CompletableFuture.allOf(task1, task2);

// ❌ 危险：combined.join() 抛出的异常无法区分是哪个子任务失败

// ✅ 应该分别处理：
task1.exceptionally(ex -> { log.error("user fetch failed", ex); return "default-user"; });
task2.exceptionally(ex -> { log.error("order fetch failed", ex); return "empty-order"; });

总结一下：exceptionallyCompose 这个名字听起来再合理，它也不是 Ja va 的标准 API。所有基于它的设计，都会在编译期直接挂掉。真正的异步重试，必须靠 handle 加手动构造 CompletableFuture 加显式调度控制来落地。而且，每一层组合都必须预设异常的出口，否则错误就会在链路中悄然消失，让你查都查不到。