Part 01. 平臺線程 

聊虛線程之前我們先說一下JDK19之前的標(biāo)準(zhǔn)線程，在JDK19中為了區(qū)分虛線程，給它起名叫平臺線程。它是對具體操作系統(tǒng)(OS)線程的包裝，每當(dāng)在JVM中創(chuàng)建一個平臺線程，在OS中就一定有一個操作系統(tǒng)線程與之對應(yīng)，任務(wù)代碼通過平臺線程在底層操作系統(tǒng)線程上運行。由于在平臺線程的整個生命周期過程中，要不停地捕獲操作系統(tǒng)線程，也就是說平臺線程要真實的綁定一個系統(tǒng)線程，因此應(yīng)用中平臺線程的數(shù)量取決于操作系統(tǒng)的線程數(shù)量。

圖1 平臺線程調(diào)用示意

平臺線程適用所有類型任務(wù)，無論是IO密集型還是計算密集型，但由于平臺線程和操作系統(tǒng)線程綁定，當(dāng)平臺線程執(zhí)行IO密集型任務(wù)時(需要大量等待)，操作系統(tǒng)線程也要跟著等待，浪費很多時間在等待上，而且為了維系這種綁定關(guān)系，平臺線程需要維護(hù)大型線程堆棧，操作系統(tǒng)也需要為平臺線程維護(hù)其他資源，因此創(chuàng)建、調(diào)度平臺線程成本很高。

總之一句話，平臺線程好用，但很“貴”。

Part 02. 虛線程  

JDK19開始提供虛線程的預(yù)覽功能，在JDK19中虛線程仍是一個java.lang.Thread實例，仍然可以使用 Thread 類和 Thread.Builder 接口創(chuàng)建虛擬線程，甚至在Executors上提供newVirtualThreadPerTaskExecutor方法用于創(chuàng)建虛擬線程，雖然創(chuàng)建出來的不是線程池。由此可見官方非常希望用戶在JDK后續(xù)版本中使用虛線程替換平臺線程。

虛線程雖然也是Thread實例，但它的創(chuàng)建不與OS線程綁定。它是由jvm負(fù)責(zé)創(chuàng)建調(diào)度，不需要維護(hù)大型堆棧，更不需要底層操作系統(tǒng)為其維護(hù)資源。

雖然虛線程不與OS線程綁定，但是提交給虛線程的任務(wù)代碼仍然是跑在OS線程上的。當(dāng)JVM調(diào)度一個虛線程開始任務(wù)時，會將它與一個平臺線程綁定，平臺線程稱為虛線程的載體，虛線程開始執(zhí)行任務(wù)，直到虛線被IO阻塞時，JVM再次調(diào)度虛線程，將它從平臺線程掛起，此時空閑下來的平臺線程就又可以與其他虛線程綁定，完成其它工作。

這種設(shè)計的好處有：（1） 虛線程的的創(chuàng)建、掛起、恢復(fù)成本很低；（2） 虛線程數(shù)量不受操作系統(tǒng)線程數(shù)量限制；（3） 線程切換放在虛線程那一層級，盡量減少了平臺線程的切換。

圖2 虛線程調(diào)用示意

Part 03.  平臺線程與虛線程的對比  

3.1 線程的成本測試

測試目的主要為了觀察平臺線程與虛線程的創(chuàng)建成本以及調(diào)度成本，設(shè)計測試代碼如下：

圖片

代碼很簡單，構(gòu)建一個task(主要是為了測試創(chuàng)建、切換線程的成本，因此task中不添加其他邏輯)，分別創(chuàng)建5萬個虛線程和平臺線程處理task。

橫坐標(biāo)為測試代碼的時間線，綠色面積圖為CPU使用率，藍(lán)色柱狀圖為內(nèi)存分配事件。

(虛線程跑5w個任務(wù)

(平臺線程跑5w個任務(wù))

從上面的圖表可以看出，平臺線程的創(chuàng)建、切換對CPU、內(nèi)存的消耗遠(yuǎn)高于虛線程。

3.2  吞吐量測試-IO密集型任務(wù)

吞吐量測試邏輯，測試在相同平臺線程數(shù)、相同時間內(nèi)哪一種線程執(zhí)行的任務(wù)數(shù)量多。

JVM提供了2個參數(shù)用以控制虛線程能調(diào)度的平臺線程數(shù)：

jdk.virtualThreadScheduler.parallelism 控制提供多少個平臺線程用以虛線程調(diào)度。

jdk.virtualThreadScheduler.maxPoolSize 控制最多多少個平臺線程用以虛線程調(diào)度。

通過設(shè)置

-Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1參數(shù)控制，虛線程只能創(chuàng)建1個平臺線程。

設(shè)計測試代碼一如下：

圖片

結(jié)果如下：

圖片

通過結(jié)果可以看出在IO密集型任務(wù)上，虛線程的吞吐量明顯高于平臺線程。

3.3 吞吐量測試-計算密集型任務(wù)

測試邏輯與3.2一樣，只是把任務(wù)邏輯改成模擬計算密集型。

測試代碼如下：

圖片

運行結(jié)果：

圖片

在計算密集型的任務(wù)中，平臺線程與虛線程表現(xiàn)差不多，說明虛線程并不會比平臺線程更快。

各種數(shù)據(jù)源通過Kafka接入到數(shù)據(jù)平臺層，數(shù)據(jù)平臺講明細(xì)數(shù)據(jù)存入數(shù)據(jù)存儲層的ClickHouse中，明細(xì)數(shù)據(jù)的存活時間可以根據(jù)業(yè)務(wù)需求設(shè)置。同時可以根據(jù)業(yè)務(wù)報表查詢的不同維度，利用ClickHouse的物化視圖形成預(yù)聚合數(shù)據(jù)，提高數(shù)據(jù)查詢效率。由數(shù)據(jù)服務(wù)層的定時任務(wù)周期性地從ClickHouse的預(yù)聚合數(shù)據(jù)中查詢業(yè)務(wù)所需的展示數(shù)據(jù)，把展示數(shù)據(jù)存入MySQL。由數(shù)據(jù)服務(wù)層的報表服務(wù)向數(shù)據(jù)展示層提供查詢服務(wù)，報表服務(wù)直接查詢MySQL中的結(jié)果數(shù)據(jù)，保證了查詢效率和并發(fā)性。

Part 04. 總結(jié) 

(1)虛線程相對于平臺線程更加輕量，由JVM創(chuàng)建、調(diào)度；

(2)虛線程的調(diào)度過程中需要依賴一個平臺線程(掛載、卸載)；

(3)虛線程在IO密集型任務(wù)中比平臺線程更有優(yōu)勢；

(4)虛線程目的不是讓系統(tǒng)更快，而是讓系統(tǒng)有更高的吞吐量。