java线程池结合completablefuture异步异常兜底，核心是每个supplyasync后紧跟ortimeout+exceptionally提供业务语义明确的降级值，确保单任务失败不中断汇聚流程，且所有future必须稳态完成（normal）后才能allof.join。
Java 线程池结合 CompletableFuture 处理异步异常兜底，核心是不让单个任务失败中断整个流程，同时保证降级结果可参与后续汇聚或返回。关键不在“捕获异常”，而在“主动设计失败路径”——每个异步任务都自带 fallback，且不依赖全局统一 handler。
每个 supplyAsync 后紧跟 exceptionally 提供降级值
exceptionally 是最直接的单任务兜底方式，它接收 Throwable，返回一个替代结果（类型需与原始 Future 一致），确保该 future 仍能正常完成、可 join、可参与 allOf 汇聚：
- 必须用 exceptionally，不用 handle 或 whenComplete —— 后两者不改变 future 的完成状态，若原任务异常，future 仍是 EXCEPTIONAL 状态，调用 join 仍会抛出 CompletionException
- 降级值应业务语义明确：查用户失败 → 返回空 User；查库存失败 → 返回默认库存量 0；远程调用超时 → 返回缓存快照
- 示例：CompletableFuture.supplyAsync(() -> api.fetchOrder(), pool)
.orTimeout(2, SECONDS)
.exceptionally(ex -> Order.empty())
用 orTimeout 主动切断卡死任务
阻塞型异常（如数据库连接挂起、RPC 长轮询）不会触发 exceptionally，必须靠超时机制提前终止：
- orTimeout 应紧接在 supplyAsync 之后，避免后续 thenXXX 链路干扰超时判断
- 超时单位建议用 SECONDS，避免纳秒级精度导致误判；时间阈值按 P95 延迟设定，而非平均值
- 注意：orTimeout 触发后，底层线程可能仍在执行（未中断），需确保任务本身支持中断或具备幂等性
allOf 汇聚前确保每个 future 都已“稳态完成”
allOf 本身不处理异常，它只等待全部 future 进入完成态（NORMAL 或 EXCEPTIONAL）。如果某个 future 未加 exceptionally，它一旦异常，allOf.join() 就会抛出异常，整批汇聚失败：
- 正确做法：先对每个 future 调用 exceptionally（或 orTimeout + exceptionally 组合），再 collect 到 List 中
- 验证方式：遍历 futures 列表，逐个调用 isDone() && !isCompletedExceptionally() —— 若为 true，说明已稳态完成，可安全 join
- 不推荐用 allOf(futures).exceptionally(...) 做整体兜底 —— 它无法修复单个失败项，只能掩盖问题
避免 commonPool 导致异常兜底失效
如果没传自定义线程池，exceptionally 回调可能在 ForkJoinPool.commonPool 中执行。而该池一旦被其他模块占满（如 parallelStream），exceptionally 本身就会延迟甚至饿死：
- 所有 supplyAsync、thenApplyAsync、甚至 exceptionally 内部的逻辑，只要涉及异步执行，都应显式传入同一业务线程池
- 尤其注意 thenCompose/thenCombine 的异步重载方法，它们也有 Executor 参数，漏传就会回退到 commonPool
- 线程池拒绝策略建议用 CallerRunsPolicy：当队列满时由提交线程执行 fallback，确保兜底逻辑不被丢弃
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
