Java CompletableFuture exceptionallyCompose 怎么串联异步恢复：异常类型、超时与回退验收

调用主服务失败后，如果备用服务本身也要异步访问，CompletableFuture.exceptionallyCompose 比在异常回调里手动套一层 Future 更清楚：它接收异常并返回一个新的异步阶段，把回退结果重新接回原链路。主请求成功时不会执行回退；主请求失败时，回退成功或再次失败都会成为最终结果。

先用一个最小链路看懂异常恢复

下面的例子把主服务和备用服务都写成异步方法。主服务失败后，exceptionallyCompose 返回备用服务的 Future；调用方只需要在最后统一处理结果。

import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CompletionException;

public class FallbackDemo {
    static CompletableFuture primary() {
        return CompletableFuture.failedFuture(
                new IllegalStateException("primary unavailable"));
    }

    static CompletableFuture fallback() {
        return CompletableFuture.supplyAsync(() -> "cached-result");
    }

    public static void main(String[] args) {
        CompletableFuture result = primary()
                .exceptionallyCompose(error -> {
                    System.out.println("主服务失败: " + error.getClass().getSimpleName());
                    return fallback();
                });

        result.whenComplete((value, error) -> {
            if (error != null) {
                System.out.println("最终失败: " + unwrap(error));
            } else {
                System.out.println("最终结果: " + value);
            }
        });
    }

    static Throwable unwrap(Throwable error) {
        return error instanceof CompletionException && error.getCause() != null
                ? error.getCause() : error;
    }
}

这里的关键不是打印日志，而是返回类型：回退方法返回 CompletableFuture，所以它能参与后续的 whenComplete、超时和最终验收。

为什么不能只把 exceptionally 当成异步回退

exceptionally 的函数返回的是一个普通值。如果备用调用也是异步的，直接写成下面这样，得到的类型会变成嵌套 Future：

CompletableFuture> wrong = primary()
        .exceptionally(error -> fallback());

这不仅让调用者多拆一层，还容易让外层 Future 已经“成功”，内层回退其实仍然失败。exceptionallyCompose 做的事情类似异步版的扁平化：回调返回的阶段会被组合进当前链路。

先分清哪些异常允许进入回退

把所有异常都送进备用服务，通常会把配置错误、参数错误和依赖故障一起放大。更稳妥的做法是先拆出根因，再决定是否回退：

static CompletableFuture load(String key) {
    return primaryLoad(key)
            .exceptionallyCompose(error -> {
                Throwable cause = unwrap(error);
                if (cause instanceof IllegalArgumentException) {
                    return CompletableFuture.failedFuture(cause);
                }
                if (cause instanceof java.util.concurrent.TimeoutException
                        || cause instanceof java.io.IOException) {
                    return fallbackLoad(key);
                }
                return CompletableFuture.failedFuture(cause);
            });
}

参数不合法时回退没有意义，可能还会掩盖调用方的 bug。超时或读取依赖失败才更像暂时性故障，但仍要记录原始异常类型、业务键和回退结果，方便确认降级是否真的生效。

把超时放在主调用和回退调用的边界上

orTimeout 会在阶段没有及时完成时，以 TimeoutException 异常完成它；这和 completeOnTimeout 直接填入一个默认值不同。需要执行异步回退时，前者更适合接到 exceptionallyCompose：

static CompletableFuture loadWithFallback(String key) {
    return primaryLoad(key)
            .orTimeout(300, java.util.concurrent.TimeUnit.MILLISECONDS)
            .exceptionallyCompose(error -> {
                Throwable cause = unwrap(error);
                return cause instanceof java.util.concurrent.TimeoutException
                        ? fallbackLoad(key).orTimeout(
                                150, java.util.concurrent.TimeUnit.MILLISECONDS)
                        : CompletableFuture.failedFuture(cause);
            });
}

这里有两个独立时限：主服务最多等待 300 毫秒，备用服务最多等待 150 毫秒。只写一个总超时并不能保证回退及时结束，备用服务可能在主链路已经超时后继续占用线程和连接。

回退再次失败时保留哪一层错误

回退失败不是成功结果，也不应该只抛出一句“服务不可用”。建议在日志或返回对象中同时保留主异常和回退异常，至少带上请求键、耗时、两条依赖名和最终状态。

loadWithFallback("user-42").whenComplete((value, error) -> {
    if (error != null) {
        Throwable finalCause = unwrap(error);
        audit("fallback_failed", finalCause.getClass().getName());
        alertIfNeeded(finalCause);
        return;
    }
    audit("fallback_or_primary_ok", value);
});

如果业务必须给用户一个可用答案，可以在更外层把“主成功、回退成功、最终失败”建模成不同状态，而不是把回退数据标成主数据。这样缓存命中、降级展示和真正的故障不会混成一个绿色成功指标。

用三组测试验收恢复链

测试不要只覆盖主服务失败后拿到默认值。至少需要验证主服务成功不会触发回退、主服务超时会触发回退、回退再次失败会把错误传到末端：

1. 主服务立即成功：断言回退调用次数为 0，最终值来自主服务。
2. 主服务以 TimeoutException 结束：断言回退只调用一次，并验证回退值和降级状态。
3. 主服务失败且回退失败：断言最终 Future 异常完成，日志同时带有主链路和回退链路信息。

测试异步链时，最好为每个依赖注入可控的 Executor 或手动完成的 Future，避免依赖真实网络和不稳定的公共线程池。还要检查超时后的原始任务是否仍可能运行；orTimeout 改变的是 Future 的完成状态，不等于自动中断底层 I/O。

相关问题：三个常见混淆点

exceptionallyCompose 会自动重试主请求吗？

不会。exceptionallyCompose 只在当前阶段异常完成时调用恢复函数，是否重试、重试几次和退避间隔都需要由业务代码明确设计。

异常回调里返回 null 可以吗？

异步组合回调应该返回一个非空的 CompletionStage。需要失败时，用 CompletableFuture.failedFuture 明确传递异常，比返回 null 让链路在更远处触发空指针更容易排查。

orTimeout 会取消远端请求吗？

它首先改变当前 Future 的完成状态，不能据此断言远端请求已经停止。真正需要取消连接、释放信号量或停止任务时，还要让底层客户端支持取消并在 finally 中清理资源。

复查清单

• 异步回退是否使用 exceptionallyCompose，而不是制造嵌套 Future？
• 是否按异常类型决定回退，避免把参数错误也送到备用服务？
• 主调用和回退调用是否分别有可解释的超时？
• 回退失败是否仍以失败状态结束，并保留两段链路的诊断信息？