Java 21 虚拟线程：一场颠覆高并发编程的“降维打击”

在 Java 的世界里，我们为了处理高并发，已经被“折磨”了太久。

为了榨干 CPU 的性能，我们学习复杂的线程池参数调优；为了解决 I/O 阻塞，我们被迫引入 CompletableFuture、RxJava 或 Reactor，把清晰的业务逻辑拆得支离破碎，跌入“回调地狱”。

直到 JDK 21 正式发布 虚拟线程（Virtual Threads），这一切迎来了终结。Java 终于拥有了类似 Go 语言 Goroutine 的轻量级并发模型。

今天，我们就剥开源码和原理的外衣，聊聊虚拟线程到底是如何实现“百万级并发”的，以及它是否存在不为人知的“暗坑”。

一、 为什么要“重新发明”线程？

要理解虚拟线程，首先得回头看看我们用了几十年的 平台线程（Platform Thread）。

在 JDK 21 之前，Java 的 java.lang.Thread 是一个1:1 的模型。也就是说，你每 new Thread() 创建一个 Java 线程，JVM 就会向操作系统申请一个内核级线程（OS Thread）。

这个模型有两个致命痛点：

1. 1. 昂贵：操作系统线程是重资源。创建一个线程需要分配约 1MB 的栈内存，且涉及内核态与用户态的上下文切换。你很难在一台机器上启动 10 万个线程，内存会直接爆炸。

2. 2. 阻塞浪费：当你的线程在等待数据库响应或网络 I/O 时，这个昂贵的 OS 线程就会被挂起（Blocked），什么都不做，白白占用资源。

为了解决这个问题，Reactive（响应式）编程诞生了。但响应式编程的代码可读性极差，堆栈信息在出错时更是难以追踪。

Java 团队想：我们要性能，但我们不要丑陋的异步代码。于是，虚拟线程诞生了。

二、 虚拟线程的魔法：M:N 模型

虚拟线程引入了 M:N 的调度模型。

• • M（大量虚拟线程）：你可以轻松创建 100 万个虚拟线程，它们非常轻量，初始栈空间只有几百字节，存在于 JVM 堆内存中。

• • N（少量平台线程）：JVM 内部维护了一个 ForkJoinPool，里面只有少量的平台线程（通常等于 CPU 核心数），被称为 载体线程（Carrier Threads）。

核心原理：Mount（挂载）与 Unmount（卸载）

虚拟线程的运行机制可以形象地比喻为“网约车模式”：

1. 1. 接单（Mount）：当一个虚拟线程需要执行 CPU 计算时，JVM 把它“挂载”到一个载体线程（司机）上执行。

2. 2. 堵车/等待（Unmount）：当虚拟线程执行到 I/O 操作（比如 socket.read()）或者 Thread.sleep() 时，它不会阻塞底层的载体线程。

• • JVM 会聪明地把这个虚拟线程的状态（堆栈、寄存器）保存到堆内存中（这个技术叫 Continuation）。

• • 然后把载体线程释放出来，去执行另一个虚拟线程的任务。

• 3. 恢复执行：当 I/O 操作完成，JVM 收到操作系统的通知，会重新把这个虚拟线程“唤醒”，再次挂载到一个可用的载体线程上继续运行。

• 结果： 底层的 OS 线程几乎永远在工作，没有一刻是闲置的，CPU 利用率被拉满，而我们写代码时却可以像写同步代码一样简单。

  三、 代码实战：1秒钟创建10万个线程？

  让我们用代码说话。如果使用传统线程池，尝试并发执行 10 万个休眠任务，机器可能会卡死或抛出 OOM。但使用虚拟线程：

  import java.time.Duration;
  import java.util.concurrent.Executors;
  import java.util.stream.IntStream;
  
  public class VirtualThreadDemo {
      public static void main(String[] args) {
          long start = System.currentTimeMillis();
  
          // Java 21 新增的虚拟线程执行器
          try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
              IntStream.range(0, 100_000).forEach(i -> {
                  executor.submit(() -> {
                      try {
                          // 模拟 I/O 操作，休眠 1 秒
                          Thread.sleep(Duration.ofSeconds(1));
                      } catch (InterruptedException e) {
                          // handle exception
                      }
                  });
              });
          } // try-with-resources 会自动等待所有任务完成
  
          long end = System.currentTimeMillis();
          System.out.println("耗时: " + (end - start) + "ms");
      }
  }

  运行结果： 整个过程大约仅需 10XX 毫秒。
  这意味着 JVM 并没有真的创建 10 万个 OS 线程，而是复用了极少数的载体线程，高效处理了这 10 万个并发任务。

  四、 深度剖析：并非万能药（避坑指南）

  虚拟线程虽好，但它不是银弹。如果你在生产环境盲目替换，可能会踩到两个大坑。

  1. 并不是所有任务都适合

  虚拟线程最适合 I/O 密集型 任务（Web 服务器、数据库调用、微服务调用）。
  对于 CPU 密集型 任务（视频转码、复杂数学运算），虚拟线程不仅没有优势，反而因为调度开销导致性能下降。对于计算密集型，传统的线程池依然是王者。

  2. 致命的 Pinning（钉住）问题

  这是目前虚拟线程最大的隐患。

  当虚拟线程执行到 synchronized 代码块或调用 JNI（本地方法）时，它会被 Pin（钉） 在载体线程上。
  这意味着，即使发生了 I/O 阻塞，JVM 也无法将它卸载（Unmount）。底层的载体线程会被连带着一起阻塞。

  错误示范：

  // 不要在虚拟线程中大量使用 synchronized
  synchronized (lock) {
      socket.read(); // 这里会发生 Pinning，导致底层的 OS 线程也被阻塞！
  }

  解决方案：
  如果你的老代码里充满了 synchronized，迁移到虚拟线程时需要谨慎。建议改用 ReentrantLock，JDK 团队已经对 ReentrantLock 做了完全的适配，它支持虚拟线程的卸载。

  五、 总结与展望

  Java 21 的虚拟线程，是 Java 历史上里程碑式的一步。

  它让我们回归了编程的初衷：用同步的思维写代码，享受异步的性能。

  • • 对于开发者：我们不再需要维护复杂的响应式链路，Controller 里的代码可以写得像流水账一样清晰。

  • • 对于架构：传统的 "Thread Pool" 模式可能会逐渐消亡，取而代之的是 "Thread per Request" 的复兴。

  最后给读者的建议：
  现在的 Spring Boot 3.2+ 已经内置了对虚拟线程的支持（只需配置 spring.threads.virtual.enabled=true）。去尝试升级你的 JDK 吧，但在抛弃线程池之前，请务必检查你的依赖库中是否滥用了 synchronized。

  Java 并没有老去，它刚刚完成了一次华丽的蜕变。