Java CompletableFuture 超时后如何停止后续处理：orTimeout 与异常分支的边界

线上调用一个慢服务时，给 CompletableFuture 加上 orTimeout，常见误解是“超时了，后台任务也停了”。实际情况是：超时只改变这个 future 的完成结果，已经运行的底层任务仍可能继续占用线程。要真正停止后续处理，需要让任务主动观察取消信号，或者让执行代码响应中断。

orTimeout 负责把 future 置为异常完成；它不会替你中断底层任务。把超时当成控制流的一部分，并在任务内部设计可观察的停止条件，才是完整方案。

先复现：超时结果已经返回，任务为什么还在跑

先看一个最小例子。slowTask 模拟需要较长时间的工作，调用方只等待 100 毫秒。这里的重点不是等待时间本身，而是观察两个输出：调用方看到的 future 结果，以及任务线程后续是否还打印进度。

ExecutorService pool = Executors.newSingleThreadExecutor();
CompletableFuture future = CompletableFuture.supplyAsync(() -> {
    try {
        Thread.sleep(500);
        System.out.println("slowTask finished");
        return "ok";
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return "interrupted";
    }
}, pool);

future.orTimeout(100, TimeUnit.MILLISECONDS)
      .exceptionally(ex -> {
          System.out.println(ex.getClass().getSimpleName());
          return "fallback";
      })
      .join();
pool.shutdown();

调用方很快会进入 exceptionally，看到 TimeoutException 对应的异常分支；但如果线程已经进入 sleep，仍可能随后打印 slowTask finished。这个现象说明 future 的完成状态和实际执行线程是两件事。

为什么 exceptionally 能接住超时，却不能自动清理任务

orTimeout 的作用是：在规定时间内没有正常完成时，让同一个 CompletableFuture 以 TimeoutException 异常完成。下游的 exceptionally 于是有机会返回降级值，调用方也能结束等待。

但 CompletableFuture 只是异步结果的编排对象，不等于它所依赖的线程。超时定时器修改的是结果状态，不会凭空知道任务正在访问哪个文件、连接哪个 socket，也不能安全地替业务代码决定清理动作。

把超时、异常和正常返回分开验证

调试时可以给三个位置打日志：任务开始、future 完成、任务真正退出。若 future 已经输出降级结果，而任务退出日志更晚出现，就能确认“结果先结束、任务后结束”的时间关系。不要只看接口返回时间就断言线程已经停止。

cancel 能不能解决：关键在于底层任务是否响应中断

cancel(true) 会让 future 进入取消状态，并尝试通过 Thread.interrupt 中断关联执行，但它不是对任意代码都有效的强制终止。任务如果吞掉 InterruptedException，或者长时间执行不检查中断标记，线程仍可能继续做事。

CompletableFuture future = CompletableFuture.supplyAsync(() -> {
    while (!Thread.currentThread().isInterrupted()) {
        doOneSmallUnit();
    }
    return "stopped";
}, pool);

try {
    future.orTimeout(100, TimeUnit.MILLISECONDS).join();
} catch (CompletionException e) {
    if (e.getCause() instanceof TimeoutException) {
        future.cancel(true);
    }
}

这个写法能表达“超时后发出取消意图”，但是否及时停下仍由 doOneSmallUnit 的边界决定。阻塞调用还要正确处理 InterruptedException，并在清理后恢复中断标记。

一套可落地的超时处理检查顺序

1. 先定义结果边界。决定超时后返回降级值、抛出业务异常，还是交给上层重试；用 orTimeout 或 exceptionally 表达调用方看到的结果。
2. 再定义停止信号。对可分段任务，在每个小单元之间检查 Thread.currentThread().isInterrupted()；对阻塞 API，保留中断语义，不要空 catch。
3. 最后验证真实退出。分别记录 future 完成与任务 finally 的时间，确认线程池队列、连接、文件句柄等资源确实回收。

常见误区与复查方式

把 join 返回当成线程退出

join 只说明当前 future 已完成，不代表业务 lambda 的资源清理已经结束。把线程退出日志放在 finally 中更可靠。

捕获中断后继续循环

如果捕获 InterruptedException 后直接继续工作，线程池的停止意图会被吞掉。通常应恢复中断标记，并让任务返回或抛出。

把 timeout 当成重试许可

一次超时后立即重试，可能让旧任务和新任务同时访问同一资源。先确认旧任务能停止，再决定是否重试。

延伸问答

orTimeout 会创建新的 future 吗？

它返回同一个 CompletableFuture，超时后让该 future 异常完成，调用链可以继续接异常处理阶段。

任务没有响应中断怎么办？

把大任务拆成可检查的小单元，修正阻塞调用的中断处理；如果依赖本身不可中断，就只能把超时视为结果边界并单独治理资源。

怎样证明任务真的停了？

同时记录 future 完成、任务 finally、线程池关闭和资源释放日志；只看到接口返回或 cancel 返回值还不够。

小结

Java 异步编排里，超时结果和底层执行是两个层次。orTimeout 解决“调用方等多久”，cancel 表达“希望任务停止”，而任务内部的中断检查和清理逻辑才决定“它什么时候真的停”。把这三层分别记录、分别验收，超时处理才不会留下隐形的后台工作。