本篇藉助JProfiler工具，從線程的觀察結果去印證官方資料，做到理論結合實踐，讓您領先一步，掌握和瞭解神秘的虛擬線程內幕 ...
歡迎訪問我的GitHub
這裡分類和彙總了欣宸的全部原創(含配套源碼)：https://github.com/zq2599/blog_demos
本篇概覽
- 本篇是《支持JDK19虛擬線程的web框架》系列的第三篇，在前面兩篇咱們一起瞭解和體驗了支持虛擬線程的web服務，功能性能都試過，整個開發過程也完整執行，算是對quarkus和虛擬線程有了初步的瞭解，但也留下兩個問題
- 虛擬線程和常規子線程的區別，究竟能不能看出來？前文已經驗證了性能上區別不大，那還有別的方式來觀察和區分嗎？
- 能不能稍微深入一點，僅憑一個@RunOnVirtualThread註解就強行寫兩篇博客，實在是太忽悠人了
- 本文聚焦第一個問題，與大家一起深入瞭解虛擬線程，重點在理論結合實際，將官方資料在實戰中得到印證
- 至於第二個問題，留待下一篇...
設置
- 開始深入學習前有個設置需要確認，否則會導致訪問服務失敗，請打開前文開發的quarkus應用，下圖紅色箭頭指向的配置必須存在，且值必須是0.0.0.0
- 如果沒有上述配置，IDEA啟動的應用就只會監聽127.0.0.1這塊網卡，如此依賴外部測試工具訪問此應用的服務就無法成功
- 那麼就開始吧：如何直觀地、清楚地看出虛擬線程和常規子線程的區別？
準備工作
- 工欲善其事.....咱們先把必要的工具裝上：IDEA的JProfiler插件，安裝步驟如下圖
- 接下來請在自己電腦上安裝JProfiler，註意，這一步必須要做，詳細的安裝和註(po)冊(jie)過程就不寫在本文中了，請自行搜索相關資料
- 完成上述準備後，點擊下圖箭頭所指按鈕，這樣就指定了JProfiler去監控分析啟動後的應用進程
- IDEA會拉起JProfiler
- 出現新的視窗如下圖，再點擊右下角的確定按鈕
- 現在JProfiler已經在監控quarkus應用的進程了，界面如下
- 如下圖，點擊線程歷史菜單，就能看到當前應用進程內的所有線程，註意按照步驟2過濾一下，只看存活的線程
- 接下來，咱們就要用JProfiler來觀察常規線程和虛擬線程的區別了
- 先回憶一下，前文中，咱們開發的quarkus應用有兩個web服務類，分別是：
-
VTPersonResource.java，該服務類使用了虛擬線程來執行web響應，對應web路徑：/vt/persons
-
PoolPersonResource.java，該服務類未使用虛擬線程，所以執行web響應的是傳統線程池中的子線程，對應web路徑：/pool/persons
- 接下來，壓測工具k6先後壓測上述兩個介面，用JProfiler觀察進程中線程的變化情況
不使用虛擬線程時的線程狀況
- 咱們先發請求到/pool/persons，也就是先不用虛擬線程，看看傳統線程池響應web服務的時候，在JProfiler中是啥樣的
- 像《上篇》那樣，用K6壓測介面/pool/persons，腳本如下，註意IP地址不能用localhost，因為這是在docker容器內運行的，localhost代表容器的迴環網卡，而並非宿主機的：
import http from 'k6/http';
import { sleep, check } from 'k6';
export let options = {
vus: 10,
duration: '60s',
};
export default function () {
let r = Math.floor(Math.random() * 6) + 1;
const res = http.get(`http://192.168.3.187:8080/pool/persons/${r}`);
check(res, {
'is status 200': (res) => res.status === 200,
'body size is > 0': (r) => r.body.length > 0,
});
sleep(1);
}
- 在壓測期間去看JProfiler，如下圖紅框，新增了10個線程，它們就是負責處理web響應的線程（前文的實戰中，我們已見過web響應的內容，裡面就有線程名稱，紅框中的和它們一致）
- 下圖是K6的測試報告，可見一共發起了570次請求，然而壓測期間JProfiler上新增的線程只有上圖中的十個，這也印證了線程池的邏輯：每個線程執行完業務邏輯後，回到線程池，下一次請求到來時，該線程繼續執行業務邏輯
- k6壓測結束後，等上三十秒再去看JProfiler，如下圖，那些處理web響應的子線程已經不見了（或者說不是存活狀態了）
- 如果您熟悉Java的線程池原理，對以上情況就一目瞭然：線程池空閑時，保留線程數不超過corePoolSize
- 既然看過了傳統線程池的服務情況，接著改看虛擬線程的情況了，兩邊對比著看收穫一定不小
思考：用JProfiler觀察虛擬線程，你到底想收穫什麼？（本篇精華段落）
-
大家好，接下來這一段話，個人覺得是本篇的精華，因為這是欣宸自己在迷茫中找到方向的一種方法（或者套路），希望能給您帶來參考
-
在用JProfiler觀察虛擬線程之前，咱們先來捋捋：接下來咱們究竟想看到什麼，能用文字說清楚嗎？這個問題很重要！
-
僅僅是想看一眼虛擬線程嗎？那無非就是看到幾個新增的線程，名字有些特殊，僅此而已，這能有啥收穫？
-
不要急於動手，咱們都應該冷靜下來，認真思考，讓這個問題能用文字表達出來，而不是僅僅在心中有個運行JProfiler的衝動：藉助JProfiler，咱們真正想要的是證虛擬線程的來龍去脈，也就是把官方文檔中的理論，在JProfiler中找到實現！
-
所以，先閱讀虛擬線程的官方文檔吧，放心，咱們只看最關鍵的部分即可，不會涉及長篇大論
-
打開java官方文檔，找到虛擬線程定義的那段，如下圖，註意紅框中的內容以及我的中文註解（我將下麵這幅圖稱為本篇最有價值的地方）
- 沒錯，官方文檔雖多，但咱們沒必要全看，上面這段才是關鍵，看完後捋捋流程圖如下
- 看到上圖，您應該會有以下三個疑惑：
- ForkJoin線程池啥時候創建的？會不會銷毀？
- 調度器（scheduler）啥時候創建的？會不會銷毀？
- carrier啥時候創建的？會不會銷毀？
- 如果這些關鍵問題沒說清楚，上面的流程圖算不算是捋了個寂寞...
- 要想搞清楚為什麼沒有回答上面三個問題，咱們把官方文檔滾動到最頂部，如下圖
- 上圖紅框表明，這是一篇JEP文檔，即： JDK Enhancement Proposal ，這類文檔只提出標準，而非實現，真正實現的這個標準的，是各個JVM虛擬機廠家（例如Oracle），所以，要想回答上面三個問題，只能去查找具體JDK軟體的實現
- 簡單的說：別糾結那三個問題，我答不上來...
- 咱們繼續，接下來更精彩
- 看過官方資料後，再回到最初的問題，咱們想通過JProfiler得到什麼？相信您已經很清楚了吧，我覺得是這三樣：
- 調度器，scheduler（ForkJoin線程池中的線程）
- 執行虛擬線程任務的真實線程，carrier
- 虛擬線程
- 現在開始壓測吧，繼續用k6，如下圖，腳本中的地址要改成使用虛擬線程的web服務
- 壓測期間去觀察JProfiler，如下圖，完全符合預期，說實話，第一次看到這些內容時，自己的內心是很激動的，這種知識點得到印證的感覺真是太好了
- 再看看那些不再存活的線程，如下圖，大量VirtualThreads存在，這也符合虛擬線程的特性：不復用，執行完畢就結束
- 等到壓測結束後，scheduler、carrier、虛擬線程，它們都不再存活，如下圖
- 如此看來，在執行任務的時候，會出現sheduler和carrier來完成虛擬線程中的任務，等到這些任務執行完畢，所有真實線程、虛擬線程都被結束，不再存活
- 至此，藉助JProfiler觀察常規線程和虛擬線程的實戰就完成了，經過了這些理論結合實際的操作和分析，相信您對虛擬線程的認知已經更具體和全面，如今它不再神秘或者高深莫測，咱們也更有信心學好它用好它
我有個想法
- 碼字碼到這裡，我想拋出一個大膽的想法和大家一起討論：今天咱們藉助JProfiler觀察到了scheduler、carrier、虛擬線程等的創建、運行、結束等過程，我這裡用的虛擬機是azul JDK，所以JProfiler中看到的也只是azul JDK對虛擬線程規範的實現情況，如果換成其他JDK，例如Oracle JDK，那麼在JProfiler中看到的scheduler、carrier、虛擬線程它們會不會有所不同呢？（例如scheduler可能會存活得久一些）畢竟JEP 425只是個標準，沒有明確規定實現，而azul JDK和Oracle JDK屬於不同廠商的實現
- 當然了這隻是個猜測，篇(lan)幅(de)所(dong)限(shou)就不在本篇做這些事情了，當我相信會有愛動手的讀者去實戰操作的，麻煩您告訴欣宸一下您的驗證結果，謝謝啦！
- 寫到這裡，虛擬線程的文章可以完結了嗎？不會，接下來咱們還要暢游quarkus，揭秘@RunOnVirtualThread註解背後的故事，看看優秀的框架是如何玩轉虛擬線程的，上廣告詞：欣宸原創，不辜負您的期待！
