Java virtual threads 怎样让任务支持可取消超时

Java 虚拟线程本身不会自动给任务增加“超时就停止”的语义。可靠做法是把职责拆开：调用方用 Future.get(timeout, unit) 限制等待时间，超时后调用 future.cancel(true) 发出取消和中断请求，任务内部在可中断的阻塞点或业务检查点响应中断，并在 finally 中释放连接、流等资源。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/Executors.html

先把“等待超时”和“任务取消”分成两件事

Future.get(800, MILLISECONDS) 的时间限制作用在等待结果的调用线程上。时间到了以后，它抛出 TimeoutException，但后台任务可能仍在执行；如果此时直接返回 HTTP 超时，后台任务还可能继续占用连接或写入共享状态。

因此要形成完整链路：等待超时 → 请求取消 → 运行中的线程收到中断 → 任务在安全点收尾 → 调用方记录最终状态。Future.cancel(true) 的参数表示允许实现尝试中断正在执行任务的线程，返回值只能说明取消请求是否被接受，不能承诺任务已经完成清理。

用虚拟线程执行器提交可以被取消的任务

Java 21 起可以用 Executors.newVirtualThreadPerTaskExecutor() 为每个提交的任务创建虚拟线程。它不是传统意义上把任务塞进固定大小的平台线程池；并发外部服务数量仍应由业务层的信号量、连接池或服务端配额控制。本文只处理单个任务的超时取消。

import java.time.Duration;
import java.util.concurrent.Callable;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;

public class CancellableVirtualTask {
    static String loadReport() throws InterruptedException {
        // 模拟一个可能长时间阻塞的 I/O；真实代码应调用可中断的客户端。
        Thread.sleep(Duration.ofSeconds(3));
        return "report-ready";
    }

    public static void main(String[] args) {
        Callable task = CancellableVirtualTask::loadReport;

        // 执行器负责管理虚拟线程，离开 try 块时会关闭并等待已提交任务。
        try (ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor()) {
            Future future = executor.submit(task);
            try {
                // 这里只限制当前调用方等待结果的时间。
                String result = future.get(800, TimeUnit.MILLISECONDS);
                System.out.println("result=" + result);
            } catch (java.util.concurrent.TimeoutException timeout) {
                // true 允许执行器向运行中的任务发出中断请求。
                boolean accepted = future.cancel(true);
                System.out.println("timeout, cancelAccepted=" + accepted);
            } catch (java.util.concurrent.ExecutionException failure) {
                // 任务异常要记录 cause，不能把所有失败都当成超时。
                System.out.println("task failed: " + failure.getCause());
            } catch (InterruptedException interrupted) {
                // 当前等待者被打断时恢复标记，并尝试取消子任务。
                future.cancel(true);
                Thread.currentThread().interrupt();
            }
        }
    }
}

这个示例里，get 超时后会调用 cancel(true)。由于 loadReport 的 sleep 能响应中断，任务有机会快速退出；如果底层客户端吞掉中断或处在不响应中断的外部调用中，就必须额外使用客户端自己的超时和关闭接口。

超时后怎样判断取消请求是否真的生效

cancel(true) 返回 true 通常表示任务尚未完成并接受了取消请求；它不是“任务已经执行完清理”的回执。任务可能正好在调用前完成，也可能捕获中断后又做少量收尾。

static void cancelAfterTimeout(Future> future) {
    // 只有等待超时路径才进入这里，避免误取消已经成功的任务。
    boolean cancelled = future.cancel(true);
    if (!cancelled && future.isDone()) {
        // false 且 done 表示任务可能已完成或已被其他线程处理。
        System.out.println("task already finished or cancelled");
    } else if (cancelled) {
        // 这里只记录取消请求已接受，不能代替任务内部的 finally 清理。
        System.out.println("cancellation requested");
    }
}

如果业务需要等待“取消后的最终状态”，可以在记录取消请求后再用一个很短的收尾等待，或让任务向自己的状态对象发布 CANCELLED。不要在超时处理器中无期限调用 future.get()，否则刚设置的上游超时又被重新阻塞。

任务内部必须把中断当成控制信号

取消能否及时生效，关键在任务代码。对 InterruptedException，常见做法是停止继续工作、在 finally 关闭资源，并在无法继续抛出检查异常时恢复当前线程的中断标记。不要捕获后静默忽略，也不要把中断异常转换成普通业务成功。

static String callService(java.net.http.HttpClient client,
                          java.net.http.HttpRequest request)
        throws InterruptedException, java.io.IOException {
    java.net.http.HttpResponse response = null;
    try {
        // HttpClient 的请求应配置自身的连接/响应超时，避免只依赖线程中断。
        response = client.send(request,
                java.net.http.HttpResponse.BodyHandlers.ofString());
        return response.body();
    } catch (InterruptedException interrupted) {
        // 向上层保留取消原因，让 finally 和调用方完成统一收尾。
        Thread.currentThread().interrupt();
        throw interrupted;
    } finally {
        // 若这里还有手工打开的流、响应体或临时文件，应在此关闭或删除。
        response = null;
    }
}

对文件流、数据库连接、响应体等资源，优先使用各自的 try-with-resources。上面的 response = null 只是强调示例没有额外拥有可关闭句柄；真实代码不能用赋空引用代替关闭资源。

三种结果用状态表收口

“超时已请求取消”和“任务已经停止”最好使用不同状态，便于排查慢服务、连接池占用和资源泄漏。若监控只记录了 TimeoutException，却没有记录 cancel 的结果与任务最终结束时间，通常无法判断取消链路是否闭合。

哪些情况不能只依赖 virtual threads 的中断

• CPU 密集循环：循环没有检查 Thread.interrupted() 时，取消请求不会凭空停止计算，应增加检查点或拆分任务。
• 外部客户端：线程中断不一定等同于远端请求取消，HTTP、数据库、消息客户端仍要配置自己的连接和响应超时。
• 共享副作用：任务可能已经写入一部分文件、数据库或消息，取消只改变控制流，不能自动撤销业务副作用。
• 执行器关闭：虚拟线程轻量并不代表可以忘记关闭执行器；用 try-with-resources 明确它的生命周期。

常见问题

Future.get 超时后任务会自动停止吗？

不会。它只让等待者收到 TimeoutException；需要显式调用 cancel(true)，并让任务响应中断或自己的客户端超时。

cancel(false) 和 cancel(true) 怎样选？

false 不请求中断正在运行的任务，适合只取消尚未启动的工作；需要停止可中断 I/O 时通常选择 true，但仍要处理资源和副作用。

捕获 InterruptedException 后为什么要恢复中断标记？

因为捕获该异常通常会清除当前线程的中断状态。若当前方法不能继续向上抛出，就调用 Thread.currentThread().interrupt()，把取消信号交给更上层。

官方资料

Future API：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/Future.html

Thread API：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.html

虚拟线程指南：https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html