很多 Java 后端候选人遇到 CompletableFuture，第一反应是把几个接口调用改成 supplyAsync，再用 allOf 等结果。这个回答听起来会用 API，但面试继续往下问就会暴露问题：这几个任务跑在哪个线程池？其中一个接口超时，另外几个还要不要等？请求已经取消，后台任务是否还在占用连接？返回部分数据算成功还是失败？
这些追问并不刁钻。真实业务里，异步接口最怕的不是写不出来，而是上线后变成一堆不可控的后台任务。同步接口慢，至少调用链路还清楚；异步编排如果没有边界，问题会散到线程池、下游连接、异常处理和结果合并里，排查难度更高。
异步之前先算清时间预算
一个接口如果总超时时间是 800 毫秒，不能因为拆成三个异步任务，就让每个任务都自由跑 800 毫秒。更合理的设计是先分配预算：主流程需要多少时间，缓存读取、外部接口、数据库查询各自最多占多少时间，超过后是失败、降级还是返回缺省值。
面试里可以把这点讲得很具体：异步任务不是越多越好，而是为了把互不依赖的等待时间重叠起来。能并行的前提是这些任务之间没有强顺序依赖；如果后一个任务依赖前一个结果，硬拆异步只会增加复杂度。
线程池是工程边界，不只是参数
CompletableFuture 如果不显式传 Executor，容易使用公共线程池。对于简单计算这不一定出问题，但在后端服务里，异步任务常常包含网络调用、数据库访问或文件读写。把这类阻塞任务混进公共池，可能影响同进程里其他依赖公共池的逻辑。
更稳的表达是：我会按任务类型和重要程度拆线程池，核心链路、非核心补充信息、批量后台任务不要混在一起。线程池也不能只配 coreSize 和 queueSize，还要有队列等待时间、执行耗时、拒绝次数和活跃线程数监控。否则异步只是把慢请求藏到了队列里。
allOf 只解决等待，不解决业务语义
allOf 能告诉你一组 Future 是否完成，但它不会替你定义“完成以后怎么办”。如果某个分支异常，整组聚合可能以异常结束；如果你在每个分支里吃掉异常，又可能把真实问题静默成空结果。
所以聚合前要先约定语义：哪些数据是页面必须有的，哪些可以降级；哪些异常要中断整个请求，哪些异常只影响局部模块；是否允许部分成功；返回给前端时要不要带降级标记。没有这些规则，异步聚合就会变成一堆 try-catch。
超时不等于任务真的停了
CompletableFuture 的 orTimeout 或 completeOnTimeout 能让 Future 在调用方看来按时结束，但底层任务是否停止，要看任务本身是否响应取消、外部客户端是否设置了超时、线程是否被阻塞在不可中断的位置。很多线上问题就是请求已经返回失败，后台任务还在继续占用连接和线程。
面试时可以强调：超时要分两层。第一层是 Future 层面的等待超时，保护当前请求；第二层是下游调用本身的超时和取消，保护线程池、连接池和对方服务。如果是 HTTP 调用、数据库查询或 RPC 调用，客户端超时必须单独设置。
项目里可以这样讲
假设一个商品详情接口需要同时查价格、库存、推荐和用户权益。我不会简单说“用 CompletableFuture 提升性能”，而会说：价格和库存是强依赖，失败要走明确错误；推荐和权益可以降级，超时后返回基础信息。不同任务使用不同线程池，并设置下游客户端超时。聚合时按模块收集结果和异常，日志里保留请求标识、分支耗时和降级原因。
这样的回答比背 API 更有说服力。因为它说明你知道异步的收益来自并行等待，也知道异步的代价会落在线程池、超时、异常和业务语义上。真正成熟的 CompletableFuture 使用方式，不是把代码写得更花，而是让每一个异步分支都有边界、证据和退路。