Java 怎样用虚拟线程执行阻塞任务

使用 Thread.ofVirtual().name(...).start(task) 可以创建并启动虚拟线程来执行阻塞任务，返回的 Thread 句柄用于等待或请求中断。任务需要完成后调用方才能继续时，应显式 join；启动成功不等于任务成功，中断请求也不等于已经结束。

官方使用指南：https://docs.oracle.com/en/java/javase/25/core/virtual-threads.html。下面示例面向 JDK 21 或以上，只展示构建器和生命周期，不使用预览特性。

先确认任务是等待型，而不是想给计算加速

典型需求是用同步写法表达等待：例如等待一次远端响应或数据库返回。虚拟线程的价值在于支撑大量等待型并发任务，不是让单个任务的 Java 指令执行得更快。本例用短暂 sleep 模拟可中断等待，不访问真实服务，也不提供吞吐量测试。

在生产代码中，超时、连接数和业务资源仍需独立管理。换成虚拟线程不会自动扩大数据库连接池，也不会让阻塞调用无条件可取消。本文先把范围缩到一个任务、一个句柄和一个明确负责等待的调用者。

构建器描述线程，Thread 句柄代表具体任务

Thread.ofVirtual 返回构建器，name 配置线程名称。直接 start(task) 会创建并启动线程；unstarted(task) 只创建未启动线程，适合需要先保存句柄或补充设置的情形，之后还要调用 Thread.start。名称帮助定位任务，不是任务成功状态。

同一个线程只能启动一次；若需要执行另一个独立任务，应创建另一个线程对象，而不是再次启动已结束的句柄。本例选择 unstarted，让“配置”和“启动”在代码中容易辨认。构建器参考：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.Builder.OfVirtual.html。

写一个保留失败记录的有限等待示例

保存为 VirtualWaitDemo.java。主线程负责启动和等待；任务自己记录 InterruptedException，未捕获异常处理器补充记录其他未捕获失败。AtomicReference 是这个小示例的结果通道，不表示 Thread 自带业务返回值。

import java.util.concurrent.atomic.AtomicReference;

public class VirtualWaitDemo {
    public static void main(String[] args) throws InterruptedException {
        var failure = new AtomicReference();

        Runnable task = () -> {
            try {
                // 仅模拟有限、可中断的阻塞等待，不访问外部服务
                Thread.sleep(300);
            } catch (InterruptedException e) {
                failure.set(e);
                Thread.currentThread().interrupt();
                // 收到取消后退出，不继续执行成功路径
            }
        };

        Thread worker = Thread.ofVirtual()
            .name("report-wait")
            .uncaughtExceptionHandler((thread, error) -> failure.set(error))
            .unstarted(task);

        worker.start();
        try {
            // 等待终止不自动转抛任务异常，因此另设失败记录
            worker.join();
        } catch (InterruptedException e) {
            // 等待者取消时，向任务请求中断，再把取消交给上层
            worker.interrupt();
            throw e;
        }

        if (failure.get() != null) {
            throw new IllegalStateException("任务未正常完成", failure.get());
        }
        System.out.println("任务已完成，虚拟线程=" + worker.isVirtual());
    }
}

正常路径的预期输出是“任务已完成，虚拟线程=true”。本文未运行示例，不把这句话当成本机测试结果。sleep 时长只是演示参数，不是响应时间保证；线程调度可能让实际等待更久。

# 在装有 JDK21 或以上的示例目录编译
javac -encoding UTF-8 VirtualWaitDemo.java
# 运行单个有限等待任务，不需要网络或数据库
java VirtualWaitDemo

把终止、成功和取消分开处理

join 的职责是等待线程终止，不是读取业务结果。一个线程因未捕获异常退出，依然属于已经终止。示例先等 join 返回，再检查 failure，避免输出一条具有误导性的成功消息。真实业务如果还可能出现“没有抛异常但结果被拒绝”，还要记录业务状态，不能只看异常有没有发生。

interrupt 是协作请求。示例的 sleep 会通过 InterruptedException 响应，任务捕获后恢复自己的中断标志并结束。主线程若在 join 时被中断，则请求 worker 中断并向上抛出异常；该取消分支没有等待 worker 终止，所以不能把它解释为“资源已经全部释放”。真实连接、文件或客户端应在任务自身的 finally 或 try-with-resources 中清理。

若为 join 加超时，超时返回后也不能直接宣告成功。应检查线程是否结束，再按业务策略记录仍在执行、请求取消或转交后续管理。不要把等待超时等同于远端操作回滚。Thread API：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/Thread.html。

不要把 run 当启动，也别依赖进程替你等完

应调用 start 来调度线程，不要把 worker.run 当作启动虚拟线程的方法。为了观察异步完成而随意在 main 里睡几秒也不可靠：等待多久与任务实际终止没有严格对应，使用 join 才能表达这里的依赖关系。

虚拟线程是守护线程，不会独自阻止 JVM 开始退出。因此命令行任务的调用者必须承担等待职责，不能认为创建了 worker 后程序自然会等它结束。长运行服务也应有明确的任务归属和关闭策略，不能只让后台任务脱离管理。

最小生命周期速查

能重复使用同一个 Thread 吗？不能重新启动，应创建新实例。为什么主线程 join 完了仍可能任务失败？终止与成功是两件事，异常或业务结果应单独传递。是否需要为本例搭建线程池？单个构建器示例不需要；大量业务任务的管理是另一个层次，不应靠丢弃句柄来省略。

落地时只要先明确三件事：谁创建任务，谁负责等待，失败或取消由谁接收。把这些生命周期责任写进代码后，再讨论更多并发任务与资源限制，才能避免“线程启动了，任务却没人管”的问题。