：從原理到壓測，告別線程池饑餓)
這個標題看著就讓人手癢。說實話SpringBoot項目里把線程池換成虛擬線程這操作在一年前還是個需要猶豫半天的決定現(xiàn)在回頭看確實是鳥槍換大炮級別的體驗升級。這篇文章我打算用最直接的方式把虛擬線程從原理到SpringBoot落地再到實際壓測數(shù)據(jù)一次講透尤其是那些官網(wǎng)文檔不會告訴你的坑。1. 為什么說虛擬線程是SpringBoot的“鳥槍換炮”先看清平臺線程池的賬本1.1 從一次線上事故說起200個線程被IO堵死的真相先聊一個真實場景。我之前維護過一個典型的SpringBoot單體服務部署在8核16G的機器上Tomcat默認開了200個線程。平時接口響應都在幾十毫秒看上去一切歲月靜好。結(jié)果有一次對接的外部系統(tǒng)抽風一個查詢接口的響應時間從50ms飆到了3秒直接導致整個服務的吞吐量斷崖式下跌。當時排查下來典型的線程池饑餓200個線程全部阻塞在外部接口等待響應上后續(xù)請求排隊排隊再排隊新請求進來直接超時失敗。這個事故讓我對平臺線程模型有了非常痛的領悟——平臺線程和IO阻塞是天然對立的。Java傳統(tǒng)的線程模型里一個平臺線程對應一個內(nèi)核線程線程的創(chuàng)建、切換、銷毀都需要操作系統(tǒng)參與。更關(guān)鍵的是線程一旦進入阻塞狀態(tài)比如等待網(wǎng)絡響應、等待鎖、等待數(shù)據(jù)庫連接它占用的資源就全部浪費了。如果你是8核16G的機器Tomcat開200個線程已經(jīng)是上限附近了你去查線程dump會發(fā)現(xiàn)大量線程停在WAITING或者TIMED_WAITING狀態(tài)根本不是在干活是在干等。那時候我做過一個粗略計算一個平臺線程默認棧內(nèi)存是1MB200個線程就是200MB每個線程在阻塞時仍然占用內(nèi)核調(diào)度資源、占用線程元數(shù)據(jù)而它的CPU使用率可能只有1%。換句話說絕大多數(shù)線程資源花在了“等待”上而不是“計算”上。1.2 “每請求一線程”模式為什么在傳統(tǒng)容器里走不通了SpringBoot的經(jīng)典處理模型是“每請求一個線程”一個HTTP請求進來Tomcat線程池分配一個線程這個線程負責把請求處理完再歸還到線程池。這套模型在Web應用剛興起的年代沒問題因為那時候的請求基本都是短平快查個數(shù)據(jù)庫、拼個響應幾百毫秒就搞定了。但現(xiàn)在的業(yè)務場景早變了。一個普通的線上接口可能要先調(diào)一個鑒權(quán)服務再調(diào)一個訂單服務再查幾次數(shù)據(jù)庫再發(fā)個消息隊列通知。一個請求從進入到返回線程真正執(zhí)行CPU指令的時間可能只有10%剩下90%的時間全部阻塞在RPC調(diào)用、數(shù)據(jù)庫查詢、Redis操作這些IO等待上。按這個比例線程池開200個、300個甚至更多也只是在給“等待”買票讓更多請求排隊進入等待區(qū)而已。所以在虛擬線程之前解決高并發(fā)IO密集場景的經(jīng)典手段是異步化改造CompletableFuture串起來、引入反應式編程WebFlux、或者把同步調(diào)用改成異步消息。每一種方案都有劇烈的代價異步化改造會讓代碼可讀性變得極差業(yè)務日志里全是回調(diào)嵌套WebFlux更是讓絕大多數(shù)習慣了同步編程的團隊直接崩潰。1.3 虛擬線程到底解決了什么問題虛擬線程Project Loom的產(chǎn)物的本質(zhì)是讓Java能夠以極低的成本創(chuàng)建海量的、輕量級的線程對象而且這些線程的調(diào)度由JVM自己管理不依賴操作系統(tǒng)內(nèi)核線程。JDK 21正式發(fā)布了虛擬線程SpringBoot 3.2開始官方支持用虛擬線程替換默認的平臺線程池。用虛擬線程后的效果是什么你可以給Tomcat配置成“每請求一個虛擬線程”而虛擬線程創(chuàng)建成本近乎為零占用內(nèi)存只有幾KB到幾十KB一個8核機器上跑幾十萬個虛擬線程都沒問題。請求進來就開一個虛擬線程處理線程阻塞了就擱在那反正JVM內(nèi)成本極低根本不需要線程池來控制數(shù)量——沒有池化自然沒有池滿。我當時把內(nèi)部服務切到虛擬線程后最直觀的感受是線程池饑餓這個名詞從報警監(jiān)控里徹底消失了。不需要再盯著“activeThreads”這個指標做容量規(guī)劃也不需要為了一個第三方接口的超時抖動去調(diào)線程池參數(shù)。2. 虛擬線程的底層機制不是“更輕量的線程池”是“線程該回歸本質(zhì)了”2.1 用戶態(tài)調(diào)度與內(nèi)核級線程的分工要理解虛擬線程建議先忘掉“線程池”這個概念。虛擬線程和操作系統(tǒng)線程平臺線程是兩種維度的東西平臺線程由操作系統(tǒng)的調(diào)度器管理接受內(nèi)核的調(diào)度虛擬線程是一個純用戶態(tài)的對象由JVM的調(diào)度器Scheduler負責分配給平臺線程執(zhí)行。虛擬線程本身不是一個CPU執(zhí)行實體它更像是“一段可以被掛起和恢復的執(zhí)行狀態(tài)”。當虛擬線程執(zhí)行到阻塞IO比如socket.read()、Thread.sleep()時JVM調(diào)度器會把這個虛擬線程“卸載”下來也就是保存好它的調(diào)用棧和狀態(tài)然后釋放它所占用的平臺線程讓這個平臺線程去執(zhí)行其他虛擬線程。等IO結(jié)果回來了調(diào)度器再把之前保存的棧給恢復找個空閑的平臺線程繼續(xù)跑。這個過程有個很關(guān)鍵的點阻塞IO變成了協(xié)作式調(diào)度。虛擬線程遇到阻塞不會白白占著平臺線程而是主動讓出讓計算資源流轉(zhuǎn)起來。這也是為什么“少開點線程反而吞吐更高”——平臺線程數(shù)量只需要和CPU核心數(shù)匹配負責在虛擬線程之間來回切換執(zhí)行。2.2 一個大佬級別的實驗跑10萬個線程還是10萬個“線程”做個小實驗就能直觀感受虛擬線程的威力。下面這段代碼可以創(chuàng)建一個平臺線程的數(shù)組然后啟動它們每個線程阻塞3秒// 平臺線程版本 ExecutorService executor Executors.newFixedThreadPool(200);換成虛擬線程版本// 虛擬線程版本 try (ExecutorService executor Executors.newVirtualThreadPerTaskExecutor()) { for (int i 0; i 100_000; i) { executor.submit(() - { try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } }平臺線程版本在200個線程時就已經(jīng)氣喘吁吁了線程數(shù)再往上加基本就是內(nèi)存爆炸而虛擬線程版本10萬個任務照樣輕松跑完占用的堆外內(nèi)存非常有限。你可以把這個測試跑一下已經(jīng)不需要看更多解釋這種數(shù)量級的差異會直接說服你。2.3 一個容易混淆的點虛擬線程并不提升計算速度它提升的是吞吐這個要單獨拿出來說因為很多人是帶著“虛擬線程應該讓接口更快”的期待來的。如果你把一個只做純計算的接口換到虛擬線程響應時間不會有任何變化甚至因為調(diào)度器的開銷反而稍微慢一點點。虛擬線程的真實價值是在“線程阻塞調(diào)度開銷”這個維度上省出了大量空間。用一個生活化類比平臺線程池模式像一家餐廳只雇了10個服務員每個服務員負責一桌客人的全套服務點單、上菜、結(jié)賬這桌客人發(fā)呆等菜服務員就只能在旁邊站著等虛擬線程模式像服務員只管把菜單遞給廚師然后立刻去接待下一桌客人菜做好了再回來端給那桌。服務員數(shù)量還是10人但同時間段完成的訂單量翻了10倍以上。這個類比對理解虛擬線程的性能收益非常有幫助。3. SpringBoot里啟用虛擬線程的具體操作官方途徑和手動兜底3.1 硬性條件拆解JDK版本和框架版本一步都不能少先把門檻劃清楚。虛擬線程是JDK 21正式落地的功能此前在JDK 19、20是預覽版強烈不建議在SpringBoot生產(chǎn)環(huán)境用預覽版。SpringBoot這邊3.2版本開始才支持通過配置一鍵啟用虛擬線程3.0和3.1沒有這個能力。如果用SpringBoot 2.x要么升級框架要么就只能手動寫配置類自己定義執(zhí)行器。配置前的檢查清單JDK版本必須21及以上我用的是21 LTS目前線上也跑得很穩(wěn)SpringBoot版本3.23.2.x、3.3.x都可以3.4.x也支持構(gòu)建工具Maven或Gradle你隨意這里無所謂依賴不需要額外引入任何包如果你的SpringBoot版本剛好是3.2以上那真的很幸運官方路線是自己改配置文件就行。如果不是也別慌后面有對應的兜底代碼方案。3.2 官方的一鍵配置SpringBoot 3.2起的配置項大解密SpringBoot 3.2留給開發(fā)者的是一行配置spring.threads.virtual.enabledtrue這里有個細節(jié)要注意這行配置管的是SpringBoot內(nèi)置的TaskExecutor比如Async注解的異步任務執(zhí)行器以及自動裝配的Tomcat容器線程池并不是。官網(wǎng)文檔里這行的準確描述是啟用后SpringBoot會把容器使用的執(zhí)行器切換成虛擬線程執(zhí)行器。放在servlet Web應用里它就是用來替換Tomcat處理請求的線程池的。也就是說加了這行配置后Tomcat對外表現(xiàn)為“每個請求來一個虛擬線程處理”不需要再調(diào)整server.tomcat.threads.max這些參數(shù)了因為線程池概念本質(zhì)上被繞過了。這里建議把server.tomcat.threads.max這類配置從配置文件中刪掉或者注釋掉避免給自己造成它還有效的錯覺。3.3 手動配置ThreadPoolExecutor替換方案的完整代碼如果你用的是SpringBoot 3.1、3.0或者SpringBoot 2.x那就需要自己動手寫一個配置類把默認的執(zhí)行器換成虛擬線程。import org.springframework.boot.web.embedded.tomcat.TomcatProtocolHandlerCustomizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.core.task.support.TaskExecutorAdapter; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; Configuration public class VirtualThreadConfig { Bean public TomcatProtocolHandlerCustomizer? protocolHandlerVirtualThreadExecutorCustomizer() { return protocolHandler - { ExecutorService executorService Executors.newVirtualThreadPerTaskExecutor(); protocolHandler.setExecutor(executorService); }; } }上面的代碼是給SpringBoot內(nèi)置Tomcat用的核心思路是拿到Tomcat的ProtocolHandler然后通過setExecutor把執(zhí)行器替換成虛擬線程執(zhí)行器。Executors.newVirtualThreadPerTaskExecutor()是JDK 21提供的工廠方法語義是“每次任務來一個虛擬線程用完就結(jié)束持續(xù)復用調(diào)度器”。如果你還在用SpringBoot 2.x版本沒有TomcatProtocolHandlerCustomizer這個API怎么辦還有第二套方案直接自己定義容器工廠import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory; import org.springframework.boot.web.server.WebServerFactoryCustomizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; Configuration public class VirtualThreadTomcatConfig { Bean public WebServerFactoryCustomizerTomcatServletWebServerFactory protocolHandlerCustomizer() { return factory - { ExecutorService executor Executors.newVirtualThreadPerTaskExecutor(); factory.addProtocolHandlerCustomizer(handler - handler.setExecutor(executor)); }; } }如果你不是用Tomcat而是Jetty也有對應的方案Jetty的QueuedThreadPool換成虛擬線程執(zhí)行器。不過說實話Java Web容器里Tomcat占了絕大多數(shù)場景我這邊就先按Tomcat來講Jetty的配置思路是類似的。3.4 核心參數(shù)解析為什么用“每任務一個虛擬線程”而不是固定線程池這里有個很重要的設計判斷虛擬線程場景下不要用Executors.newFixedThreadPool(虛擬線程數(shù)量)這種寫法。原因很簡單虛擬線程的優(yōu)勢就是便宜你想限制數(shù)量反而破壞了模型。假設你開了10萬個虛擬線程它們?nèi)烤€程池化了本質(zhì)上還是一個限制容量的池只是池中元素便宜了一點收益遠不如無池化。newVirtualThreadPerTaskExecutor()的核心語義是“任務就是全部”每次提交任務都創(chuàng)建一個新的虛擬線程去執(zhí)行執(zhí)行完銷毀。這不代表每次都創(chuàng)建平臺線程資源——底層調(diào)度器復用平臺線程只是虛擬線程對象本身是輕量的創(chuàng)建銷毀也就幾微秒的量級。我還特意看了Executors.newVirtualThreadPerTaskExecutor()的JDK源碼內(nèi)部本質(zhì)是返回了一個調(diào)度器驅(qū)動下的執(zhí)行器任務進來創(chuàng)建的是虛擬線程對象虛擬線程對象由JVM內(nèi)部的一個ForkJoinPool調(diào)度到平臺線程上執(zhí)行平臺線程數(shù)量默認等于CPU核心數(shù)對應參數(shù)是initialization.available-processors。4. SpringBoot自動裝配的隱藏鏈路不止是Tomcat這一個位置4.1 Tomcat容器線程切換的機制拆解上面配置解決的問題是Tomcat接受HTTP請求后的處理環(huán)節(jié)。HTTP請求進來后Tomcat的Acceptor線程負責accept連接然后把連接交給協(xié)議處理器ProtocolHandler協(xié)議處理器拿著剛才配置的執(zhí)行器來調(diào)度處理邏輯。換成虛擬線程后等于“連接接進來就用一個虛擬線程處理整個請求生命周期”請求再多也不怕。有一個常見的實測現(xiàn)象如果啟用了虛擬線程你在系統(tǒng)監(jiān)控里很難再看到Tomcat線程數(shù)暴漲的情況。因為平臺線程數(shù)量被控制在核心數(shù)量級線程數(shù)是平穩(wěn)的暴漲或者打滿都是虛擬線程級別的行為它們不會出現(xiàn)在老的監(jiān)控面板上。4.2 Async和定時任務不會自動繼承要單獨配置這個是很多博主不會特意提醒的地方。SpringBoot 3.2的spring.threads.virtual.enabledtrue配置只對Spring的TaskExecutor相關(guān)自動裝配生效。但是——EnableAsync注解開啟的Async方法、Scheduled定時任務任務有時候用的執(zhí)行器是獨立的不一定自動走虛擬線程。需要注意SpringBoot 3.2及以上的TaskExecutionAutoConfiguration確實會檢查ThreadPoolTaskExecutor這個Bean是否存在。實踐中你會發(fā)現(xiàn)如果你在某個配置類里手動定義了一個ThreadPoolTaskExecutor的Bean它仍然會覆蓋虛擬線程設置因為顯式定義的Bean優(yōu)先級高于自動裝配。這算是一個決定繞過后臺配置的合理手段但如果你本意是全局啟用虛擬線程這個覆蓋可能讓你踩坑。個人建議是明確了要全面啟用虛擬線程之后把項目里顯式定義的ThreadPoolTaskExecutor、Executor這些Bean全部清理一遍統(tǒng)一交給框架層去處理不做局部定義避免隱藏覆蓋。4.3 數(shù)據(jù)庫連接池、Redis連接、第三方RPC被“傳染”和沒被“傳染”的部分關(guān)鍵問題來了請求處理線程換成了虛擬線程那數(shù)據(jù)庫連接池HikariCP怎么辦Redis連接池怎么辦RPC框架的線程池怎么辦先說HikariCP。HikariCP底層是一個獨立連接池默認最大連接數(shù)是10請求線程從池里拿連接、用完歸還這個“拿連接”動作本身就是阻塞的。換成虛擬線程后請求線程在等待連接時是阻塞的虛擬線程它們不會占著平臺線程不放但是連接池資源仍然是10個連接這個上限。虛擬線程只是讓“等連接”這件事不再白白浪費平臺線程不代表數(shù)據(jù)庫能扛住更多并發(fā)連接。換句話說虛擬線程治的是“線程資源饑餓”不是“下游資源饑餓”。如果你的數(shù)據(jù)庫本身就慢、連接數(shù)本身就緊張換成虛擬線程之后請求還是會在HikariCP的connectionTimeout那里排隊只是排隊的線程從平臺線程變成了虛擬線程占用成本更低。然后再看RestTemplate、OpenFeign這類HTTP客戶端。它們默認使用的是JDK的HttpClient或者Apache HttpClient的連接池和請求線程的調(diào)度無關(guān)。虛擬線程環(huán)境下RPC調(diào)用方在等待響應的時候虛擬線程會主動讓出平臺線程平臺線程去執(zhí)行其他虛擬線程這個收益是直接覆蓋的。RPC連接池的并發(fā)能力本身沒有提升但RPC等待不再拖垮整臺服務的吞吐。4.4 還有一個隱藏玩家日志框架的異步寫入切換到虛擬線程后有個容易忽略的隱藏瓶頸是日志框架。很多項目的日志配置里加了異步Appender比如Logback的AsyncAppender它本質(zhì)是用一個固定線程池去消費日志隊列。如果隊列長度和丟棄策略寫得比較激進在虛擬線程的高吞吐下日志異步寫入會成為一個新的短板日志隊列瘋狂堆積然后丟棄排查問題的時候發(fā)現(xiàn)日志丟了。這個問題的解法有兩個方向一個是日志系統(tǒng)的Appender輸出端做批量寫盤另一個是把日志隊列調(diào)大同時調(diào)低丟棄閾值避免在壓測階段就丟日志。我在生產(chǎn)環(huán)境就碰到過一次案例吞吐提升了兩倍多結(jié)果日志文件里的請求追蹤斷了一半最后發(fā)現(xiàn)AsyncAppender的discardingThreshold設置得太激進。5. 壓測數(shù)據(jù)說話基于OpenFeign請求鏈路的虛擬線程實測5.1 為什么選OpenFeign作為壓測場景上面講了那么多原理下面用我實際做過的一次壓測來驗證。當時我們的一個核心鏈路是SpringBoot服務接收HTTP請求 - 調(diào)另一個服務的OpenFeign接口 - 再查一次MySQL - 返回結(jié)果。鏈路不算復雜但足夠有代表性這里面有完整的網(wǎng)絡IO阻塞Feign調(diào)用、數(shù)據(jù)庫IO阻塞MySQL查詢、以及穿插的序列化和反序列化計算。我設計了一個對照組對照組A使用傳統(tǒng)Tomcat線程池200線程對照組B使用虛擬線程通過手動配置類啟用壓測參數(shù)用相同QPS梯度灌進去500、1000、2000、4000、8000。機器條件8核16GJDK 21SpringBoot 3.2MySQL和下游服務都部署在同一內(nèi)網(wǎng)環(huán)境沒有網(wǎng)絡抖動等額外干擾因素。5.2 不同并發(fā)梯度下的吞吐和延遲對比這是有代表性的數(shù)據(jù)匯總單次壓測時長5分鐘取穩(wěn)定區(qū)間的P99QPS梯度平臺線程模式成功率平臺線程P99延遲虛擬線程模式成功率虛擬線程P99延遲500100%55ms100%58ms1000100%88ms100%72ms200099.2%260ms100%89ms400091%1200ms100%142ms800042%4000ms99.6%280ms一開始在低QPS區(qū)間500、1000兩者差距不大甚至平臺線程P99還略微好看一點點這符合“虛擬線程調(diào)度有一定開銷”的判斷。但QPS到了4000以后平臺線程模式開始明顯崩潰線程池在外部接口等待上耗盡大量線程處于阻塞排隊狀態(tài)P99突破秒級成功率掉到91%以下。而虛擬線程模式下8個平臺線程依然穩(wěn)定運轉(zhuǎn)P99緩慢上升但控制在300ms以內(nèi)。這里需要額外強調(diào)一點壓測期間我特意觀察了HikariCP連接池的活躍連接數(shù)兩種模式下基本趨同說明MySQL側(cè)的能力沒成為瓶頸。瓶頸就是純粹的線程調(diào)度模型差異——同樣的下游、同樣的機器只是換了個線程調(diào)度策略。5.3 數(shù)據(jù)之外的體感變化監(jiān)控和排障效率的變化除了壓測數(shù)字虛擬線程還給團隊帶來了一些“軟收益”。最直觀的是監(jiān)控面板上不再有tomcat.threads.current這種指標的毛刺了線程數(shù)變成一條平穩(wěn)的直線。報警郵件里以前經(jīng)常出現(xiàn)的“線程池活躍度超過90%”這個告警項直接被我刪掉了。然后是排障方式的改變。以前接口變慢第一反應是去dump線程一眼看到幾百個WAITING線程基本就是外部依賴慢導致線程堆積?，F(xiàn)在虛擬線程模式下線程dump里絕大部分是RUNNABLE狀態(tài)外部依賴慢導致的堆積很難再從線程角度觀察到需要依賴Trace系統(tǒng)去定位具體是哪一環(huán)耗時變大。這也是團隊需要提前適應的。6. 哪些場景千萬別用虛擬線程坑匯總與替代方案6.1 同步鎖synchronized的坑別在鎖里做阻塞操作虛擬線程不是全面免費的午餐最經(jīng)典的坑之一就是synchronized關(guān)鍵字JDK 21版本的虛擬線程在synchronized塊里被阻塞時會固定住底層承載它的平臺線程這個行為受JDK版本調(diào)度策略影響后續(xù)版本在持續(xù)優(yōu)化但在JDK 21時代就是如此。這是一種鎖競爭與IO阻塞疊加的情形虛擬線程A持有鎖等待網(wǎng)絡IO虛擬線程B排隊等鎖其他虛擬線程想用鎖的時候都堵在平臺上。最終結(jié)果可能是平臺線程被鎖卡住調(diào)度器能調(diào)度的虛擬線程數(shù)量反而減少了。如果你的代碼里有synchronized塊并且鎖塊內(nèi)會執(zhí)行阻塞操作外部RPC、數(shù)據(jù)庫查詢建議改成ReentrantLock虛擬線程在ReentrantLock的阻塞上不會釘住平臺線程JDK 21的調(diào)度器支持正確的park/unpark處理。6.2 CPU密集任務的場景虛擬線程沒有加速效果強調(diào)過了虛擬線程適合IO密集任務不適合CPU密集任務。如果你有一個任務是純計算比如大對象序列化、復雜算法計算、圖像處理它本身就會占滿分配給它的平臺線程直到計算結(jié)束不存在“讓出”的機會。假設你有8個核心你創(chuàng)建1萬個虛擬線程去跑CPU密集任務它們的總計算資源也就是8個核心的算力繼續(xù)累加虛擬線程數(shù)量只會增加調(diào)度切換開銷讓總耗時變長。這類任務建議明確使用固定數(shù)量的平臺線程池線程數(shù)設置為核心數(shù)±1比如Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())并在執(zhí)行入口處做好功耗控制。6.3 別把平臺線程當殼去套虛擬線程Executor還有一個看起來很合理但實際上是反模式的做法有人把Executors.newVirtualThreadPerTaskExecutor()放在一個池化的線程池里讓平臺線程池的任務去提交虛擬線程任務層層套殼。這樣做會把虛擬線程的“無池化”優(yōu)勢全部抵消掉平臺線程池一旦滿了照樣沒有救。虛擬線程的使用設計應該是一條鏈路貫穿到底——請求進來就是虛擬線程下游RPC操作、IO操作、阻塞調(diào)用全都在虛擬線程內(nèi)完成不要在中途切回平臺線程。6.4 什么時候保留平臺線程池更穩(wěn)妥最后說點理性的部分。雖然我把虛擬線程說得很好但并不是所有服務都得立刻切過來。下面的情況我建議保留原有線程模型服務本身就沒什么阻塞操作全是CPU計算為主的接口換了無益。對應的下游服務有嚴格的連接數(shù)限制比如數(shù)據(jù)庫最大連接數(shù)、第三方API QPS配額虛擬線程帶來的并發(fā)提升會被下游堅決阻斷反而加速下游不可用。團隊對JDK版本升級有大量顧慮JDK 17-21的升級涉及很多老庫兼容性問題這時不必為虛擬線程強行升級。其實呢很多Java老項目的開源庫可能還在用synchronized、還在用Object.wait做等待邏輯JDK 21的默認虛擬線程調(diào)度器在這些場景下效率確實會打折。如果你決定全面啟用虛擬線程建議先做一輪項目內(nèi)部庫的代碼審計把這類老舊的同步模式都清一遍。7. 新線程模型下的日志串聯(lián)與線程名稱觀察技巧7.1 線程名稱格式換到虛擬線程后你會發(fā)現(xiàn)一個細節(jié)變化日志里的線程名從tomcat-http-12變成了虛擬線程名/底層平臺線程名這種double格式比如Thread-0后面跟著ForkJoinPool-1-worker-3的影子?？吹竭@種格式說明線程調(diào)度已經(jīng)交給JVM了。順手分享一個小訣竅在測試環(huán)境如果日志里大量出現(xiàn)異步線程交替處理同一條請求不必慌張這是虛擬線程的正常行為。傳統(tǒng)線程模型下一個請求從頭到尾固定在一個線程上虛擬線程模式下可能會在多次阻塞切換后落在不同平臺線程上執(zhí)行它們通過統(tǒng)一的上下文“接續(xù)”執(zhí)行任務。7.2 帶上TraceId把跨線程鏈路串起來虛擬線程場景下跨線程日志的串聯(lián)需要格外重視。以前每次請求固定在線程上有天然優(yōu)勢——日志里的線程上下文天然串聯(lián)。虛擬線程會切來切去你需要保證MDCMapped Diagnostic Context里的TraceId在線程切換時是傳遞的。SpringBoot的taskDecorator機制可以做到代碼示例一發(fā)import org.springframework.core.task.TaskDecorator; import org.slf4j.MDC; public class MdcTaskDecorator implements TaskDecorator { Override public Runnable decorate(Runnable runnable) { var contextMap MDC.getCopyOfContextMap(); return () - { if (contextMap ! null) { MDC.setContextMap(contextMap); } try { runnable.run(); } finally { MDC.clear(); } }; } }這個裝飾器的意義在于當虛擬線程讓出平臺線程、換到另一個平臺線程執(zhí)行時MDC上下文能跟著虛擬線程對象走而不是綁定在老平臺線程上。配置執(zhí)行器的時候把裝飾器塞進去即可。如果團隊用了統(tǒng)一的Trace框架這一塊一般框架已經(jīng)處理了不需要重復造輪子但你要確認一下。7.3 監(jiān)控指標的遷移從線程數(shù)思維到任務耗時思維平臺線程時代我們判斷服務是否過載看得最多的就是線程活躍數(shù)和隊列長度。虛擬線程模式下這兩個指標基本失效了——平臺線程數(shù)穩(wěn)定得看不出任何波動隊列長度幾乎恒等于0。新的監(jiān)控重心應該轉(zhuǎn)移到任務在隊列里的等待時間調(diào)度延遲和請求全鏈路耗時分解上。之前查線程Dump來判斷外部依賴慢的方式被任務耗時分解替代了阻塞發(fā)生在哪個依賴上通過Trace里的span耗時就能一點一點挖出來。8. 我個人的最終建議怎么平穩(wěn)切換到虛擬線程如果前面的內(nèi)容都看完了下面給出一個可以直接上手的遷移路徑。先做一輪依賴庫審計把synchronized鎖里的阻塞操作、Object.wait模式、自研的線程池套殼設計全部列出來能改的改掉不能改的標記為風險項。然后在測試環(huán)境啟用虛擬線程跑一輪完整的回歸壓測重點觀察下游數(shù)據(jù)庫連接池和Redis連接池的表現(xiàn)確認它們的上限沒有成為新的瓶頸。之后在預發(fā)環(huán)境觀察一周不用擔心出問題虛擬線程的切換回退是很容易的——把配置關(guān)掉或者把那個自定義配置類注釋掉就回到了原樣。真正的風險集中在庫存量代碼中的鎖競爭和調(diào)用鏈路上而不是虛擬線程本身。對大部分應用場景來說虛擬線程確實是一次性把“平臺線程不夠用”這個老難題從架構(gòu)層面給消解掉了。我自己的體會是SpringBoot 3.x時代的框架自動裝配已經(jīng)幫開發(fā)者把這個切換成本降到了最低剩下要做的只是根據(jù)自己的業(yè)務負載去驗證和數(shù)據(jù)復盤。這個方向我相信未來幾年會逐漸成為Java服務端默認的線程模型。 SpringBoot虛擬線程實戰(zhàn)：從原理到壓測，告別線程池饑餓
這個標題看著就讓人手癢。說實話SpringBoot項目里把線程池換成虛擬線程這操作在一年前還是個需要猶豫半天的決定現(xiàn)在回頭看確實是鳥槍換大炮級別的體驗升級。這篇文章我打算用最直接的方式把虛擬線程從原理到SpringBoot落地再到實際壓測數(shù)據(jù)一次講透尤其是那些官網(wǎng)文檔不會告訴你的坑。1. 為什么說虛擬線程是SpringBoot的“鳥槍換炮”先看清平臺線程池的賬本1.1 從一次線上事故說起200個線程被IO堵死的真相先聊一個真實場景。我之前維護過一個典型的SpringBoot單體服務部署在8核16G的機器上Tomcat默認開了200個線程。平時接口響應都在幾十毫秒看上去一切歲月靜好。結(jié)果有一次對接的外部系統(tǒng)抽風一個查詢接口的響應時間從50ms飆到了3秒直接導致整個服務的吞吐量斷崖式下跌。當時排查下來典型的線程池饑餓200個線程全部阻塞在外部接口等待響應上后續(xù)請求排隊排隊再排隊新請求進來直接超時失敗。這個事故讓我對平臺線程模型有了非常痛的領悟——平臺線程和IO阻塞是天然對立的。Java傳統(tǒng)的線程模型里一個平臺線程對應一個內(nèi)核線程線程的創(chuàng)建、切換、銷毀都需要操作系統(tǒng)參與。更關(guān)鍵的是線程一旦進入阻塞狀態(tài)比如等待網(wǎng)絡響應、等待鎖、等待數(shù)據(jù)庫連接它占用的資源就全部浪費了。如果你是8核16G的機器Tomcat開200個線程已經(jīng)是上限附近了你去查線程dump會發(fā)現(xiàn)大量線程停在WAITING或者TIMED_WAITING狀態(tài)根本不是在干活是在干等。那時候我做過一個粗略計算一個平臺線程默認棧內(nèi)存是1MB200個線程就是200MB每個線程在阻塞時仍然占用內(nèi)核調(diào)度資源、占用線程元數(shù)據(jù)而它的CPU使用率可能只有1%。換句話說絕大多數(shù)線程資源花在了“等待”上而不是“計算”上。1.2 “每請求一線程”模式為什么在傳統(tǒng)容器里走不通了SpringBoot的經(jīng)典處理模型是“每請求一個線程”一個HTTP請求進來Tomcat線程池分配一個線程這個線程負責把請求處理完再歸還到線程池。這套模型在Web應用剛興起的年代沒問題因為那時候的請求基本都是短平快查個數(shù)據(jù)庫、拼個響應幾百毫秒就搞定了。但現(xiàn)在的業(yè)務場景早變了。一個普通的線上接口可能要先調(diào)一個鑒權(quán)服務再調(diào)一個訂單服務再查幾次數(shù)據(jù)庫再發(fā)個消息隊列通知。一個請求從進入到返回線程真正執(zhí)行CPU指令的時間可能只有10%剩下90%的時間全部阻塞在RPC調(diào)用、數(shù)據(jù)庫查詢、Redis操作這些IO等待上。按這個比例線程池開200個、300個甚至更多也只是在給“等待”買票讓更多請求排隊進入等待區(qū)而已。所以在虛擬線程之前解決高并發(fā)IO密集場景的經(jīng)典手段是異步化改造CompletableFuture串起來、引入反應式編程WebFlux、或者把同步調(diào)用改成異步消息。每一種方案都有劇烈的代價異步化改造會讓代碼可讀性變得極差業(yè)務日志里全是回調(diào)嵌套WebFlux更是讓絕大多數(shù)習慣了同步編程的團隊直接崩潰。1.3 虛擬線程到底解決了什么問題虛擬線程Project Loom的產(chǎn)物的本質(zhì)是讓Java能夠以極低的成本創(chuàng)建海量的、輕量級的線程對象而且這些線程的調(diào)度由JVM自己管理不依賴操作系統(tǒng)內(nèi)核線程。JDK 21正式發(fā)布了虛擬線程SpringBoot 3.2開始官方支持用虛擬線程替換默認的平臺線程池。用虛擬線程后的效果是什么你可以給Tomcat配置成“每請求一個虛擬線程”而虛擬線程創(chuàng)建成本近乎為零占用內(nèi)存只有幾KB到幾十KB一個8核機器上跑幾十萬個虛擬線程都沒問題。請求進來就開一個虛擬線程處理線程阻塞了就擱在那反正JVM內(nèi)成本極低根本不需要線程池來控制數(shù)量——沒有池化自然沒有池滿。我當時把內(nèi)部服務切到虛擬線程后最直觀的感受是線程池饑餓這個名詞從報警監(jiān)控里徹底消失了。不需要再盯著“activeThreads”這個指標做容量規(guī)劃也不需要為了一個第三方接口的超時抖動去調(diào)線程池參數(shù)。2. 虛擬線程的底層機制不是“更輕量的線程池”是“線程該回歸本質(zhì)了”2.1 用戶態(tài)調(diào)度與內(nèi)核級線程的分工要理解虛擬線程建議先忘掉“線程池”這個概念。虛擬線程和操作系統(tǒng)線程平臺線程是兩種維度的東西平臺線程由操作系統(tǒng)的調(diào)度器管理接受內(nèi)核的調(diào)度虛擬線程是一個純用戶態(tài)的對象由JVM的調(diào)度器Scheduler負責分配給平臺線程執(zhí)行。虛擬線程本身不是一個CPU執(zhí)行實體它更像是“一段可以被掛起和恢復的執(zhí)行狀態(tài)”。當虛擬線程執(zhí)行到阻塞IO比如socket.read()、Thread.sleep()時JVM調(diào)度器會把這個虛擬線程“卸載”下來也就是保存好它的調(diào)用棧和狀態(tài)然后釋放它所占用的平臺線程讓這個平臺線程去執(zhí)行其他虛擬線程。等IO結(jié)果回來了調(diào)度器再把之前保存的棧給恢復找個空閑的平臺線程繼續(xù)跑。這個過程有個很關(guān)鍵的點阻塞IO變成了協(xié)作式調(diào)度。虛擬線程遇到阻塞不會白白占著平臺線程而是主動讓出讓計算資源流轉(zhuǎn)起來。這也是為什么“少開點線程反而吞吐更高”——平臺線程數(shù)量只需要和CPU核心數(shù)匹配負責在虛擬線程之間來回切換執(zhí)行。2.2 一個大佬級別的實驗跑10萬個線程還是10萬個“線程”做個小實驗就能直觀感受虛擬線程的威力。下面這段代碼可以創(chuàng)建一個平臺線程的數(shù)組然后啟動它們每個線程阻塞3秒// 平臺線程版本 ExecutorService executor Executors.newFixedThreadPool(200);換成虛擬線程版本// 虛擬線程版本 try (ExecutorService executor Executors.newVirtualThreadPerTaskExecutor()) { for (int i 0; i 100_000; i) { executor.submit(() - { try { TimeUnit.SECONDS.sleep(3); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } }); } }平臺線程版本在200個線程時就已經(jīng)氣喘吁吁了線程數(shù)再往上加基本就是內(nèi)存爆炸而虛擬線程版本10萬個任務照樣輕松跑完占用的堆外內(nèi)存非常有限。你可以把這個測試跑一下已經(jīng)不需要看更多解釋這種數(shù)量級的差異會直接說服你。2.3 一個容易混淆的點虛擬線程并不提升計算速度它提升的是吞吐這個要單獨拿出來說因為很多人是帶著“虛擬線程應該讓接口更快”的期待來的。如果你把一個只做純計算的接口換到虛擬線程響應時間不會有任何變化甚至因為調(diào)度器的開銷反而稍微慢一點點。虛擬線程的真實價值是在“線程阻塞調(diào)度開銷”這個維度上省出了大量空間。用一個生活化類比平臺線程池模式像一家餐廳只雇了10個服務員每個服務員負責一桌客人的全套服務點單、上菜、結(jié)賬這桌客人發(fā)呆等菜服務員就只能在旁邊站著等虛擬線程模式像服務員只管把菜單遞給廚師然后立刻去接待下一桌客人菜做好了再回來端給那桌。服務員數(shù)量還是10人但同時間段完成的訂單量翻了10倍以上。這個類比對理解虛擬線程的性能收益非常有幫助。3. SpringBoot里啟用虛擬線程的具體操作官方途徑和手動兜底3.1 硬性條件拆解JDK版本和框架版本一步都不能少先把門檻劃清楚。虛擬線程是JDK 21正式落地的功能此前在JDK 19、20是預覽版強烈不建議在SpringBoot生產(chǎn)環(huán)境用預覽版。SpringBoot這邊3.2版本開始才支持通過配置一鍵啟用虛擬線程3.0和3.1沒有這個能力。如果用SpringBoot 2.x要么升級框架要么就只能手動寫配置類自己定義執(zhí)行器。配置前的檢查清單JDK版本必須21及以上我用的是21 LTS目前線上也跑得很穩(wěn)SpringBoot版本3.23.2.x、3.3.x都可以3.4.x也支持構(gòu)建工具Maven或Gradle你隨意這里無所謂依賴不需要額外引入任何包如果你的SpringBoot版本剛好是3.2以上那真的很幸運官方路線是自己改配置文件就行。如果不是也別慌后面有對應的兜底代碼方案。3.2 官方的一鍵配置SpringBoot 3.2起的配置項大解密SpringBoot 3.2留給開發(fā)者的是一行配置spring.threads.virtual.enabledtrue這里有個細節(jié)要注意這行配置管的是SpringBoot內(nèi)置的TaskExecutor比如Async注解的異步任務執(zhí)行器以及自動裝配的Tomcat容器線程池并不是。官網(wǎng)文檔里這行的準確描述是啟用后SpringBoot會把容器使用的執(zhí)行器切換成虛擬線程執(zhí)行器。放在servlet Web應用里它就是用來替換Tomcat處理請求的線程池的。也就是說加了這行配置后Tomcat對外表現(xiàn)為“每個請求來一個虛擬線程處理”不需要再調(diào)整server.tomcat.threads.max這些參數(shù)了因為線程池概念本質(zhì)上被繞過了。這里建議把server.tomcat.threads.max這類配置從配置文件中刪掉或者注釋掉避免給自己造成它還有效的錯覺。3.3 手動配置ThreadPoolExecutor替換方案的完整代碼如果你用的是SpringBoot 3.1、3.0或者SpringBoot 2.x那就需要自己動手寫一個配置類把默認的執(zhí)行器換成虛擬線程。import org.springframework.boot.web.embedded.tomcat.TomcatProtocolHandlerCustomizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import org.springframework.core.task.support.TaskExecutorAdapter; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; Configuration public class VirtualThreadConfig { Bean public TomcatProtocolHandlerCustomizer? protocolHandlerVirtualThreadExecutorCustomizer() { return protocolHandler - { ExecutorService executorService Executors.newVirtualThreadPerTaskExecutor(); protocolHandler.setExecutor(executorService); }; } }上面的代碼是給SpringBoot內(nèi)置Tomcat用的核心思路是拿到Tomcat的ProtocolHandler然后通過setExecutor把執(zhí)行器替換成虛擬線程執(zhí)行器。Executors.newVirtualThreadPerTaskExecutor()是JDK 21提供的工廠方法語義是“每次任務來一個虛擬線程用完就結(jié)束持續(xù)復用調(diào)度器”。如果你還在用SpringBoot 2.x版本沒有TomcatProtocolHandlerCustomizer這個API怎么辦還有第二套方案直接自己定義容器工廠import org.springframework.boot.web.embedded.tomcat.TomcatServletWebServerFactory; import org.springframework.boot.web.server.WebServerFactoryCustomizer; import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; Configuration public class VirtualThreadTomcatConfig { Bean public WebServerFactoryCustomizerTomcatServletWebServerFactory protocolHandlerCustomizer() { return factory - { ExecutorService executor Executors.newVirtualThreadPerTaskExecutor(); factory.addProtocolHandlerCustomizer(handler - handler.setExecutor(executor)); }; } }如果你不是用Tomcat而是Jetty也有對應的方案Jetty的QueuedThreadPool換成虛擬線程執(zhí)行器。不過說實話Java Web容器里Tomcat占了絕大多數(shù)場景我這邊就先按Tomcat來講Jetty的配置思路是類似的。3.4 核心參數(shù)解析為什么用“每任務一個虛擬線程”而不是固定線程池這里有個很重要的設計判斷虛擬線程場景下不要用Executors.newFixedThreadPool(虛擬線程數(shù)量)這種寫法。原因很簡單虛擬線程的優(yōu)勢就是便宜你想限制數(shù)量反而破壞了模型。假設你開了10萬個虛擬線程它們?nèi)烤€程池化了本質(zhì)上還是一個限制容量的池只是池中元素便宜了一點收益遠不如無池化。newVirtualThreadPerTaskExecutor()的核心語義是“任務就是全部”每次提交任務都創(chuàng)建一個新的虛擬線程去執(zhí)行執(zhí)行完銷毀。這不代表每次都創(chuàng)建平臺線程資源——底層調(diào)度器復用平臺線程只是虛擬線程對象本身是輕量的創(chuàng)建銷毀也就幾微秒的量級。我還特意看了Executors.newVirtualThreadPerTaskExecutor()的JDK源碼內(nèi)部本質(zhì)是返回了一個調(diào)度器驅(qū)動下的執(zhí)行器任務進來創(chuàng)建的是虛擬線程對象虛擬線程對象由JVM內(nèi)部的一個ForkJoinPool調(diào)度到平臺線程上執(zhí)行平臺線程數(shù)量默認等于CPU核心數(shù)對應參數(shù)是initialization.available-processors。4. SpringBoot自動裝配的隱藏鏈路不止是Tomcat這一個位置4.1 Tomcat容器線程切換的機制拆解上面配置解決的問題是Tomcat接受HTTP請求后的處理環(huán)節(jié)。HTTP請求進來后Tomcat的Acceptor線程負責accept連接然后把連接交給協(xié)議處理器ProtocolHandler協(xié)議處理器拿著剛才配置的執(zhí)行器來調(diào)度處理邏輯。換成虛擬線程后等于“連接接進來就用一個虛擬線程處理整個請求生命周期”請求再多也不怕。有一個常見的實測現(xiàn)象如果啟用了虛擬線程你在系統(tǒng)監(jiān)控里很難再看到Tomcat線程數(shù)暴漲的情況。因為平臺線程數(shù)量被控制在核心數(shù)量級線程數(shù)是平穩(wěn)的暴漲或者打滿都是虛擬線程級別的行為它們不會出現(xiàn)在老的監(jiān)控面板上。4.2 Async和定時任務不會自動繼承要單獨配置這個是很多博主不會特意提醒的地方。SpringBoot 3.2的spring.threads.virtual.enabledtrue配置只對Spring的TaskExecutor相關(guān)自動裝配生效。但是——EnableAsync注解開啟的Async方法、Scheduled定時任務任務有時候用的執(zhí)行器是獨立的不一定自動走虛擬線程。需要注意SpringBoot 3.2及以上的TaskExecutionAutoConfiguration確實會檢查ThreadPoolTaskExecutor這個Bean是否存在。實踐中你會發(fā)現(xiàn)如果你在某個配置類里手動定義了一個ThreadPoolTaskExecutor的Bean它仍然會覆蓋虛擬線程設置因為顯式定義的Bean優(yōu)先級高于自動裝配。這算是一個決定繞過后臺配置的合理手段但如果你本意是全局啟用虛擬線程這個覆蓋可能讓你踩坑。個人建議是明確了要全面啟用虛擬線程之后把項目里顯式定義的ThreadPoolTaskExecutor、Executor這些Bean全部清理一遍統(tǒng)一交給框架層去處理不做局部定義避免隱藏覆蓋。4.3 數(shù)據(jù)庫連接池、Redis連接、第三方RPC被“傳染”和沒被“傳染”的部分關(guān)鍵問題來了請求處理線程換成了虛擬線程那數(shù)據(jù)庫連接池HikariCP怎么辦Redis連接池怎么辦RPC框架的線程池怎么辦先說HikariCP。HikariCP底層是一個獨立連接池默認最大連接數(shù)是10請求線程從池里拿連接、用完歸還這個“拿連接”動作本身就是阻塞的。換成虛擬線程后請求線程在等待連接時是阻塞的虛擬線程它們不會占著平臺線程不放但是連接池資源仍然是10個連接這個上限。虛擬線程只是讓“等連接”這件事不再白白浪費平臺線程不代表數(shù)據(jù)庫能扛住更多并發(fā)連接。換句話說虛擬線程治的是“線程資源饑餓”不是“下游資源饑餓”。如果你的數(shù)據(jù)庫本身就慢、連接數(shù)本身就緊張換成虛擬線程之后請求還是會在HikariCP的connectionTimeout那里排隊只是排隊的線程從平臺線程變成了虛擬線程占用成本更低。然后再看RestTemplate、OpenFeign這類HTTP客戶端。它們默認使用的是JDK的HttpClient或者Apache HttpClient的連接池和請求線程的調(diào)度無關(guān)。虛擬線程環(huán)境下RPC調(diào)用方在等待響應的時候虛擬線程會主動讓出平臺線程平臺線程去執(zhí)行其他虛擬線程這個收益是直接覆蓋的。RPC連接池的并發(fā)能力本身沒有提升但RPC等待不再拖垮整臺服務的吞吐。4.4 還有一個隱藏玩家日志框架的異步寫入切換到虛擬線程后有個容易忽略的隱藏瓶頸是日志框架。很多項目的日志配置里加了異步Appender比如Logback的AsyncAppender它本質(zhì)是用一個固定線程池去消費日志隊列。如果隊列長度和丟棄策略寫得比較激進在虛擬線程的高吞吐下日志異步寫入會成為一個新的短板日志隊列瘋狂堆積然后丟棄排查問題的時候發(fā)現(xiàn)日志丟了。這個問題的解法有兩個方向一個是日志系統(tǒng)的Appender輸出端做批量寫盤另一個是把日志隊列調(diào)大同時調(diào)低丟棄閾值避免在壓測階段就丟日志。我在生產(chǎn)環(huán)境就碰到過一次案例吞吐提升了兩倍多結(jié)果日志文件里的請求追蹤斷了一半最后發(fā)現(xiàn)AsyncAppender的discardingThreshold設置得太激進。5. 壓測數(shù)據(jù)說話基于OpenFeign請求鏈路的虛擬線程實測5.1 為什么選OpenFeign作為壓測場景上面講了那么多原理下面用我實際做過的一次壓測來驗證。當時我們的一個核心鏈路是SpringBoot服務接收HTTP請求 - 調(diào)另一個服務的OpenFeign接口 - 再查一次MySQL - 返回結(jié)果。鏈路不算復雜但足夠有代表性這里面有完整的網(wǎng)絡IO阻塞Feign調(diào)用、數(shù)據(jù)庫IO阻塞MySQL查詢、以及穿插的序列化和反序列化計算。我設計了一個對照組對照組A使用傳統(tǒng)Tomcat線程池200線程對照組B使用虛擬線程通過手動配置類啟用壓測參數(shù)用相同QPS梯度灌進去500、1000、2000、4000、8000。機器條件8核16GJDK 21SpringBoot 3.2MySQL和下游服務都部署在同一內(nèi)網(wǎng)環(huán)境沒有網(wǎng)絡抖動等額外干擾因素。5.2 不同并發(fā)梯度下的吞吐和延遲對比這是有代表性的數(shù)據(jù)匯總單次壓測時長5分鐘取穩(wěn)定區(qū)間的P99QPS梯度平臺線程模式成功率平臺線程P99延遲虛擬線程模式成功率虛擬線程P99延遲500100%55ms100%58ms1000100%88ms100%72ms200099.2%260ms100%89ms400091%1200ms100%142ms800042%4000ms99.6%280ms一開始在低QPS區(qū)間500、1000兩者差距不大甚至平臺線程P99還略微好看一點點這符合“虛擬線程調(diào)度有一定開銷”的判斷。但QPS到了4000以后平臺線程模式開始明顯崩潰線程池在外部接口等待上耗盡大量線程處于阻塞排隊狀態(tài)P99突破秒級成功率掉到91%以下。而虛擬線程模式下8個平臺線程依然穩(wěn)定運轉(zhuǎn)P99緩慢上升但控制在300ms以內(nèi)。這里需要額外強調(diào)一點壓測期間我特意觀察了HikariCP連接池的活躍連接數(shù)兩種模式下基本趨同說明MySQL側(cè)的能力沒成為瓶頸。瓶頸就是純粹的線程調(diào)度模型差異——同樣的下游、同樣的機器只是換了個線程調(diào)度策略。5.3 數(shù)據(jù)之外的體感變化監(jiān)控和排障效率的變化除了壓測數(shù)字虛擬線程還給團隊帶來了一些“軟收益”。最直觀的是監(jiān)控面板上不再有tomcat.threads.current這種指標的毛刺了線程數(shù)變成一條平穩(wěn)的直線。報警郵件里以前經(jīng)常出現(xiàn)的“線程池活躍度超過90%”這個告警項直接被我刪掉了。然后是排障方式的改變。以前接口變慢第一反應是去dump線程一眼看到幾百個WAITING線程基本就是外部依賴慢導致線程堆積?，F(xiàn)在虛擬線程模式下線程dump里絕大部分是RUNNABLE狀態(tài)外部依賴慢導致的堆積很難再從線程角度觀察到需要依賴Trace系統(tǒng)去定位具體是哪一環(huán)耗時變大。這也是團隊需要提前適應的。6. 哪些場景千萬別用虛擬線程坑匯總與替代方案6.1 同步鎖synchronized的坑別在鎖里做阻塞操作虛擬線程不是全面免費的午餐最經(jīng)典的坑之一就是synchronized關(guān)鍵字JDK 21版本的虛擬線程在synchronized塊里被阻塞時會固定住底層承載它的平臺線程這個行為受JDK版本調(diào)度策略影響后續(xù)版本在持續(xù)優(yōu)化但在JDK 21時代就是如此。這是一種鎖競爭與IO阻塞疊加的情形虛擬線程A持有鎖等待網(wǎng)絡IO虛擬線程B排隊等鎖其他虛擬線程想用鎖的時候都堵在平臺上。最終結(jié)果可能是平臺線程被鎖卡住調(diào)度器能調(diào)度的虛擬線程數(shù)量反而減少了。如果你的代碼里有synchronized塊并且鎖塊內(nèi)會執(zhí)行阻塞操作外部RPC、數(shù)據(jù)庫查詢建議改成ReentrantLock虛擬線程在ReentrantLock的阻塞上不會釘住平臺線程JDK 21的調(diào)度器支持正確的park/unpark處理。6.2 CPU密集任務的場景虛擬線程沒有加速效果強調(diào)過了虛擬線程適合IO密集任務不適合CPU密集任務。如果你有一個任務是純計算比如大對象序列化、復雜算法計算、圖像處理它本身就會占滿分配給它的平臺線程直到計算結(jié)束不存在“讓出”的機會。假設你有8個核心你創(chuàng)建1萬個虛擬線程去跑CPU密集任務它們的總計算資源也就是8個核心的算力繼續(xù)累加虛擬線程數(shù)量只會增加調(diào)度切換開銷讓總耗時變長。這類任務建議明確使用固定數(shù)量的平臺線程池線程數(shù)設置為核心數(shù)±1比如Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())并在執(zhí)行入口處做好功耗控制。6.3 別把平臺線程當殼去套虛擬線程Executor還有一個看起來很合理但實際上是反模式的做法有人把Executors.newVirtualThreadPerTaskExecutor()放在一個池化的線程池里讓平臺線程池的任務去提交虛擬線程任務層層套殼。這樣做會把虛擬線程的“無池化”優(yōu)勢全部抵消掉平臺線程池一旦滿了照樣沒有救。虛擬線程的使用設計應該是一條鏈路貫穿到底——請求進來就是虛擬線程下游RPC操作、IO操作、阻塞調(diào)用全都在虛擬線程內(nèi)完成不要在中途切回平臺線程。6.4 什么時候保留平臺線程池更穩(wěn)妥最后說點理性的部分。雖然我把虛擬線程說得很好但并不是所有服務都得立刻切過來。下面的情況我建議保留原有線程模型服務本身就沒什么阻塞操作全是CPU計算為主的接口換了無益。對應的下游服務有嚴格的連接數(shù)限制比如數(shù)據(jù)庫最大連接數(shù)、第三方API QPS配額虛擬線程帶來的并發(fā)提升會被下游堅決阻斷反而加速下游不可用。團隊對JDK版本升級有大量顧慮JDK 17-21的升級涉及很多老庫兼容性問題這時不必為虛擬線程強行升級。其實呢很多Java老項目的開源庫可能還在用synchronized、還在用Object.wait做等待邏輯JDK 21的默認虛擬線程調(diào)度器在這些場景下效率確實會打折。如果你決定全面啟用虛擬線程建議先做一輪項目內(nèi)部庫的代碼審計把這類老舊的同步模式都清一遍。7. 新線程模型下的日志串聯(lián)與線程名稱觀察技巧7.1 線程名稱格式換到虛擬線程后你會發(fā)現(xiàn)一個細節(jié)變化日志里的線程名從tomcat-http-12變成了虛擬線程名/底層平臺線程名這種double格式比如Thread-0后面跟著ForkJoinPool-1-worker-3的影子?？吹竭@種格式說明線程調(diào)度已經(jīng)交給JVM了。順手分享一個小訣竅在測試環(huán)境如果日志里大量出現(xiàn)異步線程交替處理同一條請求不必慌張這是虛擬線程的正常行為。傳統(tǒng)線程模型下一個請求從頭到尾固定在一個線程上虛擬線程模式下可能會在多次阻塞切換后落在不同平臺線程上執(zhí)行它們通過統(tǒng)一的上下文“接續(xù)”執(zhí)行任務。7.2 帶上TraceId把跨線程鏈路串起來虛擬線程場景下跨線程日志的串聯(lián)需要格外重視。以前每次請求固定在線程上有天然優(yōu)勢——日志里的線程上下文天然串聯(lián)。虛擬線程會切來切去你需要保證MDCMapped Diagnostic Context里的TraceId在線程切換時是傳遞的。SpringBoot的taskDecorator機制可以做到代碼示例一發(fā)import org.springframework.core.task.TaskDecorator; import org.slf4j.MDC; public class MdcTaskDecorator implements TaskDecorator { Override public Runnable decorate(Runnable runnable) { var contextMap MDC.getCopyOfContextMap(); return () - { if (contextMap ! null) { MDC.setContextMap(contextMap); } try { runnable.run(); } finally { MDC.clear(); } }; } }這個裝飾器的意義在于當虛擬線程讓出平臺線程、換到另一個平臺線程執(zhí)行時MDC上下文能跟著虛擬線程對象走而不是綁定在老平臺線程上。配置執(zhí)行器的時候把裝飾器塞進去即可。如果團隊用了統(tǒng)一的Trace框架這一塊一般框架已經(jīng)處理了不需要重復造輪子但你要確認一下。7.3 監(jiān)控指標的遷移從線程數(shù)思維到任務耗時思維平臺線程時代我們判斷服務是否過載看得最多的就是線程活躍數(shù)和隊列長度。虛擬線程模式下這兩個指標基本失效了——平臺線程數(shù)穩(wěn)定得看不出任何波動隊列長度幾乎恒等于0。新的監(jiān)控重心應該轉(zhuǎn)移到任務在隊列里的等待時間調(diào)度延遲和請求全鏈路耗時分解上。之前查線程Dump來判斷外部依賴慢的方式被任務耗時分解替代了阻塞發(fā)生在哪個依賴上通過Trace里的span耗時就能一點一點挖出來。8. 我個人的最終建議怎么平穩(wěn)切換到虛擬線程如果前面的內(nèi)容都看完了下面給出一個可以直接上手的遷移路徑。先做一輪依賴庫審計把synchronized鎖里的阻塞操作、Object.wait模式、自研的線程池套殼設計全部列出來能改的改掉不能改的標記為風險項。然后在測試環(huán)境啟用虛擬線程跑一輪完整的回歸壓測重點觀察下游數(shù)據(jù)庫連接池和Redis連接池的表現(xiàn)確認它們的上限沒有成為新的瓶頸。之后在預發(fā)環(huán)境觀察一周不用擔心出問題虛擬線程的切換回退是很容易的——把配置關(guān)掉或者把那個自定義配置類注釋掉就回到了原樣。真正的風險集中在庫存量代碼中的鎖競爭和調(diào)用鏈路上而不是虛擬線程本身。對大部分應用場景來說虛擬線程確實是一次性把“平臺線程不夠用”這個老難題從架構(gòu)層面給消解掉了。我自己的體會是SpringBoot 3.x時代的框架自動裝配已經(jīng)幫開發(fā)者把這個切換成本降到了最低剩下要做的只是根據(jù)自己的業(yè)務負載去驗證和數(shù)據(jù)復盤。這個方向我相信未來幾年會逐漸成為Java服務端默認的線程模型。