CompletableFuture本身不执行任务，只负责编排，真正执行依赖线程池；关键在于理清线程归属、结果流转与异常兜底：带Async后缀方法才换线程，需显式指定专用线程池（禁用commonPool），按语义选用thenApply/thenCompose/thenCombine三类编排模式，并通过exceptionally、orTimeout等机制保障容错与超时控制。
CompletableFuture 本身不执行任务，它只负责编排；真正干活的是线程池。要构建可靠的异步变量编排工作流，关键不是堆方法，而是理清“谁在哪个线程里执行”“结果怎么流转”“失败如何兜底”这三件事。
明确线程归属：带 Async 后缀的方法才换线程
CompletableFuture 的方法分两类：
-
不带 Async（如
thenApply、thenAccept、whenComplete）：默认在前一个阶段完成的线程中执行，可能串行阻塞，不适合耗时逻辑 -
带 Async（如
thenApplyAsync、thenAcceptAsync、whenCompleteAsync）：必须指定线程池（推荐自定义），才能真正实现异步解耦
例如：从用户 ID 查用户 → 查其订单 → 汇总统计，若中间某步含数据库查询或 HTTP 调用，必须用 thenComposeAsync(..., ioPool)，否则整个链卡在同一个线程上，失去并发意义。
按业务语义选编排模式：不是所有 then 都一样
三种核心模式对应三类变量依赖关系：
-
单值链式转换（thenApply/thenApplyAsync）：适合纯内存计算，比如
String → JSON → DTO → 加密后字符串，每步只依赖上一步输出，无 I/O -
异步依赖嵌套（thenCompose/thenComposeAsync）：适合“用 A 结果去触发 B 异步任务”，比如
loadUser(id) → thenCompose(user -> loadOrders(user.getId()))，避免thenApply + get()这种反模式阻塞 -
并行结果聚合（thenCombine/thenCombineAsync）：适合“两个独立异步任务完成后合并”，比如
fetchPrice() 和 fetchStock()并行执行，再thenCombine((p,s) -> new ProductView(p,s))
必须显式传入线程池：别碰 ForkJoinPool.commonPool()
默认线程池是 ForkJoinPool.commonPool()，它的线程数 = CPU 核心数，且被全 JVM 共享。一旦某个业务用了慢 IO（如未设超时的 HTTP 请求），就会拖垮其他所有用到 commonPool 的模块。
正确做法：
- 为不同场景建专用线程池：比如
ioPool（固定大小、带队列、拒绝策略为 CallerRunsPolicy）、cpuPool（大小 ≈ CPU 核心数，用于计算密集型） - 所有
supplyAsync、runAsync、thenXXXAsync都显式传入对应池，例如：CompletableFuture.supplyAsync(() -> api.fetch(), ioPool) - 避免全局共享单个 Executor，防止故障扩散
兜住异常与超时：编排 ≠ 放任不管
真实工作流必须考虑失败路径：
- 用
exceptionally()或handle()捕获阶段异常，返回兜底值或记录日志，避免整条链中断 - 用
orTimeout(duration, unit)设置单个阶段超时（JDK 9+），或用completeOnTimeout()提供超时默认值 - 多个并行任务统一等待时，用
CompletableFuture.allOf(f1, f2, f3).orTimeout(10, TimeUnit.SECONDS)，再join()获取结果，比逐个get()更安全
例如批量备份场景：主任务和汇总日志两个 CompletableFuture，应通过 allOf 统一管控生命周期，并设置合理超时，防止某环节 hang 死整个流程。
不复杂但容易忽略：编排的本质是控制流 + 数据流 + 线程流的协同。把每个 .thenXXX 的执行线程、输入来源、输出去向画出来，工作流就清晰了。
