面试考察点
- 是否区分
thenApply、thenCompose和thenCombine。 - 能否处理异常、超时和取消。
- 是否关注默认公共线程池带来的资源干扰。
核心答案
CompletableFuture 用阶段组成异步数据流：
thenApply转换结果，thenCompose串联返回 Future 的依赖任务，thenCombine合并两个独立结果。生产环境应传入隔离的线程池，并为外部调用设置超时和降级。
不带 Async 的后续阶段可能由完成前一阶段的线程执行；带 Async 的版本会提交到指定执行器，二者影响线程上下文和调度开销。
异常处理
exceptionally 用于异常恢复，handle 同时处理成功与失败，whenComplete 适合观察结果但通常不改变它。最终 join() 会把异常包装为非受检的 CompletionException，get() 则声明受检异常。
常用编排语义
| API | 输入与输出 | 适用关系 |
|---|---|---|
thenApply |
T -> U | 同步转换已有结果 |
thenCompose |
T -> Future | 串联依赖的异步调用，避免 Future 嵌套 |
thenCombine |
Future |
两个独立任务完成后合并 |
allOf |
多个 Future -> Future |
等待一批任务全部结束 |
anyOf |
多个 Future -> Future | 取最先完成结果，需处理取消其余任务 |
理解数据依赖比背 API 更重要。A 的结果是 B 的输入时使用 compose；A、B 可以同时开始且最终需要合并时使用 combine；把两者写成串行 thenApply 会无谓增加总延迟。
一个聚合接口示例
CompletableFuture<User> user = supplyAsync(() -> userClient.get(userId), ioPool);
CompletableFuture<List<Order>> orders = supplyAsync(() -> orderClient.list(userId), ioPool);
CompletableFuture<Profile> profile = user.thenCombine(orders,
(u, os) -> new Profile(u, os));
Profile result = profile.orTimeout(300, TimeUnit.MILLISECONDS)
.exceptionally(error -> Profile.degraded(userId))
.join();
这里的降级应只覆盖可接受的依赖失败；如果用户身份是授权前提，就不能返回一个伪造成功的 Profile。超时也不代表远程调用一定停止，客户端、服务端和资源池仍需有自己的超时与取消策略。
执行器隔离
不指定 executor 的 supplyAsync 通常使用 commonPool。把阻塞 HTTP、数据库、文件 I/O 放入 commonPool，可能与其他库任务相互干扰。应根据任务性质划分：CPU 密集池大小接近可用核心数，I/O 池按下游连接、等待时间和背压策略估算，并使用有界队列和拒绝策略。
后续阶段不带 Async 时，会在完成前一阶段的线程执行。这有助于减少切换，但若回调中做长耗时操作，会占住 I/O 回调或线程池工作线程。长任务应显式切换到合适的 executor。
超时、取消与资源泄漏
orTimeout 让 Future 以异常结束，completeOnTimeout 提供默认结果，但两者不会神奇地取消已经发出的网络请求。调用库应支持请求级超时，任务内部应响应中断或取消，连接池要能归还连接。否则表面超时后，后台仍堆积慢调用。
避免线程池饥饿
最危险的写法是在同一个有限线程池任务中调用另一个同池任务的 join。当所有线程都等待尚未调度的子任务时，系统形成饥饿死锁。用组合 API 让依赖以回调形式衔接，或将阻塞任务隔离到不同池。
实践边界
并行调用前先确认下游容量，不能把串行循环机械改成大量异步任务。对 CPU 和阻塞 I/O 使用不同执行器，设置队列、超时和监控；取消 Future 也未必能中止已发出的远程请求。
常见误区
在同一个小线程池的任务中阻塞等待依赖任务，可能造成线程饥饿死锁。异步也不会让单个任务更快，它优化的是等待期间的线程利用率和独立任务并行度。
高频追问与参考回答
追问：allOf 为什么拿不到结果列表？
allOf 只表示一组任务全部完成，完成后需要从原 Future 列表逐个读取结果，并统一处理其中任一任务失败的策略。
追问：thenApply 和 thenCompose 最常见的区别是什么？
回调返回普通值用 thenApply；回调返回另一个 CompletableFuture 用 thenCompose 来扁平化。前者误用会得到 CompletableFuture<CompletableFuture<T>>。
追问：exceptionally 能处理取消吗？
取消会使 Future 以 CancellationException 结束，通常可被异常处理阶段观察到。但业务是否应降级、传播取消或补偿，要根据调用语义决定。
追问：如何保留 traceId？
不要假定 ThreadLocal 自动跨异步阶段传播。可显式传递上下文、使用框架提供的任务装饰器，或在每个阶段创建带上下文的日志作用域。
总结
异步编排的关键不是链式语法，而是依赖关系、执行器隔离、超时、异常和下游容量控制。
机制全景图
下面把「CompletableFuture 如何实现异步任务编排？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["提交异步阶段"]
A --> B["在线程池执行任务"]
B --> C["组合依赖与汇聚"]
C --> D["传播结果或异常"]
D --> E["设置超时并释放资源"]
完整链路：从输入到结果
沿着「提交异步阶段 → 在线程池执行任务 → 组合依赖与汇聚 → 传播结果或异常 → 设置超时并释放资源」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 提交异步阶段
supplyAsync/runAsync 决定初始阶段与执行器，默认 commonPool 不适合混入不可控阻塞 I/O。
2. 在线程池执行任务
每个阶段在指定或继承的执行器中运行，thenApply 与 thenApplyAsync 的调度语义不同。
3. 组合依赖与汇聚
thenCompose 适合有依赖的异步扁平化，thenCombine/allOf 适合并行汇聚；错误并行会放大下游压力。
4. 传播结果或异常
异常会沿链传播直到 exceptionally、handle 或 whenComplete；join 会包装为 CompletionException。
5. 设置超时并释放资源
orTimeout 只改变 Future 结果，不一定取消底层 I/O，必须配合客户端超时、取消信号和资源隔离。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| CompletableFuture#uniApply/uniCompose | 阶段完成与依赖触发 |
| ForkJoinPool.commonPool | 默认异步执行器及阻塞风险 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
try (var pool = Executors.newFixedThreadPool(32)) {
return CompletableFuture.supplyAsync(client::load, pool)
.orTimeout(300, MILLISECONDS);
}
注入一个 2s 下游，验证 Future 超时后底层连接是否仍占用；记录各阶段线程名、队列和取消结果。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「阶段 P99」为主基线，记录值应满足「各自受子预算约束」；同时保存 各阶段耗时、执行器队列长度，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「CompletableFuture#uniApply/uniCompose」确认请求确实进入「阶段完成与依赖触发」对应的实现，再沿「ForkJoinPool.commonPool」观察「默认异步执行器及阻塞风险」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「默认 commonPool 被阻塞任务占满」，并把单一变量逐级放大，直到「阶段 P99」越过「总和超过入口」。随后再分别验证「只设置 Future 超时却未终止底层调用」和「异常处理过早转换为 null 掩盖失败」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「独立有界执行器」，确认它能控制影响范围；第二轮应用「客户端超时与 Future 超时同时设置」，验证核心链路恢复；最后落实「异常保留根因而非转 null」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「阶段 P99」回到「各自受子预算约束」、「超时后存活任务」回到「目标 0 或有界」、「执行器队列」回到「稳态低水位」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| 阶段 P99 | 各自受子预算约束 | 总和超过入口 | 预算失配 |
| 超时后存活任务 | 目标 0 或有界 | 持续增加 | 底层未取消 |
| 执行器队列 | 稳态低水位 | 单调增长 | 异步积压 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：聚合接口超时后数据库仍被持续访问
接口对 CompletableFuture 设置 300ms 超时后返回，但 JDBC 查询不可中断，后台任务继续占用连接，流量高峰时连接池耗尽。修复同时设置数据库查询超时、独立有界执行器和并发许可，并对取消无效的任务做观测。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 默认 commonPool 被阻塞任务占满 | 各阶段耗时 | 独立有界执行器 |
| 只设置 Future 超时却未终止底层调用 | 执行器队列长度 | 客户端超时与 Future 超时同时设置 |
| 异常处理过早转换为 null 掩盖失败 | 超时后存活任务数 | 异常保留根因而非转 null |
发布与回滚检查点
- 发布前：确认「CompletableFuture#uniApply/uniCompose」对应实现和上述配置在目标版本仍然有效，并保存「阶段 P99」基线。
- 灰度中：同时观察 各阶段耗时、执行器队列长度、超时后存活任务数；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「独立有界执行器」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「默认 commonPool 被阻塞任务占满」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 同步调用 | 依赖少且延迟预算充足 | 控制流直观、异常清晰 | 串行累加等待时间 |
| CompletableFuture | 多个独立 I/O 可并行且需组合 | 编排表达力强 | 执行器、异常和取消复杂 |
| 响应式流 | 长链路流式数据与背压 | 端到端非阻塞和流控 | 学习与调试成本高 |
选型至少带上 并发线程数、临界区长度、阻塞比例和任务到达速率，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
异步化不会缩短单个依赖本身的耗时，只能重叠独立等待；下游容量、超时和取消必须与编排一起设计。
工程落地遵循：先建立 happens-before 与所有权边界，再谈吞吐和无锁优化。回答时直接引用「CompletableFuture#uniApply/uniCompose」、配置实验和事故数据，比复述固定模板更有说服力。