JDK19虛線程探究
Part 01. 平臺線程
聊虛線程之前我們先說一下JDK19之前的標準線程，在JDK19中為了區分虛線程，給它起名叫平臺線程。它是對具體操作系統(OS)線程的包裝，每當在JVM中創建一個平臺線程，在OS中就一定有一個操作系統線程與之對應，任務代碼通過平臺線程在底層操作系統線程上運行。由于在平臺線程的整個生命周期過程中，要不停地捕獲操作系統線程，也就是說平臺線程要真實的綁定一個系統線程，因此應用中平臺線程的數量取決于操作系統的線程數量。
圖1 平臺線程調用示意
平臺線程適用所有類型任務，無論是IO密集型還是計算密集型，但由于平臺線程和操作系統線程綁定，當平臺線程執行IO密集型任務時(需要大量等待)，操作系統線程也要跟著等待，浪費很多時間在等待上，而且為了維系這種綁定關系，平臺線程需要維護大型線程堆棧，操作系統也需要為平臺線程維護其他資源，因此創建、調度平臺線程成本很高。
總之一句話，平臺線程好用，但很“貴”。
Part 02. 虛線程
JDK19開始提供虛線程的預覽功能，在JDK19中虛線程仍是一個java.lang.Thread實例，仍然可以使用 Thread 類和 Thread.Builder 接口創建虛擬線程，甚至在Executors上提供newVirtualThreadPerTaskExecutor方法用于創建虛擬線程，雖然創建出來的不是線程池。由此可見官方非常希望用戶在JDK后續版本中使用虛線程替換平臺線程。
虛線程雖然也是Thread實例，但它的創建不與OS線程綁定。它是由jvm負責創建調度，不需要維護大型堆棧，更不需要底層操作系統為其維護資源。
雖然虛線程不與OS線程綁定，但是提交給虛線程的任務代碼仍然是跑在OS線程上的。當JVM調度一個虛線程開始任務時，會將它與一個平臺線程綁定，平臺線程稱為虛線程的載體，虛線程開始執行任務，直到虛線被IO阻塞時，JVM再次調度虛線程，將它從平臺線程掛起，此時空閑下來的平臺線程就又可以與其他虛線程綁定，完成其它工作。
這種設計的好處有：（1） 虛線程的的創建、掛起、恢復成本很低；（2） 虛線程數量不受操作系統線程數量限制；（3） 線程切換放在虛線程那一層級，盡量減少了平臺線程的切換。
圖2 虛線程調用示意
Part 03. 平臺線程與虛線程的對比
3.1 線程的成本測試
測試目的主要為了觀察平臺線程與虛線程的創建成本以及調度成本，設計測試代碼如下：
圖片
代碼很簡單，構建一個task(主要是為了測試創建、切換線程的成本，因此task中不添加其他邏輯)，分別創建5萬個虛線程和平臺線程處理task。
橫坐標為測試代碼的時間線，綠色面積圖為CPU使用率，藍色柱狀圖為內存分配事件。
(虛線程跑5w個任務
(平臺線程跑5w個任務)
從上面的圖表可以看出，平臺線程的創建、切換對CPU、內存的消耗遠高于虛線程。
3.2 吞吐量測試-IO密集型任務
吞吐量測試邏輯，測試在相同平臺線程數、相同時間內哪一種線程執行的任務數量多。
JVM提供了2個參數用以控制虛線程能調度的平臺線程數：
jdk.virtualThreadScheduler.parallelism 控制提供多少個平臺線程用以虛線程調度。
jdk.virtualThreadScheduler.maxPoolSize 控制最多多少個平臺線程用以虛線程調度。
通過設置
-Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=1參數控制，虛線程只能創建1個平臺線程。
設計測試代碼一如下：
圖片
結果如下：
圖片
通過結果可以看出在IO密集型任務上，虛線程的吞吐量明顯高于平臺線程。
3.3 吞吐量測試-計算密集型任務
測試邏輯與3.2一樣，只是把任務邏輯改成模擬計算密集型。
測試代碼如下：
圖片
運行結果：
圖片
在計算密集型的任務中，平臺線程與虛線程表現差不多，說明虛線程并不會比平臺線程更快。
各種數據源通過Kafka接入到數據平臺層，數據平臺講明細數據存入數據存儲層的ClickHouse中，明細數據的存活時間可以根據業務需求設置。同時可以根據業務報表查詢的不同維度，利用ClickHouse的物化視圖形成預聚合數據，提高數據查詢效率。由數據服務層的定時任務周期性地從ClickHouse的預聚合數據中查詢業務所需的展示數據，把展示數據存入MySQL。由數據服務層的報表服務向數據展示層提供查詢服務，報表服務直接查詢MySQL中的結果數據，保證了查詢效率和并發性。
Part 04. 總結
(1)虛線程相對于平臺線程更加輕量，由JVM創建、調度；
(2)虛線程的調度過程中需要依賴一個平臺線程(掛載、卸載)；
(3)虛線程在IO密集型任務中比平臺線程更有優勢；
(4)虛線程目的不是讓系統更快，而是讓系統有更高的吞吐量。
