CompletableFuture超时核心是声明式控制完成时机：JDK9起用orTimeout()抛TimeoutException（需exceptionally兜底）或completeOnTimeout()设默认值，须配自定义线程池防commonPool阻塞，多层任务需分层设防。
CompletableFuture 处理超时问题，核心不是“让子线程自己中断自己”，而是通过声明式语义控制任务完成时机，并配合线程协作与兜底逻辑。JDK 8 原生不支持强制中断运行中任务，但自 JDK 9 起提供了 orTimeout() 和 completeOnTimeout() 两个关键方法，它们底层依赖延迟调度器（Delayer）实现非阻塞超时判定，真正做到了“不卡主线程、不占资源、可降级”。
用 orTimeout() 主动抛异常，走异常处理链
当任务超时，orTimeout() 会自动调用 completeExceptionally(new TimeoutException())，把 CompletableFuture 置为异常完成状态。它适合需要明确感知超时、并统一做降级或告警的场景。
- 必须搭配
exceptionally()或handle()使用，否则异常会被静默吞掉 - 超时后原任务仍在后台运行（不会被 cancel），需确保其逻辑是幂等或可安全丢弃的
- 不能替代业务层超时（如 HTTP 客户端自身的 connect/read timeout），应作为兜底防线
用 completeOnTimeout() 返回默认值，避免异常传播
completeOnTimeout(value, timeout, unit) 在超时发生时直接设置成功结果，不抛异常。它更适合“尽力而为”型任务，比如推荐位加载、非核心配置拉取。
- 返回值类型必须和原始 CompletableFuture 的泛型一致，否则编译失败
- 如果任务已提前完成，该方法无效；如果已异常完成，也不会覆盖结果
- 常和
orTimeout()组合使用：先设兜底值，再补异常处理，双重保险
超时 + 自定义线程池，防止阻塞公共池
超时控制失效的常见原因，是任务在 ForkJoinPool.commonPool() 中执行了阻塞操作（如数据库查询、无超时的 I/O）。一旦线程被占满，延迟任务调度器（Delayer）也无法触发超时逻辑。
立即学习“Java免费学习笔记（深入）”；
- 所有
supplyAsync、thenApplyAsync等异步方法，务必显式传入自定义线程池 - 线程池建议用
ThreadPoolExecutor，而非Executors工厂类（避免无界队列风险） - 对含 I/O 的任务，线程数宜设为 CPU 核心数 × 2 ~ 4；纯计算任务可接近核心数
组合多个超时策略，应对复杂依赖链
真实业务中往往不是单个任务超时，而是“A 和 B 并行，都完成后交给 C 处理，整体不能超 2 秒”。这时需分层设防：
- A、B 各自用
orTimeout(1, SECONDS)防止单点拖垮 - 聚合后用
anyOf(A, B).orTimeout(500, MILLISECONDS)控制任意一个快速响应 - 最终结果用
allOf(A, B).thenApply(...).orTimeout(2, SECONDS)约束总耗时 - 所有
orTimeout后紧跟exceptionally，确保每层都有降级出口
