支持JDK19虛擬執行緒的web框架之四：看原始碼，了解quarkus如何支持虛擬執行緒

歡迎訪問我的GitHub

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

前文鏈接

• 支持JDK19虛擬執行緒的web框架，之一：體驗
• 支持JDK19虛擬執行緒的web框架，之二：完整開發一個支持虛擬執行緒的quarkus應用
• 支持JDK19虛擬執行緒的web框架，之三：觀察運行中的虛擬執行緒

本篇概覽

• 本篇是《支持JDK19虛擬執行緒的web框架》系列的第四篇，主要內容是閱讀quarkus原始碼，開闊眼界，了解框架級別的軟體是如何使用虛擬執行緒的，另外再感受一下整體架構設計的重要性，只有良好的設計才能保證新增能力對現有框架不會造成太大影響
• 另外請放心，雖然quarkus原始碼復雜，但本文會做到十分克制，不會在虛擬執行緒之外的地方展開閱讀和分析，以保證整篇文章都在聚焦虛擬執行緒，
• 本文主要由下圖的內容構成，紅色區域表示本篇核心：一個特別的Excutor物件，咱們只要搞清楚這個物件是如何創建的，以及如何使用，就弄明白了quarkus框架是如何支持虛擬執行緒的，另外之前咱們用過的@RunOnVirtualThread注解，在解釋Executor物件是從哪來的這個問題時也是決定性的，需要追蹤它的具體作用：

• 根據上面的規劃，本篇將分為以下三部分展開敘述：

1. 首先是最具體形象的：前面的代碼中，如果要開啟虛擬執行緒就用@RunOnVirtualThread注解去修飾方法，那么咱們首先就要弄明白這個@RunOnVirtualThread注解在代碼運行的時候，起到了什么作用？
2. 其次是本篇的核心：一個Executor物件的前世今生，今天的文章都會圍繞它展開，它是虛擬執行緒的靈魂，所以本文的第二部分就先弄明白這個重要的Executor是怎么誕生的
3. 最后，也就是最重要的：Executor物件是怎么作業的

• 接下來直奔主題吧，一頭扎入quarkus原始碼的汪洋，暢游其中

關于quarkus原始碼

• 本文中閱讀的quarkus原始碼版本是2.13.3.Final，下載地址：https://codeload.github.com/quarkusio/quarkus/zip/refs/tags/2.13.3.Final

引數isDefaultBlocking，后面多處用到

• 看原始碼的第一步，咱們先弄明白一個重要引數：isDefaultBlocking，因為后面的原始碼閱讀有好幾處都會用到

• 關于isDefaultBlocking，其來源是介面RequestContextFactory，如下圖，介面的isDefaultBlocking方法，默認回傳是false

• 實際運行中，該介面的實作類是ResteasyReactiveRecorder#createDeployment中創建的匿名類，其代碼如下，未實作isDefaultBlocking方法，因此依舊是介面定義中的默認方法生效，回傳值就是false

• 記住isDefaultBlocking等于false，接下來回到正題：咱們給web服務類添加的@RunOnVirtualThread注解，到底去了哪里？

@RunOnVirtualThread注解去哪了？

• quarkus應用啟動的時候，方法ResteasyReactiveProcessor#setupEndpoints會執行，主要是執行每個endpoint（web服務的可訪問地址）的初始化操作，里面會呼叫EndpointIndexer#createEndpoints方法

• EndpointIndexer#createEndpoints方法中，會為每個web介面方法創建ResourceMethod物件，里面是此web介面方法的配置資訊，注意下面箭頭所指位置，ResourceMethod物件的成員變數runOnVirtualThread的取值，來自同名的臨時變數

• 從下圖可見，那個臨時變數runOnVirtualThread其實來自方法isRunOnVirtualThread

• 打開EndpointIndexer#isRunOnVirtualThread方法，如下圖，如果某個類的某個方法被添加了@RunOnVirtualThread注解，那么下面的getInheritableAnnotation方法回傳的就是從此方法中取得的注解物件

• 至于上圖中的getInheritableAnnotation方法，我覺得很有必要看一眼，就一眼...，如下圖，可見，@RunOnVirtualThread注解不論是寫在方法上還是類上都有效

• 至此，可以小結了：咱們開發web服務的程序中，為web服務類添加的@RunOnVirtualThread，都存入了ResourceMethod物件中
• 上面這個結論很重要，后面會用到
• 現在已經順利弄明白了第一個問題：@RunOnVirtualThread注解去哪了？繼續下一個：那個特別的Executor物件是怎么誕生的？

關于Executor

• 本篇最重要的內容就是一個特別的Executor物件，現在就來聚焦它，先看它的創建程序
• quarkus應用啟動的時候，方法ResteasyReactiveProcessor#setupDeployment會執行，主要是完成應用啟動是的一些初始化操作，里面代碼很多，下圖箭頭所指是本篇最關心的，里面會提取bean的注解做對應的處理

• 現在，重點來了！！！
• 上圖紅色箭頭的代碼在ResteasyReactiveRecorder.java中，來看這個createDeployment方法，如下圖，第一個箭頭處，出現了一個靜態變數，名為VIRTUAL_EXECUTOR_SUPPLIER，它先被傳給了RuntimeDeploymentManager物件，然后在箭頭2位置，RuntimeDeploymentManager物件的deploy中，就會用到這個VIRTUAL_EXECUTOR_SUPPLIER

• 接下來兵分兩路，先看上圖箭頭1中的VIRTUAL_EXECUTOR_SUPPLIER是什么，再看箭頭2的deploy中如何使用VIRTUAL_EXECUTOR_SUPPLIER

首先，VIRTUAL_EXECUTOR_SUPPLIER是什么

• 在看之前，先回顧一下JDK官方指導是如何使用虛擬執行緒的，如下圖，一共兩步：先呼叫Executors.newVirtualThreadPerTaskExecutor()創建一個Executor實體（沒錯，就是咱們平時寫多執行緒代碼時的那個Executor），再執行executor.submit方法，這樣就創建了虛擬執行緒，并在虛擬執行緒中執行業務邏輯：

• 現在去看創建VIRTUAL_EXECUTOR_SUPPLIER的代碼就會特別清晰了，如下圖，前面在JDK官方指導看到的Executors.newVirtualThreadPerTaskExecutor()，在quarkus這里被改為用反射實作，這樣可以避免JDK19以下的環境中出現編譯問題，箭頭3位置的代碼也很重要，如果當前環境不支持虛擬執行緒，就會回傳一個可用的executor，確保業務能執行下去

• 對于上圖箭頭3位置的做法，個人并不認同：我使用虛擬執行緒，就是想一口氣創建成千上萬執行緒，再肆無忌憚的使用，遇到不支持虛擬執行緒的場景，直接拋例外讓我知道這條路走不通，逼我再去想辦法解決，這樣不好么？而箭頭3位置顯然回傳的是傳統執行緒，這么一來，豈不是成了創建成千上萬的傳統執行緒了？這誰扛得住？關鍵是，在開發階段，因為條件所限，可能只構造了少量執行緒來驗證基本功能，如果就這樣發布到生產環境，就有可能創建大量傳統執行緒，導致CPU的內核態使用率上漲，影響系統整體性能
• 至此，咱們算是搞清楚這個executor是啥了：用Executors.newVirtualThreadPerTaskExecutor()創建的Executor實體，雖然是用反射，但本質上得到的結果和JDK方法的推薦做法一致

其次，RuntimeDeploymentManager#deploy方法里是什么？

• 剛才說好的兵分兩路，先看VIRTUAL_EXECUTOR_SUPPLIER是什么，再看RuntimeDeploymentManager#deploy()方法

• 該方法內容很多，咱們還是只看虛擬執行緒有關的，如下圖，VIRTUAL_EXECUTOR_SUPPLIER成了runtimeResourceDeployment的成員變數，然后針對每個bean的每個方法，都要執行一次箭頭4指向的buildResourceMethod方法，此方法是關鍵，接下來重點看

• 展開上圖箭頭4的方法，原來如此，注意箭頭指向的method.isRunOnVirtualThread()，這個在前面已經分析過了，咱們用@isRunOnVirtualThread修飾過的web介面，在這里回傳的值就是true，就會執行箭頭2所指的代碼，為此web介面添加一個handler，從名字上看，這個blockingHandlerVirtualThread和之前咱們一直關注的VIRTUAL_EXECUTOR_SUPPLIER應該有不小的關系

• 看RuntimeResourceDeployment的構造方法，果然VIRTUAL_EXECUTOR_SUPPLIER是blockingHandlerVirtualThread構造方法的入參

• 至此就要先打住了，不要急著看BlockingHandler的代碼，那里面的東西是在處理web請求時才會執行，到目前為止咱們的重點還只是分析Executors.newVirtualThreadPerTaskExecutor()方法創建的executor去了哪里，現在就小結一下吧

• 一圖勝千言，本篇最核心的Executor物件的誕生程序，由一個主線邏輯和兩個支線邏輯組成，如下圖，紅色代表主線任務，它負責遍歷所有web介面對應的方法，發現該方法需要用虛擬執行緒執行時，就為此方法系結一個BlockingHandler物件，這個handler的成員變數中，就有直線邏輯用JDK19特定的方法創建出來的虛擬執行緒特有的executor物件，至于這個handler物件怎么用？就是本篇的另一半重要內容了：執行虛擬執行緒

• 至此，本篇的第二個重要問題：這個特別的Executor物件是哪來的，這個問題已經弄明白了（好像一句話就能說清楚：放入了和web介面方法關聯的handler中），接下來是最后一個問題：這個特別的Executor物件應該怎么用？

這個特別的Executor物件應該怎么用？

• 由于虛擬執行緒是在處理web回應的時候被用到的，所以分析這個特別的Executor物件時，不可避免的進入了quarkus處理web回應的復雜邏輯中，之所以說復雜，因為這里面最底層涉及到netty，再往上又涉及到vertx庫，如果咱們從頭去看會嚴重偏離主題，所以接下來分析web回應的代碼時，我這邊就盡量簡化了
• 代碼分析中RestInitialHandler#beginProcessing方法開始吧，對于反應式web服務，每次請求都會執行此方法，如下圖，紅色箭頭指向的ResteasyReactiveRequestContext物件需要重點關注，這里面放置了本次web請求的相關資訊，接下來就會執行此物件的run方法

• 打開run方法，豁然開朗，前面咱們看到為web介面方法系結handler，這里會取出handler依次執行

• 上圖的方法是在中實作的，打開代碼后嚇了我一跳，估計quarkus的人也怕被噴，在注釋中看到了他們滿滿的求生欲：代碼寫成這樣是為了性能考慮，這樣寫就是單態呼叫，取代了簡化寫法中的多型呼叫，會有更好的性能表現（不敢說學到了新技術，只能說開闊了眼界）

• 上面的代碼其實就是呼叫hanler的handle方法，所以，是時候去看那個BlockingHandler的handler方法了

• 剛打開代碼就大呼一聲痛快！如下圖，handler將虛擬執行緒的executor和web請求的背景關系物件requestContext串起來了，接下來該去箭頭2所指的resume中一探究竟，我這里大膽的猜一下，resume方法中要做的事情應該和Runnable有關，理由很簡單：Runnable和Executor不就是配合著用的嘛

• 上圖箭頭2的代碼在AbstractResteasyReactiveContext.java中，先看這個AbstractResteasyReactiveContext類，果然實作了Runnable

• 接下來該看AbstractResteasyReactiveContext#resume方法了，看之前我猜應該是executor.execute(this)，因為我只會這么寫...，打開代碼一看就樂了，原來我只會這么寫就夠了，因為他們也是這么寫的，注意箭頭2，本文的核心也就是這段代碼了

• 寫到這里，關于executor的使用也全部分析完了，用一個簡化圖小結吧

• 至此，quarkus支持虛擬執行緒的相關代碼已經閱讀完畢，這里再做個小結：

1. 咱們在web介面類上添加的@RunOnVirtualThread注解，會存入每個web介面方法對應的ResourceMethod物件中
2. 應用在初始化的時候，檢查web介面方法對應的ResourceMethod物件，如果需要在虛擬執行緒中回應，就給這個web介面系結一個BlockingHandler物件，此物件有個成員變數，是個executor，是通過Executors.newVirtualThreadPerTaskExecutor()方法創建的
3. web請求到達時，web介面方法的handler物件會被拿來執行其handler方法，BlockingHandler也是其中之一
4. BlockingHandler的handler方法中，會使用executor.execute方法來執行web回應邏輯，此方法會創建創建虛擬執行緒，在虛擬執行緒中完成web回應

• 相比前面三篇的動手實戰，本篇主要在閱讀quarkus原始碼，略顯枯燥，盡管已盡量用圖來輔助理解，但是讀原始碼就是這樣，不但捷徑很少，岔路還特別多，好在咱們一路咬牙堅持下來了，識訓也不會少

后面更精彩

• 下一篇文章就是整個系列的終篇了，相比本文，終篇會簡單很多，大家一起在輕松的氛圍中暢談執行緒技術的一個重要成員：ThreadLocal，看它在虛擬執行緒時代如何興風作浪

歡迎關注博客園：程式員欣宸

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

標籤：Java

上一篇：每日演算法題之二叉樹的深度

下一篇：Mysql詳解