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