如何利用 CompletableFuture 的 orTimeout 实现对异步任务执行周期的强制熔断

异步编程里，CompletableFuture 的 orTimeout 是个很有用的工具，但一个经典问题来了：它会直接中断正在运行的异步任务吗？答案很明确：不会。orTimeout 只是给 CompletableFuture 的完成过程加一个超时判定，它不会调用 Thread.interrupt()，也不会主动取消底层任务（比如 supplyAsync 中提交的 Runnable 或 Supplier）。任务线程继续跑，只是你后续对这个 future 的 get()、join() 或链式回调不会再等它——而是立即抛出 TimeoutException 或 fallback 到你指定的默认值。

说白了，如果你的任务本身不响应中断、也不检查超时状态，orTimeout 只能“掩盖”超时，不能“终止”资源消耗。

正确配合 cancel(true) 才能实现真正熔断

那么，怎样才能让任务真的停下来？关键一步是主动触发取消，并让任务逻辑里能响应中断。典型做法是把原始任务包进一个可取消的 CompletableFuture，并在 orTimeout 触发后调用 cancel(true)：

CompletableFuture task = CompletableFuture.supplyAsync(() -> {    try {        Thread.sleep(5000); // 模拟长耗时        return "done";    } catch (InterruptedException e) {        Thread.currentThread().interrupt(); // 保留中断状态        throw new RuntimeException("task interrupted", e);    }});CompletableFuture withTimeout = task    .orTimeout(1, TimeUnit.SECONDS)    .exceptionally(ex -> {        if (ex instanceof TimeoutException) {            task.cancel(true); // 关键：显式中断执行线程            return "fallback";        }        return null;    });

• orTimeout 自身不取消任务，但会把 future 置为异常完成状态
• exceptionally 是唯一可靠捕获 TimeoutException 的位置（handle 也能，但需额外判空）
• task.cancel(true) 向执行线程发中断信号，前提是任务内部有 sleep、wait、BlockingQueue.take() 等可中断点

orTimeout 和 completeOnTimeout 的行为差异

有意思的是，orTimeout 还有一个双胞胎兄弟叫 completeOnTimeout，二者都设超时，但语义和副作用完全不同：

• orTimeout(1, SECONDS)：超时后 future 立即以 TimeoutException 完成；原始任务照常运行
• completeOnTimeout("fallback", 1, SECONDS)：超时后 future 以你给的默认值完成；同样不取消原始任务
• 两者都不带自动取消能力，completeOnTimeout 还容易掩盖错误——因为返回的是正常值，而非异常
• 生产环境更推荐 orTimeout + exceptionally + cancel(true) 组合，失败可观测、熔断可追踪

线程池未配置拒绝策略时的隐藏风险

话说回来，光知道上面这些还不够。如果用的是无界队列的自定义线程池（比如 new ThreadPoolExecutor(core, max, keepAlive, unit, new LinkedBlockingQueue())），而任务又没做取消响应，orTimeout 后大量堆积的未完成任务可能吃光内存或拖垮线程池。

几点现实建议：

• 给线程池配有限队列 + CallerRunsPolicy 或 AbortPolicy
• 在 supplyAsync 里显式传入带监控/超时感知的 Executor，而不是依赖 ForkJoinPool.commonPool()
• 关键任务务必在逻辑开头检查 Thread.currentThread().isInterrupted()，避免“已超时却还在算”的情况

超时不是终点，而是熔断决策的起点；真正难的从来不是设个时间，而是让整个执行链路对中断信号有反应。