Java Virtual Threads虚线程与平台线程的调度差异

Java Virtual Threads虚线程与平台线程的调度差异

理解Java虚拟线程与平台线程在调度上的根本差异，是高效使用它们的前提。核心区别在于：平台线程的调度完全委托给操作系统，而虚拟线程的调度则由JVM自行管理。

第一部分：理解平台线程（操作系统线程）的调度

平台线程是Java线程的传统实现，与操作系统内核线程通常是一对一的关系。

1. 创建一个平台线程，例如通过 new Thread(...)。
2. 启动该线程，调用 start() 方法。
3. 操作系统调度器会介入，负责将这个线程分配到一个物理CPU核心上运行。
4. 当线程执行一个阻塞操作（如I/O、Thread.sleep）时，操作系统会将其状态设为阻塞，并从CPU核心上卸载。
5. 此时，操作系统调度器必须进行上下文切换，选择另一个就绪的线程来占用这个CPU核心。
6. 当阻塞操作完成后，操作系统调度器再次进行上下文切换，将原线程重新分配到CPU核心上。

这个过程的问题在于：

• 成本高昂：每次上下文切换都需要保存和恢复线程状态（寄存器、程序计数器等），开销大。
• 数量限制：操作系统能有效管理的线程数量有限（通常为数千到数万），因为每个线程都占用固定的内核资源和内存栈。

第二部分：理解虚拟线程的调度

虚拟线程是JVM管理的轻量级线程，不直接对应操作系统线程。

1. 创建一个虚拟线程，例如使用 Thread.ofVirtual().start(...) 或 Executors.newVirtualThreadPerTaskExecutor()。
2. JVM虚拟线程调度器负责管理它。调度器将虚拟线程分配到一个载体线程上执行。载体线程就是底层的平台线程。
3. 虚拟线程的代码开始运行。
4. 当虚拟线程遇到阻塞操作（如I/O、LockSupport.park、Thread.sleep）时，关键差异出现：
   • JVM不会让载体线程也阻塞。
   • 相反，JVM会将虚拟线程从其载体线程上“卸载”。
   • 载体线程随即被释放，可以去执行其他就绪的虚拟线程。
5. 当阻塞操作完成后，虚拟线程变为可运行状态。JVM调度器会将其重新分配给一个空闲的载体线程继续执行。

这个过程的优势在于：

• 成本极低：“卸载”和“分配”只是JVM内部的状态记录操作，远比操作系统上下文切换快。
• 数量巨大：JVM可以管理数百万甚至更多的虚拟线程，因为它们只是普通的Java对象，开销很小。

第三部分：调度差异的实际体现

为了更直观地对比，下表总结了核心差异：

第四部分：如何实际使用与观察差异

理解了理论，下面通过具体步骤来创建和监控这两种线程，感受调度差异。

步骤1：创建并运行一个高阻塞任务

我们模拟一个需要大量等待I/O的任务，这是虚拟线程的典型应用场景。

// 一个模拟网络请求的阻塞任务
private static void blockingTask(int taskId) {
    System.out.println("Task " + taskId + " started on thread: " + Thread.currentThread().getName());
    try {
        // 模拟耗时的网络I/O
        Thread.sleep(1000);
    } catch (InterruptedException e) {
        e.printStackTrace();
    }
    System.out.println("Task " + taskId + " finished on thread: " + Thread.currentThread().getName());
}

步骤2：使用平台线程执行任务

1. 创建一个固定大小的平台线程池，例如 Executors.newFixedThreadPool(100)。
2. 提交 1000 个任务。

ExecutorService platformExecutor = Executors.newFixedThreadPool(100);
for (int i = 0; i < 1000; i++) {
    int taskId = i;
    platformExecutor.submit(() -> blockingTask(taskId));
}
platformExecutor.shutdown();

观察输出，你会看到：

• 线程池名称通常是 pool-x-thread-y。
• 由于线程池大小只有100，但要执行1000个任务，任务会排队等待。当100个线程都在sleep时，整个线程池被阻塞，无法处理新任务，尽管CPU是空闲的。

步骤3：使用虚拟线程执行任务

1. 创建一个虚拟线程执行器 Executors.newVirtualThreadPerTaskExecutor()。它为每个任务创建一个新的虚拟线程。
2. 提交 同样的1000个任务。

ExecutorService virtualExecutor = Executors.newVirtualThreadPerTaskExecutor();
for (int i = 0; i < 1000; i++) {
    int taskId = i;
    virtualExecutor.submit(() -> blockingTask(taskId));
}
virtualExecutor.shutdown();

观察输出，你会看到：

• 线程名称通常是 "" 或类似 <unnamed> 的虚拟线程标识。
• 所有1000个任务几乎同时启动（因为创建1000个虚拟线程开销很小）。
• 当任务执行Thread.sleep时，虚拟线程被卸载，其载体线程被释放去执行其他刚启动的虚拟线程。整个过程流畅，没有因I/O等待而卡住其他任务。

步骤4：配置与监控虚拟线程调度器

JVM提供了一些参数和API来微调调度器。

1. 限制载体线程数量：通过系统属性 -Djdk.virtualThreadScheduler.parallelism=N 设置载体线程池大小（默认为CPU核心数）。N通常设置为CPU核心数。
2. 设置最大载体线程数：通过 -Djdk.virtualThreadScheduler.maxPoolSize=M 限制载体线程池上限。在CPU密集型混合场景下有用。
3. 使用jcmd进行监控：在应用运行时，可以使用JDK自带的jcmd工具查看虚拟线程状态。

   # 找到Java进程ID（PID）
   jps -l
   # 打印虚拟线程信息
   jcmd <PID> Thread.dump_to_file -format=json <输出文件路径.json>

   分析生成的JSON文件，可以看到"isVirtual": true的线程，以及它们当前是运行中、阻塞在哪个监视器锁或I/O上。

第五部分：调度差异带来的编程范式转变

1. 停止为I/O优化线程池大小：过去，为I/O密集型任务精心调整线程池大小是必要之举。现在，对于纯阻塞I/O任务，直接使用虚拟线程执行器（每任务一个线程）通常是最佳选择，因为调度成本已可忽略。
2. synchronized可能成为瓶颈：当虚拟线程在synchronized块内阻塞时，它目前无法从载体线程上卸载（JDK 21+正在改进）。这意味着它会占用一个载体线程直到锁释放。应考虑使用ReentrantLock，因为虚拟线程在其上阻塞时可以被卸载。
3. 避免长时间占用CPU：虚拟线程的调度依赖协作式让出。如果一个虚拟线程执行纯CPU计算而长时间不阻塞，它将一直占用其载体线程，影响其他虚拟线程的调度。可以在计算循环中插入 Thread.yield() 提示调度器。
4. 使用结构化并发：虚拟线程使得“每请求一并发”成为可能。结合 StructuredTaskScope（预览特性），可以更清晰地管理一组相关任务的生命周期和取消，而不是操作独立的线程池。