本文比较了 Spring Boot 应用程序中的不同请求处理方法：ThreadPool、WebFlux、协程和虚拟线程 (Project Loom)。
在本文中，我们将简要描述并粗略比较可在 Spring Boot 应用程序中使用的各种请求处理方法的性能。
高效的请求处理在开发高性能后端应用程序中起着至关重要的作用。传统上，大多数开发人员使用 Spring Boot 应用程序中嵌入的 Tomcat，其默认线程池用于在后台处理请求。然而，替代方法近年来越来越受欢迎。WebFlux 利用事件循环进行响应式请求处理，而 Kotlin 协程及其suspend功能也越来越受到青睐。
此外，引入虚拟线程的 Project Loom 预计将在 Java 21 中发布。不过，尽管 Java 21 尚未发布，但从 Java 19 开始我们就已经可以尝试 Project Loom 了。因此，在本文中，我们还将探索使用虚拟线程来处理请求。
此外，我们将使用JMeter 进行高负载测试的不同请求处理方法进行性能比较。
性能测试模型
我们将使用以下模型来比较请求处理方法：
流程就像蛋糕一样简单：
- 客户端（JMeter）将并行发送 500 个请求。每个线程将等待响应，然后重复发送另一个请求。请求超时时间为 10 秒。测试时间将持续1分钟。
- 我们正在测试的 Spring Boot 应用程序将接收来自客户端的请求并等待来自慢速服务器的响应。
- 慢速服务器以随机超时响应。最大响应时间为 4 秒。平均响应时间为2秒。
处理的请求越多，性能结果就越好。
1. 线程池
默认情况下，Tomcat 使用线程池（有时称为连接池）来处理请求。
概念很简单：当请求到达 Tomcat 时，它会从线程池中分配一个线程来处理该请求。该分配的线程将保持阻塞状态，直到生成响应并将其发送回客户端。
默认情况下，线程池最多包含 200 个线程。这基本上意味着单个时间点只能处理 200 个请求。
但这个参数和其他参数是可配置的。
默认线程池
让我们对一个带有嵌入式 Tomcat 和默认线程池的简单 Spring Boot 应用程序进行性能测量。
线程池容纳 200 个线程。对于每个请求，服务器都会对另一台服务器进行阻塞调用，平均响应时间为两秒。因此我们可以预计每秒 100 个请求的吞吐量。
|
请求总数
|
吞吐量，请求/秒
|
响应时间，毫秒
|
错误率，%
|
|||
|
平均的
|
最小
|
90%线
|
最大限度
|
|||
|
3356
|
91.2
|
4787
|
155
|
6645
|
7304
|
0.00
|
值得注意的是，实际结果非常接近，测得的吞吐量为每秒 91.2 个请求。
增加线程池
让我们使用应用程序属性将线程池中的最大线程数增加到 400：
server:
tomcat:
threads:
max: 400让我们再次运行测试：
| 请求总数 | 吞吐量，请求/秒 | 响应时间，毫秒 | 错误率，% | |||
| 平均的 | 最小 | 90%线 | 最大限度 | |||
| 6078 | 176.7 | 2549 | 10 | 4184 | 4855 | 0.00 |
预计线程池中的线程数量加倍将使吞吐量提高两倍。
但请注意，在不考虑系统容量和资源限制的情况下增加线程池中的线程数量可能会对性能、稳定性和整体系统行为产生不利影响。根据系统的具体要求和功能仔细调整和优化线程池大小至关重要。
2.WebFlux
WebFlux 没有为每个请求分配专用线程，而是采用具有少量线程的事件循环模型，通常称为事件循环组。这使得它能够用有限数量的线程处理大量并发请求。请求是异步处理的，事件循环可以利用非阻塞 I/O 操作有效地同时处理多个请求。WebFlux非常适合需要高可扩展性的场景，例如处理大量长连接或流数据。
理想情况下，WebFlux 应用程序应该完全以响应式方式编写；有时，这并不那么容易。但我们有一个简单的应用程序，我们可以只使用WebClient 来调用慢速服务器。
@Bean
public WebClient slowServerClient() {
return WebClient.builder()
.baseUrl("http://127.0.0.1:8000")
.build();
}在 Spring WebFlux 的上下文中， RouterFunction 是请求映射和处理的另一种方法：
@Bean
public RouterFunction<ServerResponse> routes(WebClient slowServerClient) {
return route(GET("/"), (ServerRequest req) -> ok()
.body(slowServerClient
.get()
.exchangeToFlux(resp -> resp.bodyToFlux(Object.class)),
Object.class
));
}但仍然可以使用传统控制器。
那么，让我们运行测试：
| 请求总数 | 吞吐量，请求/秒 | 响应时间，毫秒 | 错误率，% | |||
| 平均的 | 最小 | 90%线 | 最大限度 | |||
| 7443 | 219.2 | 2068 | 12 | 3699 | 4381 | 0.00 |
结果甚至比增加线程池的情况更好。但需要注意的是，线程池和 WebFlux 都有各自的优点和缺点，选择取决于具体要求、工作负载的性质以及开发团队的专业知识。
3. 协程和WebFlux
Kotlin协程 可以有效地用于请求处理，以更加并发和非阻塞的方式提供替代方法。
Spring WebFlux支持 协程来处理请求，所以让我们尝试编写这样一个控制器：
@GetMapping
suspend fun callSlowServer(): Flow<Any> {
return slowServerClient.get().awaitExchange().bodyToFlow(String::class)
}挂起函数可以执行长时间运行或阻塞操作，而不会阻塞底层线程。Kotlin 协程基础知识文章很好地描述了基础知识。
那么，让我们再次运行测试：
| 请求总数 | 吞吐量，请求/秒 | 响应时间，毫秒 | 错误率，% | |||
| 平均的 | 最小 | 90%线 | 最大限度 | |||
| 7481 | 220.4 | 2064 | 5 | 3615 | 4049 | 0.00 |
粗略地，我们可以得出这样的结论：结果与没有协程的 WebFlux 应用程序的情况没有什么不同。
但除了协程之外，还使用了相同的WebFlux，测试可能并没有完全揭示出协程的潜力。下次，值得尝试Ktor。
4. 虚拟线程（Project Loom）
虚拟线程或纤维是Project Loom引入的概念。
与本机线程相比，虚拟线程的内存占用量显着降低，允许应用程序创建和管理更多数量的线程，而不会耗尽系统资源。它们可以更快地创建和切换，从而减少与线程创建相关的开销。
虚拟线程执行的切换由 Java 虚拟机 (JVM) 内部处理，可以在以下位置完成：
自愿挂起：虚拟线程可以使用Thread.sleep()或等方法显式挂起其执行CompletableFuture.await()。当虚拟线程自行挂起时，执行会暂时暂停，JVM 可以切换到执行另一个虚拟线程。
阻塞操作：当虚拟线程遇到阻塞操作，例如等待I/O或获取锁时，可以自动挂起。这允许 JVM 通过使用底层本机线程执行其他准备运行的虚拟线程来更有效地利用它们。
如果您对虚拟线程和载体线程主题感兴趣，请阅读 DZone 上这篇精彩的文章 — Java 虚拟线程 — 简单介绍。
虚拟线程最终将在 Java 21 中发布，但从 Java 19 开始我们就已经可以测试它们了。我们只需要显式指定 JVM 选项即可。
基本上，我们要做的就是用一些基于虚拟线程的执行器替换 Tomcat 线程池：
@Bean
public TomcatProtocolHandlerCustomizer<?> protocolHandler() {
return protocolHandler ->
protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
}因此，我们开始使用虚拟线程，而不是线程池执行器。
让我们运行测试：
| 请求总数 | 吞吐量，请求/秒 | 响应时间，毫秒 | 错误率，% | |||
| 平均的 | 最小 | 90%线 | 最大限度 | |||
| 7427 | 219.3 | 2080 | 12 | 3693 | 4074 | 0.00 |
结果实际上与 WebFlux 的情况相同，但我们根本没有使用任何反应式技术。即使对于慢速服务器的调用，也使用常规阻塞 RestTemplate。我们所做的就是用虚拟线程执行器替换线程池。
结论
让我们将测试结果收集到一张表中：
| 请求处理程序 | 30 秒内的请求总数 |
吞吐量，请求/秒 | 响应时间，毫秒 | 错误率，% | |||
| 平均的 | 最小 | 90%线 | 最大限度 | ||||
| 线程池（200 个线程） | 3356 | 91.2 | 4787 | 155 | 6645 | 7304 | 0.00 |
| 增加线程池（400 个线程） | 6078 | 176.7 | 2549 | 10 | 4184 | 4855 | 0.00 |
| WebFlux | 7443 | 219.2 | 2068 | 12 | 36999 | 4381 | 0.00 |
| WebFlux + 协程 | 7481 | 220.4 | 2064 | 5 | 3615 | 4049 | 0.00 |
| 虚拟线程（Project Loom） | 7427 | 219.3 | 2080 | 12 | 3693 | 4074 | 0.00 |
本文进行的性能测试比较肤浅，但我们可以得出一些初步结论：
- 线程池表现出较差的性能结果。增加线程数量可能会带来改进，但应考虑系统的容量和资源限制。尽管如此，线程池仍然是一个可行的选择，特别是在处理大量阻塞操作时。
- WebFlux 展示了非常好的结果。但值得注意的是，要充分受益于其性能。整个代码应该以响应式风格编写。
- 将协程与 WebFlux 结合使用会产生类似的性能结果。也许我们必须使用 Ktor 来尝试它们，Ktor 是一个专门为利用协程的力量而设计的框架。
- 使用虚拟线程（Project Loom）也产生了类似的结果。然而，值得注意的是，我们没有修改代码或采用任何反应技术。唯一的改变是用虚拟线程执行器替换线程池。尽管很简单，但与使用线程池相比，性能结果显着提高。
因此，我们可以初步得出结论，Java 21中虚拟线程的发布将显着改变现有服务器和框架中请求处理的方法。