榨干 JDK 21 性能：Spring Boot 虚拟线程落地实践与压测避坑指南

2026/6/23 03:10:00 2 0 0 0

随着 JDK 21 正式转正虚拟线程（Virtual Threads，即 Project Loom），Java 开发者终于迎来了梦寐以求的“高并发福音”。传统的 Java Web 容器（如 Tomcat）采用的是 Thread-per-request（一个请求一个物理线程）模型，面对动辄成千上万的并发连接，物理线程的上下文切换开销和内存占用会迅速吃光服务器资源。

为了解决这个问题，曾经流行过以 WebFlux、RxJava 为代表的响应式编程。但响应式编程那反人类的“套娃”式代码、极难调试的 Stack Trace，让绝大多数业务开发望而却步。

虚拟线程的出现，彻底打破了这一僵局。它让我们能用最简单的同步阻塞代码，跑出异步非阻塞的超高性能。

本文将实战演示如何在 Spring Boot 3.x 中落地 JDK 21 虚拟线程，深度剖析在真实业务场景中可能遭遇的“三大深水暗礁”，并给出详实的性能压测对比。

一、 Spring Boot 3.2+ 开启虚拟线程的正确姿势

在 Spring Boot 3.2 及以上版本中，开启虚拟线程极其简单，只需要在 application.properties 中加入一行配置：

spring.threads.virtual.enabled=true

当这行配置生效后，Spring Boot 会在底层做一系列自动装配：

Tomcat/Undertow 容器：将不再使用传统的固定大小线程池，而是改用 Executors.newVirtualThreadPerTaskExecutor()，为每个 HTTP 请求分配一个独立的虚拟线程。
TaskExecutor：Spring 内部的 @Async 异步任务执行器也会自动切换为虚拟线程执行器。
TaskScheduler：定时任务也将运行在虚拟线程之上。

验证虚拟线程是否生效

我们可以写一个简单的 Controller 来打印当前的线程信息：

@RestController
@RequestMapping("/thread")
public class ThreadController {

    @GetMapping("/info")
    public String getThreadInfo() {
        Thread thread = Thread.currentThread();
        return "Thread Name: " + thread.toString() + " | Is Virtual: " + thread.isVirtual();
    }
}

启动服务并访问该接口，输出结果如下：

Thread Name: VirtualThread[#27,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1 | Is Virtual: true

可以看到，当前执行线程已经变成了 VirtualThread，而它正承载于底层的 JDK 平台线程（Carrier Thread） ForkJoinPool-1-worker-1 之上。

二、虚拟线程落地的“三大深水暗礁”

如果以为只要配上 spring.threads.virtual.enabled=true 就能高枕无忧，那生产环境的大规模宕机可能就在不远处等着你。虚拟线程虽然轻量（一个虚拟线程仅占几百字节到几 KB 内存），但它的底层调度逻辑和传统线程有本质区别。

暗礁一：Carrier Thread Pinning（载体线程钉死）

虚拟线程是运行在物理平台线程（Carrier Thread）之上的。当虚拟线程遇到阻塞操作（如网络 I/O、Thread.sleep）时，它会自动“让出”物理线程，让其他虚拟线程上去运行。

但是，在以下两种情况下，虚拟线程无法让出物理线程，这种现象被称为 Pinning（钉死）：

在 synchronized 块或 synchronized 方法内部。
调用了本地方法（Native Method）。

一旦虚拟线程在 synchronized 中被钉死，且此时正在进行耗时的 I/O 操作，底层的物理线程就会被一直占用。如果所有的物理线程都被钉死，整个 JVM 的虚拟线程调度就会陷入瘫痪，表现为吞吐量雪崩。

【避坑指南】

排查排查再排查：在 JVM 启动参数中加入以下配置，一旦发生 Pinning，控制台会打印出详细的堆栈轨迹：
```
-Djdk.tracePinnedThreads=full
```
替换为 ReentrantLock：检查第三方依赖或自研代码，将传统的 synchronized 锁替换为 java.util.concurrent.locks.ReentrantLock。虚拟线程在遇到 ReentrantLock 阻塞时，能够顺利让出底层的 Carrier Thread。

// ❌ 错误做法：会导致 Pinning
public synchronized String fetchData() {
    return restTemplate.getForObject("https://api.example.com", String.class);
}

//  正确做法：支持虚拟线程自动挂起
private final ReentrantLock lock = new ReentrantLock();
public String fetchData() {
    lock.lock();
    try {
        return restTemplate.getForObject("https://api.example.com", String.class);
    } finally {
        lock.unlock();
    }
}

暗礁二：数据库连接池（HikariCP）的“瞬间饱水”与死锁

在传统线程模型中，Tomcat 默认最大线程数是 200。这意味着最多只有 200 个并发请求会同时向数据库获取连接。此时，HikariCP 连接池大小设为 50-100 是非常安全的。

但是在虚拟线程模型下，瞬时并发请求可能达到 10000 个。这 10000 个虚拟线程会同时去向 HikariCP 申请连接。

这就导致两个严重后果：

连接池瞬间枯竭：大量虚拟线程在等待连接，导致 HTTP 请求大面积超时。
死锁风险：如果业务代码中存在嵌套事务，或者在同一个请求中多次获取连接，极易发生“线程 A 拿着连接 Wait 线程 B，而线程 B 正在等连接”的死锁惨剧。

【避坑指南】

不要盲目调大数据库连接池，数据库本身的承载能力是有上限的。

限流防洪：使用 Semaphore（信号量）或者专用的限流器（如 Resilience4j），在进入数据库访问前进行并发控制，将并发访问 DB 的虚拟线程数限制在合理范围内。
异步降级：对于非核心查询，引入 Redis 等缓存层，避免请求直达 DB。

// 使用 Semaphore 控制数据库访问并发度
private final Semaphore dbSemaphore = new Semaphore(100);

public User getUser(Long id) {
    try {
        dbSemaphore.acquire();
        return userRepository.findById(id).orElse(null);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException(e);
    } finally {
        dbSemaphore.release();
    }
}

暗礁三：ThreadLocal 的滥用与内存泄漏

很多老旧框架和中间件喜欢用 ThreadLocal 来传递上下文（如 UserInfo、TraceId、LogContext）。在传统线程池中，线程是复用的，ThreadLocal 的总量是可控的（比如几百个）。

但在虚拟线程时代，一秒钟可能会创建并销毁几十万个虚拟线程。如果这些虚拟线程的 ThreadLocal 中挂载了大对象（例如大而复杂的 JSON 解析上下文，或者大报文字符串），而代码又没有显式调用 remove()，哪怕虚拟线程生命周期很短，在 GC 来不及回收的间隙，堆内存也会瞬间被撑爆，直接触发 OOM。

【避坑指南】

即用即走，显式清除：确保在 try-finally 块中调用 ThreadLocal.remove()。
拥抱 JDK 21 预览特性 ScopedValue：JDK 21 引入了 ScopedValue，它比 ThreadLocal 更安全、更轻量，生命周期与代码块绑定，一旦离开作用域自动释放，无法被篡改，非常适合在虚拟线程间传递只读上下文。

三、真实场景下的性能压测与对比

为了验证虚拟线程的真实威力，我们搭建了一个典型的 I/O 密集型业务场景。

1. 压测环境准备

系统配置：4核/8G 内存，Linux CentOS 7
JDK 版本：GraalVM JDK 21
Spring Boot 版本：3.2.5
压测工具：wrk
模拟业务：Controller 收到请求后，调用一个模拟下游慢服务的接口（使用 Thread.sleep(150) 模拟 150ms 的网络 I/O 延迟），随后返回。

2. 测试场景设置

我们对比两组配置：

对照组（Platform Threads）：传统 Tomcat 线程池模式，最大线程数设为默认的 200。
实验组（Virtual Threads）：开启 spring.threads.virtual.enabled=true。

3. 执行压测命令

使用 wrk 模拟高并发，设置 1000 个并发连接，持续时间 30 秒：

wrk -t12 -c1000 -d30s http://127.0.0.1:8080/benchmark/slow-io

4. 压测数据对比

指标	对照组 (平台线程 - Tomcat 200)	实验组 (虚拟线程 - Loom)	性能提升幅度
每秒吞吐量 (QPS)	1,280	6,120	+ 378%
平均延迟 (Latency)	782 ms	162 ms	- 79%
P99 延迟	1,120 ms	180 ms	- 83%
CPU 使用率 (平均)	85% (高频上下文切换)	42% (计算资源利用更纯粹)	系统负载大幅降低

5. 压测结果深度分析

为什么虚拟线程能取得近 4 倍的吞吐量提升？

在平台线程下：当并发连接数（1000）远大于 Tomcat 最大线程数（200）时，多余的 800 个连接只能在 Tomcat 的 Accept 队列中排队等待。这直接导致了平均延迟（782ms）远大于实际的业务处理时间（150ms）。同时，CPU 花费了大量时间在 200 个线程的上下文切换上。
在虚拟线程下：1000 个连接进来，Spring Boot 瞬间拉起 1000 个虚拟线程进行处理。这 1000 个虚拟线程在遇到 150ms 的 I/O 阻塞时，主动交出底层的 4 个 Carrier 线程，由底层 ForkJoinPool 调度其他不阻塞的虚拟线程运行。这使得 CPU 几乎没有无效的上下文切换开销，每个请求都能在完成 I/O 后第一时间被响应，平均延迟降至 162ms（非常接近 150ms 的物理极限值）。

注意：虚拟线程不能提升 CPU 密集型任务（如大数计算、加解密、视频转码）的性能。如果任务全是纯 CPU 计算，使用虚拟线程反而会因为多了一层调度而导致性能轻微下降。

四、生产环境落地 CheckList

在准备将 Spring Boot 项目升级到 JDK 21 并开启虚拟线程前，请对照以下 Checklist 进行逐一确认：

基础环境：Spring Boot 版本是否 $\ge$ 3.2，JDK 版本是否 $\ge$ 21。
死锁排查：全局搜索代码中是否存在 synchronized 关键字，尤其是包裹了 HTTP 请求、RPC 调用、数据库操作等 I/O 行为的块。如有，全部重构为 ReentrantLock。
依赖兼容：重点排查持久层框架（MyBatis、Hibernate）、日志框架（Logback）、Redis 客户端（Jedis / Lettuce）是否已升级到兼容 JDK 21 虚拟线程的最新版本。
连接池调优：是否为数据库连接池（HikariCP）和 HTTP 客户端连接池配置了合理的 Semaphore 限流，防止瞬间压垮下游。
JVM 监控：监控指标中是否加入了 Platform Threads 和 Virtual Threads 的计数器监控，以便及时发现线程泄漏。

五、总结

JDK 21 虚拟线程的落地，是 Java 生态十年来最重要的一次底层变革。它用极低的改造门槛，为 I/O 密集型高并发业务提供了近乎免费的性能红利。

但在享受红利的同时，我们也必须敬畏底层调度的改变。告别 synchronized、严防 ThreadLocal、做好下游连接池的并发限流，才是虚拟线程在生产环境安全、稳定落地的王道。

架构师老路 Java 21 虚拟线程

榨干 JDK 21 性能：Spring Boot 虚拟线程落地实践与压测避坑指南

一、 Spring Boot 3.2+ 开启虚拟线程的正确姿势

验证虚拟线程是否生效

二、 虚拟线程落地的“三大深水暗礁”

暗礁一：Carrier Thread Pinning（载体线程钉死）

【避坑指南】

暗礁二：数据库连接池（HikariCP）的“瞬间饱水”与死锁

【避坑指南】

暗礁三：ThreadLocal 的滥用与内存泄漏

【避坑指南】

三、 真实场景下的性能压测与对比

1. 压测环境准备

2. 测试场景设置

3. 执行压测命令

4. 压测数据对比

5. 压测结果深度分析

四、 生产环境落地 CheckList

五、 总结

评论点评

二、虚拟线程落地的“三大深水暗礁”

三、真实场景下的性能压测与对比

四、生产环境落地 CheckList

五、总结