CompletableFuture面试总在异常处理上翻车？5个扣分点把执行链讲清

先给结论：先判断阶段状态，再选异常处理方法

1. 把 thenApply 和 thenCompose 说成一回事

CompletableFuture<User> userFuture = loadUser();

// 结果是 CompletableFuture<CompletableFuture<List<Order>>>，通常不是你想要的
CompletableFuture<CompletableFuture<List<Order>>> wrong =
    userFuture.thenApply(user -> loadOrders(user.id()));

// 把下一个异步阶段接平，结果是 CompletableFuture<List<Order>>
CompletableFuture<List<Order>> right =
    userFuture.thenCompose(user -> loadOrders(user.id()));

thenApply 是对结果做映射，函数通常返回普通值；thenCompose 是连接两个异步阶段，函数返回另一个 Future。只要下一步本身是异步调用，我会优先考虑 thenCompose，避免把 Future 套在 Future 里面。

2. 用 exceptionally 做日志，却没说清它会恢复结果

CompletableFuture<List<Order>> orders = loadOrders(userId)
    .exceptionally(ex -> {
        log.warn("load orders failed, userId={}", userId, ex);
        return List.of(); // 后续拿到的是空列表，异常已被替代
    });

我不会默认把所有异常都降级成空结果。对可接受的超时或依赖不可用，可以返回明确的降级对象；对数据一致性或权限类异常，则继续抛出，交给上层统一处理，并通过日志和指标区分真实空结果与降级结果。

.exceptionally(ex -> {
    Throwable cause = ex instanceof CompletionException
        ? ex.getCause() : ex;
    if (cause instanceof TimeoutException) {
        return cachedOrders();
    }
    throw new CompletionException(cause);
});

3. 把 handle、whenComplete 都说成「finally」

• handle 会拿到 (result, exception)，并计算一个新的结果，适合「无论成功失败，都转换成统一返回对象」。
• whenComplete 会拿到 (result, exception) 做观察动作，返回阶段默认保留原来的结果或异常，适合日志、指标、清理。

// 统一成业务结果：需要 handle
CompletableFuture<CallResult> response = callRemote()
    .handle((value, ex) -> {
        if (ex == null) {
            return CallResult.success(value);
        }
        return CallResult.failed("依赖服务异常");
    });

// 只做观测：需要 whenComplete
CompletableFuture<Response> observed = callRemote()
    .whenComplete((value, ex) -> {
        metrics.record("remote.call", ex == null ? "success" : "failure");
    });

4. 只会说「会抛异常」，却分不清 join() 和 get()

1. join() 在阶段异常完成时抛出未检查的 CompletionException，底层异常在 cause 中。
2. get() 在阶段异常完成时抛出 ExecutionException；带超时的版本还涉及超时异常，调用线程中断也需要按 checked exception 处理。

try {
    List<Order> orders = ordersFuture.join();
} catch (CompletionException ex) {
    Throwable cause = ex.getCause();
    // 根据 cause 做分类处理
}

在已经处于异步流水线、并且方法签名不希望继续暴露 checked exception 时，我可能使用 join()，但会在边界统一解包和分类；如果需要超时控制、响应式处理或显式处理中断，就不能只图代码短，应该选择合适的 get(timeout, unit) 或继续保持异步链。

5. 忽略 Async 的执行器，导致回答停留在 API 层

• 不带 Async 的依赖动作，可能由完成当前阶段的线程执行，也可能由调用完成方法的线程执行。
• 不带显式 Executor 的 xxxAsync 方法，默认使用 ForkJoinPool.commonPool()；如果 common pool 的并行度不足 2，文档规定会改为为每个任务创建新线程。
• 需要隔离阻塞 IO、控制并发度或避免公共线程池互相影响时，应显式传入合适的执行器，并结合队列、超时、拒绝和监控做容量设计。

ExecutorService ioPool = Executors.newFixedThreadPool(32);

CompletableFuture<Response> response =
    CompletableFuture.supplyAsync(() -> callBlockingService(), ioPool)
        .thenApplyAsync(this::toResponse, cpuPool);

1. 这一步是 CPU 计算还是阻塞 IO？
2. 预期并发、超时和任务大小是什么？
3. 线程池满了之后如何限流、降级、告警和验证？

加分追问：allOf 等完了，结果在哪里？

CompletableFuture<Void> all = CompletableFuture.allOf(f1, f2, f3);

List<Result> results = all.thenApply(v -> List.of(
    f1.join(), f2.join(), f3.join()
)).join();

一段可直接练习的完整回答

CompletableFuture 的异常处理，我会先区分结果转换、异步阶段串联和异常恢复。thenApply 处理普通结果映射，thenCompose 连接下一个异步阶段；如果要给失败提供替代值，用 exceptionally，如果成功失败都要转成统一业务结果，用 handle，只做日志和指标则用 whenComplete。最终取结果时，我会区分 join 的 CompletionException 和 get 的 ExecutionException，并在边界解包原始异常。涉及 Async 方法时，再说明默认执行器和阻塞 IO 的隔离，避免只谈 API 不谈容量与故障处理。

面试前 10 分钟自查清单

• 能否用一句话区分 thenApply 与 thenCompose，并写出返回类型差异？
• 能否说明 exceptionally 是替代结果，而不只是记录日志？
• 能否举例说明什么时候用 handle，什么时候用 whenComplete？
• 能否说清 join() 的 CompletionException 与 get() 的 ExecutionException？
• 能否解释不带 Async 与带 Async 的执行线程差异？
• 能否解释 allOf 为什么返回 Void，以及如何读取各 Future 的结果？
• 能否把一个异常处理选择绑定到真实业务：超时、降级、重试、数据一致性或告警？