1. 简介
从Spring Boot 3.2 支持虚拟线程。要使用虚拟线程，需要在 Java 21 上运行，并将属性 spring.threads.virtual.enabled 设置为 true。
启用虚拟线程后，Tomcat 和 Jetty 将使用虚拟线程处理请求。这意味着处理网络请求的应用程序代码（如控制器中的方法）将在虚拟线程上运行。
启用虚拟线程后，applicationTaskExecutor Bean 将成为配置为使用虚拟线程的 SimpleAsyncTaskExecutor。任何使用应用程序任务执行器的地方，如调用 @Async 方法时的 @EnableAsync、Spring MVC 的异步请求处理和 Spring WebFlux 的阻塞执行支持，现在都将使用虚拟线程。
接下来将分别通过传统阻塞Servlet技术、使用虚拟线程及使用反应式技术WebFlux来分别对比它们的性能。
2. 性能对比
使用虚拟线程 & 传统Servlet都使用下面的接口：
@RestController
@RequestMapping("/task/default")
public class TaskDefaultController {
@GetMapping("")
public Object index() throws Exception {
System.out.printf("before - %s%n", Thread.currentThread()) ;
TimeUnit.MILLISECONDS.sleep(100) ;
System.out.printf("after - %s%n", Thread.currentThread()) ;
return "task - default..." ;
}
}先测试下启用虚拟线程执行情况。
配置：
spring:
threads:
virtual:
enabled: true控制台输出：
before - VirtualThread[#42,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1
after - VirtualThread[#42,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1使用的是虚拟线程。
2.1 传统Tomcat线程池方式
配置线程池，如果不配置使用默认的最大线程200，整体的吞吐量将在2200作用。
server:
tomcat:
threads:
min-spare: 500
max: 1000初始启动服务后，内存，CPU占用情况；默认启动后线程个数与上面配置一致。
图片
使用jmeter测试，配置如下：
图片
使用500个线程，循环200次，整体做100000次压测。后续的测试都会基于该配置进行。
图片
吞吐量为：4696
内存，CPU占用情况
图片
2.2 使用虚拟线程
首先开启虚拟线程
spring:
threads:
virtual:
enabled: true初始启动服务后，内存，CPU占用情况
图片
jmeter测试情况如下：
图片
吞吐量为：4677，与上面的阻塞Servlet基本差不多。但传统Tomcat线程池方式需要更多的线程才能达到这一值。
图片
整个过程内存使用情况，虚拟线程要比传统Tomcat线程池方式占用的多。
JDK 的虚拟线程调度器是一个工作偷取 ForkJoinPool，以先进先出(FIFO)模式运行。调度器的并行性是指可用来调度虚拟线程的平台线程数。默认情况下，它等于可用处理器的数量，但可以通过系统属性 jdk.virtualThreadScheduler.parallelism 进行调整。ForkJoinPool 与普通池不同，普通池用于并行流的实现，并以后进先出模式运行。
调整数量再进行测试，设置JVM参数
-Djdk.virtualThreadScheduler.parallelism=100 -Djdk.virtualThreadScheduler.maxPoolSize=100设置100个平台线程来调用虚拟线程。
启动服务后，线程，内存使用情况。
图片
jmeter测试结果如下：
图片
与调整前没什么区别，反而是增加了应用的线程数量。
2.3 反应式WebFlux
引入依赖
org.springframework.boot
spring-boot-starter-webflux
基于webflux，我们需要重新编写接口测试。
@RestController
@RequestMapping("/task/reactor")
public class ReactorController {
@GetMapping("")
public Object index() throws Exception {
// 与上面2种方式不同，reactor方式则需要使用delayElement方式来模拟耗时任务
return Mono.just("task - reactor...").delayElement(Duration.ofMillis(100)) ;
}
}初始启动服务后，内存，CPU占用情况。
图片
jmeter测试情况如下：
图片
吞吐量为：4659，与上面的测试结果基本一致。
图片
内存使用情况要比前面几种方式占用都少。同时通过jmeter测试结果也能发现，MAX请求的最大响应时间webflux是最小的，Std.Dev：所有请求响应时间的标准差也是最小的（该值越小，平均值越可靠）。
根据测试结果，虚拟线程与webflux谁更胜一筹还不够清晰，接下来我们结合数据库操作进行测试。
3. 基于数据库测试
数据库数据准备了600w的数据。
图片
3.1 传统Tomcat线程池方式
基于JPA进行数据库的操作
@Entity
@Table(name = "t_user")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer uid ;
private String name ;
}Repository接口
public interface UserRepository extends JpaRepository {
} Controller测试接口
@RestController
@RequestMapping("/users")
public class UserController {
@Resource
private UserRepository ur ;
@GetMapping("/count")
public User count() {
return ur.findById(5800000).orElse(null) ;
}
}测试结果：
图片
3.2 使用虚拟线程
记得开启虚拟线程，测试结果如下：
图片
3.3 反应式WebFlux
需要引入如下依赖
org.springframework.boot
spring-boot-starter-data-r2dbc
com.github.jasync-sql
jasync-r2dbc-mysql
2.1.24
配置
spring:
r2dbc:
url: r2dbc:mysql://localhost:3306/batch?serverZnotallow=GMT%2B8&sslMode=DISABLED
username: root
password: xxxooo
pool:
initialSize: 100
maxSize: 100
max-acquire-time: 30s
max-idle-time: 30m实体定义，这里的注解与jpa不一样
@Table("t_user")
public class User {
@Id
private Integer uid ;
private String name ;
}Repository定义
public interface UserR2DBCRepository extends ReactiveCrudRepository {
} Controller接口
@RestController
@RequestMapping("/r2dbc")
public class UserR2DBCController {
@Resource
private UserR2DBCRepository ur ;
@GetMapping("/users")
public Mono count() {
return ur.findById(5800000) ;
}
} 测试结果
图片
根据测试结果来，webflux的整体性能远远高于虚拟线程及传统tomcat线程池的方式。
以上是本篇文章全部内容，希望对你有帮助。
完毕！！！
