CompletableFuture 是 Java 8 确立的异步编程标准范式，强调声明式编排、显式线程归属与统一异常处理；须用 thenApply/thenCompose/thenApplyAsync 链式编排，按 IO/CPU 类型隔离线程池，异常必须用 exceptionally 或 handle 兜底，对外结果必须设超时。
CompletableFuture 是 Java 8 引入后逐步确立现代异步编程事实标准的核心组件，它不是“可选工具”，而是规范异步流程设计、线程资源管理与错误响应机制的统一范式。它的规范性体现在三方面：声明式编排代替手动回调、显式线程归属代替隐式共享、统一异常语义代替静默失败。
用链式阶段替代嵌套回调
传统 Future 需要轮询或阻塞等待，容易写出“回调地狱”；CompletableFuture 要求所有后续逻辑通过 thenApply、thenCompose、thenAccept 等 CompletionStage 方法注册，形成清晰的执行流水线。
- 有返回值的同步转换用 thenApply（同线程执行，轻量）
- 需开启新异步阶段时用 thenApplyAsync（指定线程池，避免阻塞前序线程）
- 下一个任务依赖上一个结果且本身也是 CompletableFuture 时，必须用 thenCompose，而非 thenApply + .join() —— 后者会引发线程阻塞和潜在死锁
线程池必须显式指定，禁止依赖 commonPool
默认的 ForkJoinPool.commonPool() 是全局共享资源，IO 类任务一旦耗尽其线程，就会拖垮整个应用的并行能力（如定时任务、日志刷盘等）。规范做法是按任务类型划分线程池：
- IO 密集型（DB 查询、HTTP 调用）：用 cachedThreadPool 或固定大小（如 50~100）的 fixedThreadPool
- CPU 密集型（数据聚合、加解密）：线程数 ≈ Runtime.getRuntime().availableProcessors()
- 混合型场景：至少隔离出 IO 池和 CPU 池，调用时明确传入，例如 supplyAsync(() → queryDB(), ioPool)
异常处理不可省略，且需统一兜底策略
CompletableFuture 的异常不会自动抛出到主线程，不处理就会静默丢失。规范要求每个异步链终点必须覆盖失败路径：
立即学习“Java免费学习笔记（深入）”；
- exceptionally(Function<Throwable, T>)：提供降级值，适合可容忍失败的场景（如缓存未命中时返回默认值）
- handle(BiFunction<T, Throwable, R>)：同时接收结果与异常，适合需要记录日志+返回统一格式的场景
- 禁止只写 whenComplete（不改变结果）、也禁止漏掉任何分支——尤其在 thenCombine、allOf 等组合操作后
结果获取必须带超时，禁用无保护的 join/get
在服务间调用或网关层，不设超时的 join() 或 get() 是系统雪崩的常见诱因。规范写法是：
- 链内流转用 join()（无超时，但仅限内部阶段衔接）
- 对外暴露结果时，必须用 orTimeout(long, TimeUnit) + exceptionally 设置熔断阈值
- 若需兼容老接口，用 get(3, SECONDS) 并捕获 TimeoutException 和 ExecutionException
