支援JDK19虛擬執行緒的web框架，之三：觀察運行中的虛擬執行緒

歡迎訪問我的GitHub

這裡分類和匯總了欣宸的全部原創(含配套源碼)：//github.com/zq2599/blog_demos

《支援JDK19虛擬執行緒的web框架》系列文章鏈接

本篇概覽

  • 本篇是《支援JDK19虛擬執行緒的web框架》系列的第三篇，在前面兩篇咱們一起了解和體驗了支援虛擬執行緒的web服務，功能性能都試過，整個開發過程也完整執行，算是對quarkus和虛擬執行緒有了初步的了解，但也留下兩個問題
  1. 虛擬執行緒和常規子執行緒的區別，究竟能不能看出來？前文已經驗證了性能上區別不大，那還有別的方式來觀察和區分嗎？
  2. 能不能稍微深入一點，僅憑一個@RunOnVirtualThread註解就強行寫兩篇部落格，實在是太忽悠人了
  • 本文聚焦第一個問題，與大家一起深入了解虛擬執行緒，重點在理論結合實際，將官方資料在實戰中得到印證
  • 至於第二個問題，留待下一篇…

設置

  • 開始深入學習前有個設置需要確認，否則會導致訪問服務失敗，請打開前文開發的quarkus應用，下圖紅色箭頭指向的配置必須存在，且值必須是0.0.0.0

image-20221022153432270

  • 如果沒有上述配置，IDEA啟動的應用就只會監聽127.0.0.1這塊網卡，如此依賴外部測試工具訪問此應用的服務就無法成功
  • 那麼就開始吧：如何直觀地、清楚地看出虛擬執行緒和常規子執行緒的區別？

準備工作

  • 工欲善其事…..咱們先把必要的工具裝上：IDEA的JProfiler插件，安裝步驟如下圖

image-20221015164110766

  • 接下來請在自己電腦上安裝JProfiler，注意，這一步必須要做，詳細的安裝和注(po)冊(jie)過程就不寫在本文中了，請自行搜索相關資料
  • 完成上述準備後，點擊下圖箭頭所指按鈕，這樣就指定了JProfiler去監控分析啟動後的應用進程
  • IDEA會拉起JProfiler

image-20221022114521069

  • 出現新的窗口如下圖，再點擊右下角的確定按鈕

image-20221022114723561

  • 現在JProfiler已經在監控quarkus應用的進程了，介面如下

image-20221022120025891

  • 如下圖，點擊執行緒歷史菜單，就能看到當前應用進程內的所有執行緒，注意按照步驟2過濾一下，只看存活的執行緒

image-20221022160249366

  • 接下來，咱們就要用JProfiler來觀察常規執行緒和虛擬執行緒的區別了
  • 先回憶一下，前文中，咱們開發的quarkus應用有兩個web服務類，分別是：

  1. VTPersonResource.java，該服務類使用了虛擬執行緒來執行web響應，對應web路徑：/vt/persons

  2. 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(`//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響應的內容，裡面就有執行緒名稱，紅框中的和它們一致）

image-20221022160442914

  • 下圖是K6的測試報告，可見一共發起了570次請求，然而壓測期間JProfiler上新增的執行緒只有上圖中的十個，這也印證了執行緒池的邏輯：每個執行緒執行完業務邏輯後，回到執行緒池，下一次請求到來時，該執行緒繼續執行業務邏輯

image-20221022161058526

  • k6壓測結束後，等上三十秒再去看JProfiler，如下圖，那些處理web響應的子執行緒已經不見了（或者說不是存活狀態了）

image-20221022161339902

  • 如果您熟悉Java的執行緒池原理，對以上情況就一目了然：執行緒池空閑時，保留執行緒數不超過corePoolSize
  • 既然看過了傳統執行緒池的服務情況，接著改看虛擬執行緒的情況了，兩邊對比著看收穫一定不小

思考：用JProfiler觀察虛擬執行緒，你到底想收穫什麼？（本篇精華段落）

  • 大家好，接下來這一段話，個人覺得是本篇的精華，因為這是欣宸自己在迷茫中找到方向的一種方法（或者套路），希望能給您帶來參考

  • 在用JProfiler觀察虛擬執行緒之前，咱們先來捋捋：接下來咱們究竟想看到什麼，能用文字說清楚嗎？這個問題很重要！

  • 僅僅是想看一眼虛擬執行緒嗎？那無非就是看到幾個新增的執行緒，名字有些特殊，僅此而已，這能有啥收穫？

  • 不要急於動手，咱們都應該冷靜下來，認真思考，讓這個問題能用文字表達出來，而不是僅僅在心中有個運行JProfiler的衝動：藉助JProfiler，咱們真正想要的是證虛擬執行緒的來龍去脈，也就是把官方文檔中的理論，在JProfiler中找到實現！

  • 所以，先閱讀虛擬執行緒的官方文檔吧，放心，咱們只看最關鍵的部分即可，不會涉及長篇大論

  • 打開java官方文檔，找到虛擬執行緒定義的那段，如下圖，注意紅框中的內容以及我的中文註解（我將下面這幅圖稱為本篇最有價值的地方）

image-20221022175154277

  • 沒錯，官方文檔雖多，但咱們沒必要全看，上面這段才是關鍵，看完後捋捋流程圖如下

image-20221022212357583

  • 看到上圖，您應該會有以下三個疑惑：
  1. ForkJoin執行緒池啥時候創建的？會不會銷毀？
  2. 調度器（scheduler）啥時候創建的？會不會銷毀？
  3. carrier啥時候創建的？會不會銷毀？
  • 如果這些關鍵問題沒說清楚，上面的流程圖算不算是捋了個寂寞…
  • 要想搞清楚為什麼沒有回答上面三個問題，咱們把官方文檔滾動到最頂部，如下圖

image-20221022213416135

  • 上圖紅框表明，這是一篇JEP文檔，即： JDK Enhancement Proposal ，這類文檔只提出標準，而非實現，真正實現的這個標準的，是各個JVM虛擬機廠家（例如Oracle），所以，要想回答上面三個問題，只能去查找具體JDK軟體的實現
  • 簡單的說：別糾結那三個問題，我答不上來…
  • 咱們繼續，接下來更精彩
  • 看過官方資料後，再回到最初的問題，咱們想通過JProfiler得到什麼？相信您已經很清楚了吧，我覺得是這三樣：
  1. 調度器，scheduler（ForkJoin執行緒池中的執行緒）
  2. 執行虛擬執行緒任務的真實執行緒，carrier
  3. 虛擬執行緒
  • 現在開始壓測吧，繼續用k6，如下圖，腳本中的地址要改成使用虛擬執行緒的web服務

image-20221022171002446

  • 壓測期間去觀察JProfiler，如下圖，完全符合預期，說實話，第一次看到這些內容時，自己的內心是很激動的，這種知識點得到印證的感覺真是太好了

image-20221022215116960

  • 再看看那些不再存活的執行緒，如下圖，大量VirtualThreads存在，這也符合虛擬執行緒的特性：不復用，執行完畢就結束

image-20221022220055370

  • 等到壓測結束後，scheduler、carrier、虛擬執行緒，它們都不再存活，如下圖

image-20221022221215621

  • 如此看來，在執行任務的時候，會出現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註解背後的故事，看看優秀的框架是如何玩轉虛擬執行緒的，上廣告詞：欣宸原創，不辜負您的期待！

歡迎關注部落格園：程式設計師欣宸

學習路上，你不孤單，欣宸原創一路相伴…

Tags:

VirMach 便宜 VPS

QNews

QNews