completablefuture 提供 ortimeout（超时抛异常）和 completeontimeout（超时返回默认值）两种优雅超时机制，需搭配自定义线程池使用，禁用 get(timeout) 阻塞调用。
CompletableFuture 本身不支持强制中断正在运行的子线程，但提供了两种原生、非侵入式的超时处理方式：一种是超时抛异常（orTimeout），另一种是超时返回默认值（completeOnTimeout）。它们都作用于 CompletableFuture 的生命周期，无需手动管理线程或轮询中断标志，真正实现“优雅”——即语义清晰、链路可控、降级明确。
用 orTimeout 实现超时异常 + 降级兜底
当任务在指定时间内未完成，orTimeout 会主动将 CompletableFuture 置为异常完成状态，并抛出 TimeoutException。它天然适配 exceptionally 或 handle 方法做统一错误处理。
- 调用方式简洁：
.orTimeout(1, TimeUnit.SECONDS) - 异常可被
exceptionally()捕获并返回默认值，不影响后续链式调用 - 适合对结果强依赖、但允许降级的场景（如查缓存失败后查 DB）
- 注意：它不会终止底层线程执行，仅改变 Future 状态；若任务仍继续运行，需确保其具备资源清理或幂等性
用 completeOnTimeout 实现静默兜底
completeOnTimeout 在超时后直接以你指定的默认值完成 Future，不抛异常、不中断流程，更轻量，更适合“尽力而为”类逻辑。
- 调用示例：
.completeOnTimeout("fallback", 800, TimeUnit.MILLISECONDS) - 返回值与主任务类型一致，可无缝接入 thenApply / thenCombine 等转换操作
- 避免异常传播开销，适用于高吞吐、低延迟敏感的服务（如风控特征实时计算）
- 与 orTimeout 可组合使用：先设 completeOnTimeout 提供默认值，再用 orTimeout 防止默认值也迟迟不生效（极端兜底）
必须搭配自定义线程池使用
默认的 ForkJoinPool.commonPool() 是共享资源，一旦某个超时任务长期卡住，会拖慢其他业务线程。所有 supplyAsync / thenApplyAsync 调用都应显式传入专用线程池。
- IO 密集型任务（如 HTTP 调用）：用
newFixedThreadPool(n)，n 根据并发量和远程服务 SLA 设定 - 避免用 cachedThreadPool，防止突发流量导致线程数无限增长
- 线程名建议带业务标识（如
"order-api-pool-1"），便于问题定位
慎用 get(timeout) —— 它不是异步超时，而是主线程阻塞等待
future.get(1, TimeUnit.SECONDS) 是同步阻塞调用，会挂起当前线程直到结果就绪或超时。它不控制子任务本身，只控制“获取结果”的等待时间，违背了异步编程初衷。
- 在 Web 请求线程（如 Tomcat worker）中调用，会导致线程被占满，吞吐骤降
- 无法与 thenCompose、allOf 等组合 API 自然衔接
- 仅适合单元测试或极简脚本场景，生产代码应完全规避
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
