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

在 Java 21 正式发布之前，Java 的并发模型一直依赖于操作系统内核线程。这种传统的线程模型在处理高并发请求时，往往受限于内存和上下文切换的开销。为了从根本上解决这个问题，Java 引入了虚拟线程。理解这两者在调度机制上的差异，是编写高吞吐量 Java 应用的关键。

理解平台线程的调度机制

平台线程是 Java 传统模型中的核心，也就是我们通常所说的“内核级线程”。要理解它的局限性，首先要搞清楚它是如何被调度的。

1. 认识 1:1 映射模型
   在传统模型中，每一个 Java 的 Thread 实例都直接对应操作系统中的一个线程。当你 new Thread() 并 start() 时，JVM 会向操作系统发起系统调用，请求创建一个真正的内核线程。

2. 理解操作系统的全权接管
   一旦平台线程创建完成，它的调度权就完全移交给了操作系统（OS）。JVM 不知道也不关心哪个线程正在 CPU 上运行，也不决定哪个线程该等待。操作系统根据时间片、优先级等算法，决定哪个线程在 CPU 核心上执行。

3. 意识到阻塞的高昂代价
   当平台线程执行 I/O 操作（如读取文件、等待网络请求）时，它必须进入阻塞状态。此时，操作系统会挂起该线程，保存上下文，并切换到其他线程。这个“上下文切换”涉及到用户态与内核态的转换，需要消耗大量的 CPU 周期和内存（通常每个线程需要分配 1MB 左右的栈空间）。

拥抱虚拟线程的调度机制

虚拟线程是为了解决平台线程“重量级”和“数量受限”的问题而诞生的。它是一种用户态线程，由 JVM 调度，而非操作系统。

1. 掌握 M:N 调度模型
   虚拟线程采用了 M:N 的调度模型。即：大量的虚拟线程（M）运行在较少的操作系统平台线程（N）之上。这些作为载体的平台线程通常被称为“载体线程”，默认数量等于 CPU 核心数。

2. 理解 JVM 调度器的角色
   在虚拟线程模型中，JVM 充当了“轻量级操作系统”的角色。JVM 的调度器负责将虚拟线程分配到载体线程上执行。调度器使用 ForkJoinPool 的实现变种来管理任务队列。

   为了更直观地展示两者在调度流向上的差异，请参考下面的流程对比图：

   graph LR subgraph OS["操作系统内核态"] PT1["平台线程 1 (Carrier)"] PT2["平台线程 2 (Carrier)"] CPU["CPU 核心"] end subgraph JVM["JVM 用户态"] VT1["虚拟线程 A"] VT2["虚拟线程 B"] VT3["虚拟线程 C"] Scheduler["JVM 调度器"] end VT1 -->|挂载| Scheduler VT2 -->|挂载| Scheduler VT3 -->|挂载| Scheduler Scheduler -->|分配执行| PT1 Scheduler -->|分配执行| PT2 PT1 --> CPU PT2 --> CPU

3. 体验“几乎免费”的创建成本
   虚拟线程仅仅是 JVM 堆上的一个对象。创建一个虚拟线程不需要向操作系统申请资源，也不需要分配固定的 1MB 栈内存。你可以轻松地在单个 JVM 实例中创建数百万个虚拟线程。

深入对比：阻塞行为的本质差异

平台线程与虚拟线程最大的区别在于它们“如何等待”。这也是虚拟线程能大幅提升吞吐量的秘密所在。

平台线程的阻塞

当平台线程遇到 I/O 操作时：

1. 操作系统介入：JVM 检测到 I/O 操作，向操作系统发起请求。
2. 线程休眠：操作系统将底层的内核线程标记为休眠状态，将其从 CPU 的运行队列中移除。
3. 资源闲置：虽然线程什么都不做，但它所占用的内核栈内存和线程结构体依然保留在内存中，直到 I/O 完成被唤醒。

虚拟线程的阻塞与卸载

当虚拟线程遇到 I/O 操作时：

1. JVM 拦截：JVM 识别到虚拟线程正在进行阻塞操作。
2. 状态卸载：JVM 将虚拟线程的当前状态（栈帧、局部变量等）保存到堆内存中。
3. 释放载体：此时，底层的载体线程（平台线程）被立即释放。它不会闲着，而是立即去执行队列中下一个等待运行的虚拟线程。
4. 状态重载：当 I/O 操作完成（例如网络数据包到达），JVM 会将刚才保存的虚拟线程状态重新挂载到一个空闲的载体线程上，继续执行。

这种机制使得你在处理成千上万个并发请求时，只需要少量的 CPU 核心就能保持忙碌，而不会因为大量的 I/O 等待导致线程上下文频繁切换。

代码实操：创建与运行虚拟线程

为了在代码中体验差异，我们可以使用 Thread.ofVirtual() 工厂方法或 Executors 来创建虚拟线程。

1. 准备 Java 环境
   确保你的 JDK 版本为 21 或更高。可以在终端运行 java -version 命令确认。

2. 编写虚拟线程示例
   创建一个名为 VirtualThreadDemo.java 的文件，并输入以下代码：

   public class VirtualThreadDemo {
       public static void main(String[] args) {
           // 创建一个包含 10 万个任务的列表
           int threadCount = 100_000;
   
           // 使用虚拟线程执行任务
           for (int i = 0; i < threadCount; i++) {
               Thread.ofVirtual().start(() -> {
                   try {
                       // 模拟耗时操作
                       Thread.sleep(1000);
                       System.out.println("Thread finished: " + Thread.currentThread().getName());
                   } catch (InterruptedException e) {
                       Thread.currentThread().interrupt();
                   }
               });
           }
   
           // 保持主线程存活，以便观察虚拟线程执行
           try {
               Thread.sleep(5000);
           } catch (InterruptedException e) {
               e.printStackTrace();
           }
       }
   }

3. 运行并观察
   编译并运行上述代码。

   • 如果是平台线程，创建 10 万个线程极大概率会导致 OutOfMemoryError 或系统卡死。
   • 使用虚拟线程时，你会看到程序几乎瞬间启动，并在几秒钟内处理完所有任务。这就是“卸载”机制带来的高吞吐量。

关键特性对比总结

为了方便记忆和查阅，下表总结了平台线程与虚拟线程在调度层面的核心差异。

实战建议：何时使用虚拟线程

理解了调度差异后，在实际开发中应遵循以下原则：

1. 优先用于 I/O 密集型任务
   如果你的应用主要是处理 HTTP 请求、数据库查询、消息队列消费等涉及大量等待的操作，毫不犹豫地使用虚拟线程。它能用极少的硬件资源支撑极高的并发量。

2. 避免用于 CPU 密集型计算
   虚拟线程本身并不能加速计算。如果你的任务是一直占满 CPU 进行数学运算，使用虚拟线程不仅没有优势，反而会增加 JVM 调度的开销。对于这类任务，应限制数量，使其大致等于 CPU 核心数。

3. 使用 synchronized 时需谨慎
   虽然虚拟线程可以被卸载，但在执行 synchronized 代码块或方法时，虚拟线程会被“钉”在载体线程上。这意味着在锁竞争激烈且持有时间较长的情况下，载体线程无法被释放，会导致吞吐量下降。在可能的情况下，优先使用 ReentrantLock 来替代 synchronized，因为前者支持在等待锁时卸载虚拟线程。

4. 使用线程池管理生命周期
   不要手动创建成千上万个虚拟线程。使用 Executors.newVirtualThreadPerTaskExecutor() 来获取一个 ExecutorService。这个执行器为每个任务创建一个新的虚拟线程，并在任务结束后自动回收。

   try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
       // 提交任务
       executor.submit(() -> System.out.println("Task running"));
   } // try-with-resources 会自动关闭 executor

通过理解 JVM 如何在用户态接管线程调度，以及如何通过“挂载”和“卸载”来处理阻塞，你就能充分发挥 Java 虚拟线程的威力，构建出高效、简洁的高并发应用。