Spring Boot 3.2 于 2023 年 11 月大張旗鼓地發(fā)布，標(biāo)志著 Java 開發(fā)領(lǐng)域的一個(gè)關(guān)鍵時(shí)刻。這一突破性的版本引入了一系列革命性的功能，包括：

虛擬線程：利用 Project Loom 的虛擬線程釋放可擴(kuò)展性，從而減少資源消耗并增強(qiáng)并發(fā)性。

Native Image支持：通過(guò)Native Image編譯制作速度極快的應(yīng)用程序，減少啟動(dòng)時(shí)間并優(yōu)化資源利用率。

JVM 檢查點(diǎn)：利用 CRaC 項(xiàng)目的 JVM 檢查點(diǎn)機(jī)制實(shí)現(xiàn)應(yīng)用程序的快速重啟，無(wú)需冗長(zhǎng)的重新初始化。

RestClient：采用新的 RestClient 接口的功能方法，簡(jiǎn)化 HTTP 交互并簡(jiǎn)化代碼。

Spring for Apache Pulsar：利用 Apache Pulsar 的強(qiáng)大功能實(shí)現(xiàn)強(qiáng)大的消息傳遞功能，無(wú)縫集成到您的 Spring Boot 應(yīng)用程序中。

其中，虛擬線程是最近 Java 版本中引入的最具變革性的特性之一。正如官方文件所述：虛擬線程是輕量級(jí)線程，可減少編寫、維護(hù)和調(diào)試高吞吐量并發(fā)應(yīng)用程序的工作量。線程是可以調(diào)度的最小處理單元。它與其他此類單位同時(shí)運(yùn)行，并且在很大程度上獨(dú)立于其他此類單元運(yùn)行。它是 java.lang.Thread 的一個(gè)實(shí)例。有兩種線程：平臺(tái)線程和虛擬線程。平臺(tái)線程是作為操作系統(tǒng) （OS） 線程的瘦包裝器實(shí)現(xiàn)的。平臺(tái)線程在其底層操作系統(tǒng)線程上運(yùn)行 Java 代碼，平臺(tái)線程在平臺(tái)線程的整個(gè)生命周期內(nèi)捕獲其操作系統(tǒng)線程。因此，可用平臺(tái)線程數(shù)限制為操作系統(tǒng)線程數(shù)。與平臺(tái)線程一樣，虛擬線程也是 java.lang.Thread 的實(shí)例。但是，虛擬線程不綁定到特定的操作系統(tǒng)線程。虛擬線程仍在操作系統(tǒng)線程上運(yùn)行代碼。但是，當(dāng)在虛擬線程中運(yùn)行的代碼調(diào)用阻塞 I/O 操作時(shí)，Java 運(yùn)行時(shí)會(huì)掛起虛擬線程，直到它可以恢復(fù)為止。與掛起的虛擬線程關(guān)聯(lián)的操作系統(tǒng)線程現(xiàn)在可以自由地對(duì)其他虛擬線程執(zhí)行操作。虛擬線程適用于運(yùn)行大部分時(shí)間被阻塞的任務(wù)，通常等待 I/O 操作完成。但是，它們不適用于長(zhǎng)時(shí)間運(yùn)行的 CPU 密集型操作。

雖然人們普遍認(rèn)為虛擬線程在 I/O 密集型方案中表現(xiàn)出色，但它們?cè)?CPU 密集型任務(wù)中的性能仍然是一個(gè)問(wèn)號(hào)。本系列文章深入探討了虛擬線程在各種用例中的潛在優(yōu)勢(shì)，從基本的“hello world”到靜態(tài)文件服務(wù)（I/O 密集型）、QR 碼生成（CPU 密集型）和多部分/表單數(shù)據(jù)處理（混合工作負(fù)載）等實(shí)際應(yīng)用。

在本系列的開頭文章中，我們已經(jīng)了解了虛擬線程與物理線程相比在最簡(jiǎn)單（且不切實(shí)際）的 hello world 情況下的性能。物理線程和虛擬線程之間幾乎沒(méi)有任何性能或資源使用差異。在本文中，我們將更加“實(shí)用”，并針對(duì)靜態(tài)文件服務(wù)器情況進(jìn)行比較。這絕對(duì)是一個(gè)常見(jiàn)且“真實(shí)世界”的案例。讓我們看看這次我們發(fā)現(xiàn)了什么。

測(cè)試環(huán)境

所有測(cè)試均在配備 16G RAM、8 個(gè)物理內(nèi)核和 4 個(gè)效率內(nèi)核的 MacBook Pro M2 上執(zhí)行。測(cè)試工具是 Bombardier，它是更快的 HTTP 負(fù)載測(cè)試器之一（用 Go 編寫）。

軟件版本為：

Java v21.0.1

Spring Boot 3.2.1

程序配置

除了主 Java 類之外，不需要編寫任何 Java 文件，靜態(tài)文件服務(wù)器只能通過(guò)配置就能發(fā)揮作用。

application.properties文件如下：

server.port=3000
spring.mvc.static-path-pattern=/static/**
spring.web.resources.static-locations=file:/Users/mayankc/Work/source/perfComparisons/static/

使用虛擬線程時(shí)，我們將通過(guò)添加以下行來(lái)啟用它們：

spring.threads.virtual.enabled=true

pom.xml內(nèi)容：

org.springframework.boot
spring-boot-starter-parent
3.2.1


com.example
demo
0.0.1-SNAPSHOT
demo
DemoprojectforSpringBoot

21



org.springframework.boot
spring-boot-starter-web



org.springframework.boot
spring-boot-starter-test
test

測(cè)試數(shù)據(jù)

大小完全相同但數(shù)據(jù)不同的 100K 文件被放置在靜態(tài)資源目錄中。每個(gè)文件大小正好是 102400 字節(jié)。

文件的命名范圍為 1 到 100000。

使用 Bombardier 的修改版本，為每次運(yùn)行生成隨機(jī)請(qǐng)求 URL: http://localhost:3000/static/

應(yīng)用場(chǎng)景

為了確保結(jié)果一致，每個(gè)測(cè)試在開始數(shù)據(jù)收集之前都會(huì)經(jīng)歷 5K 請(qǐng)求預(yù)熱階段。

然后，在不同范圍的并發(fā)連接級(jí)別（50、100 和 300）中仔細(xì)記錄測(cè)量結(jié)果，每個(gè)級(jí)別都承受 500 萬(wàn)個(gè)請(qǐng)求工作負(fù)載。

結(jié)果評(píng)估

除了簡(jiǎn)單地跟蹤原始速度之外，我們還將采用詳細(xì)的指標(biāo)框架來(lái)捕獲延遲分布（最小值、百分位數(shù)、最大值）和吞吐量（每秒請(qǐng)求數(shù)）。

CPU 和內(nèi)存的資源使用情況監(jiān)控將補(bǔ)充此分析，從而提供不同工作負(fù)載下系統(tǒng)性能的全面了解。

測(cè)試結(jié)果

結(jié)果以圖表形式呈現(xiàn)如下：

總結(jié)

對(duì)靜態(tài)文件服務(wù)的分析表明，物理線程在性能和資源效率方面略勝一籌（與我們的預(yù)期相反）。

不過(guò)，這種受 I/O 限制的場(chǎng)景可能并不是充分發(fā)揮虛擬線程潛力的理想場(chǎng)所。涉及數(shù)據(jù)庫(kù)交互的任務(wù)可能會(huì)顯示出更多令人信服的優(yōu)勢(shì)。也許負(fù)載不足以讓虛擬線程發(fā)揮出最大的作用。為了找出答案，我們將在接下來(lái)的文章中介紹 URL短鏈（數(shù)據(jù)庫(kù)驅(qū)動(dòng)）、二維碼生成（CPU受限）和混合工作負(fù)載場(chǎng)景（如表單數(shù)據(jù)處理），旨在揭示虛擬線程真正出類拔萃的案例。

審核編輯：湯梓紅