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

虛擬線程：利用 Project Loom 的虛擬線程釋放可擴展性，從而減少資源消耗并增強并發性。

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

JVM 檢查點：利用 CRaC 項目的 JVM 檢查點機制實現應用程序的快速重啟，無需冗長的重新初始化。

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

Spring for Apache Pulsar：利用 Apache Pulsar 的強大功能實現強大的消息傳遞功能，無縫集成到您的 Spring Boot 應用程序中。

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

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

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

測試環境

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

軟件版本為：

Java v21.0.1

Spring Boot 3.2.1

程序配置

除了主 Java 類之外，不需要編寫任何 Java 文件，靜態文件服務器只能通過配置就能發揮作用。

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內容：

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

測試數據

大小完全相同但數據不同的 100K 文件被放置在靜態資源目錄中。每個文件大小正好是 102400 字節。

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

使用 Bombardier 的修改版本，為每次運行生成隨機請求 URL: http://localhost:3000/static/

應用場景

為了確保結果一致，每個測試在開始數據收集之前都會經歷 5K 請求預熱階段。

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

結果評估

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

CPU 和內存的資源使用情況監控將補充此分析，從而提供不同工作負載下系統性能的全面了解。

測試結果

結果以圖表形式呈現如下：

總結

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

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

審核編輯：湯梓紅