在 Spring 6 中使用虚拟线程
一、简介
在这个简短的教程中，我们将了解如何在 Spring Boot 应用程序中利用虚拟线程的强大功能。
虚拟线程是Java 19 的预览功能，这意味着它们将在未来 12 个月内包含在官方 JDK 版本中。Spring 6 版本最初由 Project Loom 引入，为开发人员提供了开始尝试这一出色功能的选项。
首先，我们将看到“平台线程”和“虚拟线程”之间的主要区别。接下来，我们将使用虚拟线程从头开始构建一个 Spring-Boot 应用程序。最后，我们将创建一个小型测试套件，以查看简单 Web 应用程序吞吐量的最终改进。
二、 虚拟线程与平台线程
主要区别在于虚拟线程在其操作周期中不依赖于操作系统线程：它们与硬件解耦，因此有了“虚拟”这个词。这种解耦是由 JVM 提供的抽象层实现的。
对于本教程来说，必须了解虚拟线程的运行成本远低于平台线程。它们消耗的分配内存量要少得多。这就是为什么可以创建数百万个虚拟线程而不会出现内存不足问题，而不是使用标准平台（或内核）线程创建几百个虚拟线程。
从理论上讲，这赋予了开发人员一种超能力：无需依赖异步代码即可管理高度可扩展的应用程序。
三、在Spring 6中使用虚拟线程
从 Spring Framework 6（和 Spring Boot 3）开始，虚拟线程功能正式公开，但虚拟线程是Java 19 的预览功能。这意味着我们需要告诉 JVM 我们要在应用程序中启用它们。由于我们使用 Maven 来构建应用程序，因此我们希望确保在 pom.xml 中包含以下代码：
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>19</source>
<target>19</target>
<compilerArgs>
--enable-preview
</compilerArgs>
</configuration>
</plugin>
</plugins>
</build>
从 Java 的角度来看，要使用 Apache Tomcat 和虚拟线程，我们需要一个带有几个 bean 的简单配置类：
@EnableAsync
@Configuration
@ConditionalOnProperty(
value = "spring.thread-executor",
havingValue = "virtual"
)
public class ThreadConfig {
@Bean
public AsyncTaskExecutor applicationTaskExecutor() {
return new TaskExecutorAdapter(Executors.newVirtualThreadPerTaskExecutor());
}
@Bean
public TomcatProtocolHandlerCustomizer<?> protocolHandlerVirtualThreadExecutorCustomizer() {
return protocolHandler -> {
protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
};
}
}
第一个 Spring Bean ApplicationTaskExecutor将取代标准的*ApplicationTaskExecutor* ，提供为每个任务启动新虚拟线程的Executor。第二个 bean，名为ProtocolHandlerVirtualThreadExecutorCustomizer，将以相同的方式 自定义标准TomcatProtocolHandler 。我们还添加了注释@ConditionalOnProperty，**以通过切换application.yaml文件中配置属性的值来按需启用虚拟线程：
spring:
thread-executor: virtual
//...
我们来测试一下Spring Boot应用程序是否使用虚拟线程来处理Web请求调用。为此，我们需要构建一个简单的控制器来返回所需的信息：
@RestController
@RequestMapping("/thread")
public class ThreadController {
@GetMapping("/name")
public String getThreadName() {
return Thread.currentThread().toString();
}
}
*Thread*对象的toString *()*方法将返回我们需要的所有信息：线程 ID、线程名称、线程组和优先级。让我们通过一个curl请求来访问这个端点：
$ curl -s http://localhost:8080/thread/name
$ VirtualThread[#171]/runnable@ForkJoinPool-1-worker-4
正如我们所看到的，响应明确表示我们正在使用虚拟线程来处理此 Web 请求。换句话说，*Thread.currentThread()*调用返回虚拟线程类的实例。现在让我们通过简单但有效的负载测试来看看虚拟线程的有效性。
四、性能比较
对于此负载测试，我们将使用JMeter。这不是虚拟线程和标准线程之间的完整性能比较，而是我们可以使用不同参数构建其他测试的起点。
在这种特殊的场景中，我们将调用Rest Controller中的一个端点，该端点将简单地让执行休眠一秒钟，模拟复杂的异步任务：
@RestController
@RequestMapping("/load")
public class LoadTestController {
private static final Logger LOG = LoggerFactory.getLogger(LoadTestController.class);
@GetMapping
public void doSomething() throws InterruptedException {
LOG.info("hey, I'm doing something");
Thread.sleep(1000);
}
}
请记住，由于*@ConditionalOnProperty* 注释，我们只需更改 application.yaml 中变量的值即可在虚拟线程和标准线程之间切换。
JMeter 测试将仅包含一个线程组，模拟 1000 个并发用户访问*/load* 端点 100 秒：
在本例中，采用这一新功能所带来的性能提升是显而易见的。让我们比较不同实现的“响应时间图”。这是标准线程的响应图。我们可以看到，立即完成一次调用所需的时间达到 5000 毫秒：
发生这种情况是因为平台线程是一种有限的资源，当所有计划的和池化的线程都忙时，Spring 应用程序除了将请求搁置直到一个线程空闲之外别无选择。
让我们看看虚拟线程会发生什么：
正如我们所看到的，响应稳定在 1000 毫秒。虚拟线程在请求后立即创建和使用，因为从资源的角度来看它们非常便宜。在本例中，我们正在比较 spring 默认固定标准线程池（默认为 200）和 spring 默认无界虚拟线程池的使用情况。
**这种性能提升之所以可能，是因为场景过于简单，并且没有考虑 Spring Boot 应用程序可以执行的全部操作。**从底层操作系统基础设施中采用这种抽象可能是有好处的，但并非在所有情况下都是如此。