Java 21 虚拟线程的运行机制与迁移注意事项

# Java 21 虚拟线程的运行机制与迁移注意事项

Java 21 正式发布的虚拟线程（Virtual Threads，Project Loom）改变了 Java 长期依赖的 1:1 操作系统线程模型。在处理高并发、I/O 密集型业务时，虚拟线程能够以极低的资源开销提升系统的整体吞吐量。

然而，将现有项目迁移到虚拟线程并非只是简单替换 `ExecutorService` 实现，如果不理解其底层的载体线程调度机制，可能会在生产环境中引发载体线程锁死、内存暴涨或下游资源击穿等问题。

---

## 1. 运行机制差异

传统平台线程（Platform Thread）直接映射到操作系统的内核线程，创建成本高（默认栈空间约 1MB），数量通常受限于操作系统和物理内存。

虚拟线程由 JVM 在用户空间进行管理，其核心是基于 `Continuation` 机制：

1. **载体线程（Carrier Thread）**：JVM 内部维护了一个 `ForkJoinPool` 作为虚拟线程的载体池，默认大小等于系统的 CPU 可用核心数。
2. **挂载与卸载（Mount / Unmount）**：当虚拟线程执行阻塞 I/O 操作（如 Socket 读写、`Thread.sleep`）时，JVM 会保存其调用栈帧（Continuation），将该虚拟线程从载体线程上卸载。载体线程随即执行其他就绪的虚拟线程。
3. **恢复执行**：当底层 I/O 事件就绪时，操作系统通过 epoll/kqueue 等多路复用机制通知 JVM，JVM 将未完成的虚拟线程重新提交给载体池调度执行。

---

## 2. 关键迁移与排查问题

### 2.1 载体线程固定（Pinning）

当虚拟线程被“固定”在载体线程上时，即使发生阻塞 I/O，JVM 也无法将其卸载，导致底层的平台线程被长期占用。

触发 Pinning 的主要场景：
- 在 `synchronized` 关键字保护的代码块或方法内部执行阻塞调用。
- 调用 JNI 本地方法。

在载体线程数（CPU 核心数）较少的情况下，若干个并发的 Pinning 状态即可耗尽载体池，使其他虚拟线程得不到执行时间。

**改造方式**：将遗留代码中的 `synchronized` 替换为 `java.util.concurrent.locks.ReentrantLock`。

```java
// 问题代码：在 synchronized 内部进行阻塞式网络调用，导致载体线程被 Pinning
public synchronized String fetchRemoteData(String url) {
    return httpClient.get(url);
}

// 改造代码：使用 ReentrantLock，等待锁或发生 I/O 时载体线程可正常释放
private final ReentrantLock lock = new ReentrantLock();

public String fetchRemoteData(String url) {
    lock.lock();
    try {
        return httpClient.get(url);
    } finally {
        lock.unlock();
    }
}
```

**排查手段**：
通过在 JVM 启动参数中添加参数，使 JVM 在发生 Pinning 时打印调用栈：
```bash
-Djdk.tracePinnedThreads=full
```

---

### 2.2 线程池的使用方式转变

在传统架构中，线程池主要承担两项职责：
1. **复用昂贵的线程资源**；
2. **通过核心/最大线程数限制并发量，保护下游资源**。

对于虚拟线程，由于其创建和销毁开销极低，**不应该对其进行池化**。池化虚拟线程不仅违背设计初衷，还会增加管理开销。

```java
// 不推荐：池化虚拟线程
ExecutorService pool = Executors.newFixedThreadPool(200, Thread.ofVirtual().factory());

// 推荐：按任务即时创建
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> handleRequest(request));
}
```

如果需要限制对某个具体资源（如外部 RPC、数据库）的并发访问数，应使用 `Semaphore`：

```java
public class ResourceClient {
    // 限制同时并发调用该资源的虚拟线程数量为 50
    private final Semaphore limiter = new Semaphore(50);

    public void call() throws InterruptedException {
        limiter.acquire();
        try {
            doRemoteCall();
        } finally {
            limiter.release();
        }
    }
}
```

---

### 2.3 ThreadLocal 的内存累积

在传统线程池中，由于线程总量有限（例如固定 200 个），即使每个 `ThreadLocal` 变量占用较大内存，总开销也是受控的。

而在虚拟线程场景下，活跃线程数可能达到数万甚至数十万级别。如果在虚拟线程中大量使用 `ThreadLocal` 缓存复杂对象或缓冲区，将导致内存占用线性上升，容易触发 Full GC 或 OOM。

**建议措施**：
- 审查第三方库中是否存在重型 `ThreadLocal`（如复用大型字节数组、序列化 Context）。
- 跨栈帧传递上下文参数时，评估使用 `java.lang.ScopedValue`（预览特性）替代 `ThreadLocal`。

---

### 2.4 任务类型适配性

虚拟线程的设计目标是提高系统在 **I/O 阻塞等待** 时的硬件利用率。

- **适用场景**：HTTP 服务处理、RPC 服务调用、数据库交互、文件 I/O。
- **不适用场景**：CPU 密集型计算（如密码哈希计算、视频编解码、大矩阵运算）。对于 CPU 密集型任务，线程数超过物理核心数后，虚拟线程不仅无法提高执行速度，还会因为频繁的调度和内存栈管理带来额外的性能损耗。

---

## 3. Spring Boot 工程接入示例

在 Spring Boot 3.2 及以上版本中，可以通过配置直接启用虚拟线程支持：

```yaml
spring:
  threads:
    virtual:
      enabled: true
```

启用后，Spring MVC 的嵌入式 Tomcat 以及 `@Async` 异步任务执行器将自动切换为使用虚拟线程。

对于数据库连接池（如 HikariCP），连接数**不应**随虚拟线程数量同比例放大。由于数据库服务端的并发连接承载力有限，HikariCP 的最大连接数仍需保持在常规合理区间（如 10~50），请求在获取连接时会自动在信号量或连接队列上挂起虚拟线程，不会耗尽载体线程。

---

## 4. 迁移落地检查清单

1. **依赖库兼容性**：检查 JDBC 驱动、加解密类库、网络客户端是否包含老旧的 `synchronized` 阻塞实现。
2. **连接池与限流配置**：明确区分“任务并发数”与“下游连接数”，避免因虚拟线程不受限地发起调用导致下游系统过载。
3. **监控指标**：通过 JFR（Java Flight Recorder）采集 `jdk.VirtualThreadPinned` 事件，评估生产环境中是否存在隐蔽的载体线程阻塞问题。