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

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

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

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

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

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

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

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

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

測試環(huán)境

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

軟件版本為：

Java v21.0.1

Spring Boot 3.2.1

程序配置

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

application.properties文件如下：

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

使用虛擬線程時，我們將通過添加以下行來啟用它們：

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

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

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

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

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

應(yīng)用場景

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

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

結(jié)果評估

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

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

測試結(jié)果

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

總結(jié)

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

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

審核編輯：湯梓紅