orTimeout 不会中断正在运行的异步任务，仅返回 TimeoutException 的新 CompletableFuture，原任务继续执行；需配合可中断 Callable、显式 cancel(true) 及响应中断的线程池才能实现真正熔断。
orTimeout 会中断正在运行的异步任务吗？
orTimeout 不会中断底层 Future 的执行，它只在超时后返回一个抛出 TimeoutException 的新 CompletableFuture。原任务仍在后台运行，可能继续占用线程、资源或产生副作用。
这意味着：如果你依赖「超时即终止」来防止资源泄漏或重复提交，仅靠 orTimeout 是不够的。
- 常见错误现象：
orTimeout触发后，日志里仍看到任务完成打印，甚至数据库被重复写入 - 根本原因：Java 标准库中
CompletableFuture没有内置取消传播机制；orTimeout只是“放弃等待”，不调用cancel(true) - 正确做法：必须手动组合
orTimeout与可取消的执行逻辑（如封装在ExecutorService.submit(Callable)中，并显式调用Future.cancel(true)）
如何让 orTimeout 真正触发任务取消？
核心思路是把耗时操作包装进一个能响应中断的 Callable，并用可管理的 ExecutorService 提交，再通过 orTimeout 控制等待逻辑，超时后主动调用 cancel(true)。
示例关键片段：
ExecutorService executor = Executors.newCachedThreadPool();
CompletableFuture<string> future = CompletableFuture.supplyAsync(() -> {
try {
// 模拟可中断的阻塞操作（如带超时的 HttpClient 调用、带 Thread.interrupted() 检查的循环）
Thread.sleep(5000);
return "done";
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
throw new RuntimeException("Interrupted", e);
}
}, executor);
// 启动后立即拿到原始 Future 用于后续 cancel
Future> backingFuture = ((CompletableFutur...
// 实际中需用反射或自定义封装获取 —— 更推荐下面这种显式 submit 方式
</string>
更稳妥的实操建议：
- 不要依赖
supplyAsync的隐式Future，改用executor.submit(() -> { ... })显式获得Future - 在
orTimeout的回调中（如whenComplete或exceptionally），检查是否因TimeoutException失败，若是则调用对应Future.cancel(true) - 确保业务逻辑里所有阻塞调用都支持中断（例如用
HttpClient的withTimeout，而非Thread.sleep）
orTimeout 和 completeOnTimeout 的关键区别
两者都设超时，但行为完全不同，选错会导致熔断失效。
-
orTimeout：超时后返回一个以TimeoutException完成的CompletableFuture，原任务不受影响 -
completeOnTimeout：超时后直接用指定值「覆盖完成」当前CompletableFuture，但原任务仍运行 —— 这不是熔断，是“假装完成了” - 真正需要熔断防护时，
orTimeout+ 显式取消才是正解；completeOnTimeout适合兜底返回默认值的场景（如缓存降级），不适合防资源滥用 - 注意：两个方法返回的都是新
CompletableFuture，原实例不会被修改，链式调用时别丢了引用
容易被忽略的线程池配置陷阱
即使取消逻辑写对了，如果线程池本身不响应中断，任务照样停不下来。
- 避免使用
Executors.newFixedThreadPool或newCachedThreadPool：它们创建的线程默认不处理中断，cancel(true)可能无效 - 推荐用
new ThreadPoolExecutor(...)并设置threadFactory，确保线程在启动时保留中断能力 - 更简单方案：用
ForkJoinPool.commonPool()时要格外小心 —— 它的 worker 线程不响应interrupt()，cancel(true)对其提交的任务基本无效 - 生产环境建议独立配置专用线程池，并开启
allowCoreThreadTimeOut(true)防止空转线程堆积
真正的熔断不是加个 orTimeout 就完事，得从任务封装、线程模型、中断传播三层一起对齐。漏掉任意一层，超时就只是“看起来失败了”。
