歡迎訪問我的GitHub
這裡分類和彙總了欣宸的全部原創(含配套原始碼)：https://github.com/zq2599/blog_demos
本篇概覽
- 本篇是《支援JDK19虛擬執行緒的web框架》系列的第四篇，主要內容是閱讀quarkus原始碼，開闊眼界，瞭解框架級別的軟體是如何使用虛擬執行緒的，另外再感受一下整體架構設計的重要性，只有良好的設計才能保證新增能力對現有框架不會造成太大影響
- 另外請放心，雖然quarkus原始碼複雜，但本文會做到十分克制，不會在虛擬執行緒之外的地方展開閱讀和分析，以保證整篇文章都在聚焦虛擬執行緒，
- 本文主要由下圖的內容構成，紅色區域表示本篇核心：一個特別的Excutor物件，我們們只要搞清楚這個物件是如何建立的，以及如何使用，就弄明白了quarkus框架是如何支援虛擬執行緒的，另外之前我們們用過的@RunOnVirtualThread註解，在解釋Executor物件是從哪來的這個問題時也是決定性的，需要追蹤它的具體作用：
- 根據上面的規劃，本篇將分為以下三部分展開敘述：
- 首先是最具體形象的：前面的程式碼中，如果要開啟虛擬執行緒就用@RunOnVirtualThread註解去修飾方法，那麼我們們首先就要弄明白這個@RunOnVirtualThread註解在程式碼執行的時候，起到了什麼作用？
- 其次是本篇的核心：一個Executor物件的前世今生，今天的文章都會圍繞它展開，它是虛擬執行緒的靈魂，所以本文的第二部分就先弄明白這個重要的Executor是怎麼誕生的
- 最後，也就是最重要的：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支援虛擬執行緒的相關程式碼已經閱讀完畢，這裡再做個小結：
- 我們們在web介面類上新增的@RunOnVirtualThread註解，會存入每個web介面方法對應的ResourceMethod物件中
- 應用在初始化的時候，檢查web介面方法對應的ResourceMethod物件，如果需要在虛擬執行緒中響應，就給這個web介面繫結一個BlockingHandler物件，此物件有個成員變數，是個executor，是透過Executors.newVirtualThreadPerTaskExecutor()方法建立的
- web請求到達時，web介面方法的handler物件會被拿來執行其handler方法，BlockingHandler也是其中之一
- BlockingHandler的handler方法中，會使用executor.execute方法來執行web響應邏輯，此方法會建立建立虛擬執行緒，在虛擬執行緒中完成web響應
- 相比前面三篇的動手實戰，本篇主要在閱讀quarkus原始碼，略顯枯燥，儘管已儘量用圖來輔助理解，但是讀原始碼就是這樣，不但捷徑很少，岔路還特別多，好在我們們一路咬牙堅持下來了，收穫也不會少
後面更精彩
- 下一篇文章就是整個系列的終篇了，相比本文，終篇會簡單很多，大家一起在輕鬆的氛圍中暢談執行緒技術的一個重要成員：ThreadLocal，看它在虛擬執行緒時代如何興風作浪