你好呀，我是歪歪。
這周我在 Spring 的 github 上閒逛的時候，一個 issues 引起了我的興趣。
這篇文章，是我順著這個 issues 往下寫，始於它，但是不止於它：
https://github.com/spring-pro...
這個 issues 標題翻譯過來，就是說希望 @Async 這個註解能夠支援佔位符或 SpEL 表示式。
而我關注到這個 issues 的原因，完全是因為我之前寫過 @Async 相關的文章，看著眼熟，就隨手點進來看了一下。
在這個問題裡面，提到了一個編號為 27775 的 issues：
https://github.com/spring-pro...
這個說的是個啥事兒呢？
估計你看一眼我截圖中標註的地方也就看出來了，他想把執行緒池的名稱放到配置檔案裡面去。而這個需求我覺得並不奇怪，基於 Spring 框架來說，是一個很合理的需求。
搞個 Demo
我還是先給你搞個 Demo，驗收一下它想要幹啥。
首先注入了一個名稱為 why 的執行緒池。
然後有一個被 @Async 註解修飾的方法，而這個註解指定了一個值為 why 的 value，表明要使用名稱為 why 的這個執行緒池：
接著我們還需要一個 Controller，觸發一下：
最後在啟動類上加上 @EnableAsync 註解，把專案啟動起來。
呼叫下面的連結，發起呼叫：
http://127.0.0.1:8085/insertU...
輸出結果如下：
說明配置生效了。
然後，提出 issues 的這個哥們，他想要這麼一個功能：
也就是讓 @Async 註解和配置檔案進行聯動。
目前 Spring 的版本是不支援這個東西的，比如我把專案啟動起來之觸發一次：
直接丟擲了 NoSuchBeanDefinitionException，說明 @Async 的 value 註解並沒有解析表示式的功能。
支援一波
好的，現在需求就很明確了：目前不支援，有人在社群提出該需求，想要 Spring 支援該功能。
然後這個叫 sbrannen 的哥們出來了：
他說了兩句話：
- 1.如果提供的 BeanFactory 是 ConfigurableBeanFactory，我們似乎可以通過修改
org.springframework.aop.interceptor.AsyncExecutionAspectSupport.findQualifiedExecutor(BeanFactory，String)的程式碼，使用 EmbeddedValueResolver 來支援。 - 可以看一下
org.springframework.context.annotation.CommonAnnotationBeanPostProcessor.setBeanFactory(BeanFactory)，這是一個對應的例子。
第一句話中，他提到的 findQualifiedExecutor 方法，也就是需要修改的地方的程式碼，在我的 5.3.16 版本中是這樣的：
你先記住入參中有一個 beanFactory 就行了。
而第二句話中提到的 setBeanFactory 方法，是這樣的：
他說的 “for an example” 就是我框起來的部分。
這裡面關鍵的地方有兩個：
- ConfigurableBeanFactory
- EmbeddedValueResolver
首先 ConfigurableBeanFactory ，在 Spring 裡面是一個非常重要的類，但是不是本文重點，一句話帶過：你可以把它理解為是一個巨大的、功能齊全的工廠介面。
重點是 EmbeddedValueResolver 這個東西：
從註解上可以知道這個類是用來解析佔位符和表示式。相當於是 Spring 給你封裝好的一個工具類吧。
EmbeddedValueResolver 裡面就這一個方法：
而這個方法裡面呼叫了一個 resolveEmbeddedValue 方法：
org.springframework.beans.factory.support.AbstractBeanFactory#resolveEmbeddedValue
這個方法就是 Spring 裡面解析表示式的核心程式碼。
我給你演示一下。
首先我們加一點程式碼：
這個程式碼不需要解釋吧，已經很清晰了。
我只需要在我們前面分析的程式碼這裡打上斷點，然後把程式跑起來：
是不是很清晰了。
入參是 ${user.age} 表示式，出參是配置檔案中對應的 18。
關於如何解析的所有祕密都藏在這一行程式碼裡面：
你以為我要給你詳細講解嗎？
不可能的，指個路而已，自己看去吧。
現在我要開始拐彎了，拐回到這個老哥的回覆上：
現在我先帶你捋一捋啊。
首先，有個老鐵說：你這個 Spring 的 @Async 註解能不能支援表示式呀，比如這樣式兒的 @Async("${thread-pool.name}")
然後官方出來回覆說：沒問題啊，我們可以修改 findQualifiedExecutor 方法，在裡面使用 EmbeddedValueResolver 這個工具類來支援。比如就像是下面這個類中的 setBeanFactory 方法一樣：
接著我帶你去看了一下這個方法，然後知道了 EmbeddedValueResolver 的用法。
好的，那麼現在問題來了：在 findQualifiedExecutor 方法中，我們怎麼使用呢？
兜兜轉轉一大圈，現在就回到最開始的那個 issues 裡面：
這個老哥說他基於 sbrannen，也就是官方人員的提示.提交了這次修改。
怎麼修改的呢？
看他的 Files changed：
修改了三個檔案，其中一個測試類。
剩下兩個，一個是 @Async 註解：
這裡面只是修改了 Javadoc，表示這個註解支援表示式的方式進行配置。
另外一個是 AsyncExecutionAspectSupport 這個類：
在 findQualifiedExecutor 方法裡面加了五行程式碼，就完成了這個功能。
最後，官方在 review 程式碼的時候，又刪除一行程式碼：
也就是 4 行程式碼，其實應該是 2 行核心程式碼，就完成了讓 @Async 支援表示式的這個需求。
而且官方是先給你說了解決方案是什麼，只要你稍微你跟進一下，發動你的小腦殼思考一下，我想你寫出這 4 行程式碼也不是什麼困難的事情。
這就是給 Spring 貢獻原始碼了，而且是一個比較有價值的貢獻。如果是你抓住了這個機會，你完全可以在簡歷上寫一句：給 Spring 貢獻過原始碼，讓 @Async 註解支援表示式的配置方式。
一般來說對 Spring 瞭解不深入的朋友，看到這句話的時候，只會覺得很牛逼，想著應該是個大佬。
但是實際上，2 行核心程式碼就搞定了。
所以你說給 Spring 貢獻原始碼這個事兒難嗎？
機會總是有的，就看你有沒有上心了。
什麼，你問我有沒有給 Spring 貢獻過原始碼？
我沒有，我就是不上心，咋的了。
這是我寫這個文章想要表達的第個觀點：
給開源專案貢獻原始碼其實不是一件特別困難的事情，不要老想著一次就提交一整個功能上去。一點點改進，都是好的。
除錯技巧
前面提到的程式碼改進， Spring 還沒有釋出官方的包，但是我想要自己試驗一下，怎麼辦呢？
你當然可以把 Spring 的原始碼拉下來，然後自己編譯一波，最後本地改改原始碼試一試。
但是這個過程太過複雜了，基本上可以說是一個勸退的流程。
為了這麼一個小驗證，完全不值當。
所以我教你一個我自己研究出來的“騷”操作。
首先，我本地的 Spring 版本是 5.3.16，對應這部分的原始碼是這樣的:
還是先改造一下程式：
然後把程式跑起來，觸發一次呼叫，就會停在斷點的地方：
這個時候我們可以看到 qualifier 還是一個表示式的形式。
接著騷操作就來了。
你點選這個圖示，對應的快捷鍵是 Alt+F8：
這是 ide 提供的 Evaluate Expression 功能，在這個裡面是可以寫程式碼的。
比如這樣：
它還可以偷樑換柱，我在這裡把 qualifier 修改為 “yyds” 字串：
然後跑過斷點，你可以從異常資訊中看到，它是真的被修改了：
那麼，如果我把這次提交的這 4 行程式碼，利用 Evaluate Expression 功能執行一下，是不是就算是模擬了對應的修改後的功能了？
我就問你：這個方法“騷”不“騷”。
接下來，我們就實操起來。
把這幾行程式碼，填入到 Evaluate 裡面：
if (beanFactory instanceof ConfigurableBeanFactory) {
EmbeddedValueResolver embeddedValueResolver = new EmbeddedValueResolver((ConfigurableBeanFactory)beanFactory);
qualifier = embeddedValueResolver.resolveStringValue(qualifier);
}輸入程式碼片段，記得點選一下這個圖示：
點選執行之後是這樣的：
然後看輸出日誌，你可以看到這樣一行：
說明我的“偷樑換柱”大法成功了。
這不比你去編譯一份 Spring 原始碼來的方便的多？
而且這個除錯的方法，相當於是你在 debug 的時候還能再額外執行一些程式碼，所以有的時候真的有時候能起到奇效。
這是我寫這篇文章的第二個目的，想要分享給你這個除錯方法。
不同之處
細心的讀者肯定發現了，官方的程式碼有點奇怪啊：
首先 instanceof 是 Java 的保留關鍵字，它的作用是測試它左邊的物件是否是它右邊的類的例項，返回 boolean 的資料型別。
但是我記得 instanceof 不是這樣用的呀？這是個什麼騷操作啊？
不慌，先粘出來，放到 ide 裡面看看啥情況：
我們常用的寫法都是標號為 ① 那樣的，當我在我的環境裡面寫出標號為 ② 的程式碼的時候，ide 給我了一個提示：
Patterns in 'instanceof' are not supported at language level '8'
大概意思是說 instanceof 的這個用法在 JDK 8 裡面是不支援的。
看到這個提示的一瞬間，我突然想起了，這個寫法好像是 JDK 某個高階版本之後支援的，很久之前在某個地方瞟到過一眼。
然後我用 “Patterns instanceof” 關鍵詞查了一下，發現果然是 JDK 14 版本之後支援的一個新特性。
https://www.baeldung.com/java...
我就直接把文章中的例子拿出來給你說一下。
我們用 instanceof 的時候，基本上都是需要檢查物件的型別的場景，不同的型別對應不同的邏輯。
好，我問你，你使用 instanceof，在型別匹配上了之後，你的下一步操作是什麼？
是不是對物件進行強制型別轉換？
比如這樣的：
在上述程式碼截圖中，我們每種情況要通過 instanceof 判斷 animal 的具體型別，然後強制型別轉換宣告為區域性變數，接著根據具體的型別執行指定的函式。
這有的寫法有很多缺點：
- 這麼寫非常單調乏味，需要檢測型別然後強制型別轉換。
- 每個 if 都要出現三次型別名。
- 型別轉換和變數宣告可讀性很差
- 重複宣告型別名意味著很容易出錯，可能導致未預料到的執行時錯誤。
- 每新增一個animal 型別就要修改這裡的函式。
注意我加粗的地方，和原文是一樣的，這波強調和細節是拉滿了的：
為了解決上面提到的部分缺點，Java 14 提供了可以將引數型別檢查和繫結區域性變數型別合併到一起的 instanceof 操作。
就像這樣式兒的：
首先在 if 程式碼塊對 animal 的型別和 Cat 進行匹配。先看 animal 變數是否為 Cat 型別的例項，如果是，強轉為 Cat 型別，並賦值給 cat。
需要注意的是變數名 cat 並不是一個真正存在的變數，只是模式變數的一個宣告而已。你可以理解為固定語法。
變數 cat 和 dog 只有當模式匹配表示式的結果為 true 時才生效和賦值。所以如果你一不小心把變數用在別的地方，直接會提醒你編譯錯誤。
所以你對比一下上面兩個版本的程式碼，肯定是 Java 14 版本的程式碼更簡潔，也更易懂。減少了大量的型別轉換，而且可讀性大大提高。
回到 Spring
你看，本來是看 Spring 的，怎麼突然寫到了 JDK 的新特性了呢？
那必然是我埋下的伏筆啊。
我給你看一個東西：
https://spring.io/blog/2021/0...
官方在去年的 SpringOne 大會上就宣佈了：Spring 6.0 和 Spring Boot 3 這兩大框架的 JDK 基線版本是 17。
也就是說：我們很有可能在 JDK 8 之後，下一個要擁抱的版本是 JDK 17。
而我，作為一個技術愛好者的角度來說：這是好事，得支援，大力支援。
但是，作為一個寫著 CRUD 的 Java 從業者來說：想想升級之後各種相容性問題就頭疼，所以希望這個擁抱不要發生在我短暫的職業生涯中。去讓那幫年輕力壯，剛剛入行的小夥子們去折騰吧。
而當我把視角侷限在這篇文章的角度，電光火石之間，我又想到了一個給 Spring 貢獻原始碼的“騷”操作。
歷史程式碼中這麼多用 instanceof 的地方，我只要在 6.0 分支裡面，把這些地方都換成新特性的寫法，那豈不是一個更簡單的貢獻原始碼的方式？
但是，在提交 issues 之前，一般流程都是要先去查詢一下有沒有類似的提交。
所以在幹這事之前，我還是先冷靜的查詢了一下。
一查，我都笑了...
我都能想到，肯定其他人也能想到，果然有人已經捷足先登了。
比如這裡：
https://github.com/spring-pro...
這次對應提交的程式碼是這樣的：
然後，官方還在裡面小小的吐槽了一波：
簡單來說就是：老哥，這樣的小改進，就還是不要提 issue 了吧。你得整個大的啊，別隻改一個類啊。
我覺得也是，你改你改一個模組也行呀，比如這位老哥，改了 Spring-beans 模組下的 8 個檔案：
這樣才是針對這類改動的正確姿勢。
反正我把路指在這裡了，你要是有興趣，可以去看看 Spring 6.0 的程式碼是不是還有一些沒有改的地方，你去試著提交一把。
這個話題又回到我最開始表達的第一個觀點了：
給開源專案貢獻原始碼其實不是一件特別困難的事情，不要老想著一次就提交一整個功能上去。一點點改進，都是好的。
提交的東西確實是和 Spring 框架關係不大，但是你至少能體驗一下給開源專案做貢獻的流程和感覺吧，而且越大的專案，流程約精細，肯定是能學到東西。
而這個過程中學到的東西，絕對比你提交一個 instanceof 改進大的多，所以你還能說這樣的提交是沒有什麼營養的嘛？
比如我去年的一篇文章中，就提到了 Dubbo 在對響應報文進行解碼的時候有一個沒必要的重複操作，可以刪除一行校驗相關的程式碼。
我沒有去提對應的 pr，但是我寫在了文章中。
有個讀者看到後，當天中午就去提交了，官方也很快入庫了。
去年年底的時候 Dubbo 社群搞了一個回饋活動，就給他送了一個咖啡杯：
意外驚喜，一行程式碼，不僅可以學點知識，還可以免費得個咖啡杯，就問香不香。
昇華一下
好了，回顧一下這篇文章。
我從 @Async 支援表示式作為引子，引到了 instanceof 的新特性，接著又引到了 Spring 6 會以 JDK 17 作為基線版本。
其實我寫這篇文章的時候，腦海中一直在縈繞著一句話：大風起於青萍之末。
instanceof，是青萍之末。
大風就是 JDK 17 作為基線版本。
關於為什麼要用 JDK 17 作為基線版本，其實這是風華正茂的 Java 的一次渡劫。渡劫是否成功，關係著我們每一個從業者。
在雲原生的“喧譁”之下，走在前面的人已經感受到：大風已經吹起來了。
比如周志明博士在一次名為《雲原生時代，Java 的危與機》中說了這樣的一段話：
https://icyfenix.cn/tricks/20...
未來一段時間，是 Java 重要的轉型視窗期，如果作為下一個 LTS 版的 Java 17，能夠成功集 Amber、Portola、Valhalla、Loom 和 Panama 的新能力、新特性於一身，GraalVM 也能給予足夠強力支援的話，那 Java 17 LTS 大概率會是一個里程碑式的版本，帶領著整個 Java 生態從大規模服務端應用，向新的雲原生時代軟體系統轉型。
可能成為比肩當年從面向嵌入式裝置與瀏覽器 Web Applets 的 Java 1，到確立現代 Java 語言方向（Java SE/EE/ME 和 JavaCard）雛形的 Java 2 轉型那樣的里程碑。
但是，如果 Java 不能加速自己的發展步伐，那由強大生態所構建的護城河終究會消耗殆盡，被 Golang、Rust 這樣的新生語言，以及 C、C++、C#、Python 等老對手蠶食掉很大一部分市場份額，以至被迫從“天下第一”程式語言的寶座中退位。
Java 的未來是繼續向前，再攀高峰，還是由盛轉衰，鋒芒挫縮，你我拭目以待。
而我，還只是看到了青萍之末。
最後，文章首發於公眾號[why技術]，歡迎關注，第一時間接收最新文章。