你好呀，我是歪歪。
前兩天在看 SOFABoot 的時候，看到一個讓我眼前一亮的東西，來給大家盤一下。
SOFABoot，你可能不眼熟，但是沒關係，本文也不是給你講這個東西的，你就認爲它是 SpringBoot 的變種就行了。
因爲有螞蟻金服背書，所以主要是一些金融類的公司在使用這個框架：
官方介紹是這樣的：
SOFABoot 是螞蟻金服開源的基於 Spring Boot 的研發框架，它在 Spring Boot 的基礎上，提供了諸如 Readiness Check，類隔離，日誌空間隔離等能力。在增強了 Spring Boot 的同時，SOFABoot 提供了讓用戶可以在 Spring Boot 中非常方便地使用 SOFA 中間件的能力。
上面這些功能都很強大，但是我主要是分享一下它的這個小功能：
https://help.aliyun.com/document_detail/133162.html
這個功能可以讓 Bean 的初始化方法在異步線程裏面執行，從而加快 Spring 上下文加載過程，提高應用啓動速度。
爲什麼看到功能的時候，我眼前一亮呢，因爲我很久之前寫過這篇文章《我是真沒想到，這個面試題居然從11年前就開始討論了，而官方今年才表態。》
裏面提到的面試題是這樣的：
Spring 在啓動期間會做類掃描，以單例模式放入 ioc。但是 spring 只是一個個類進行處理，如果爲了加速，我們取消 spring 自帶的類掃描功能，用寫代碼的多線程方式並行進行處理，這種方案可行嗎？爲什麼？
當時通過 issue 找到了官方對於這個問題回覆總結起來就是：應該是先找到啓動慢的根本原因，而不是把問題甩鍋給 Spring。這部分對於 Spring 來說，能不動，就別動。
僅從“啓動加速-異步初始化方法”這個標題上來看，Spring 官方不支持的東西 SOFABoot 支持了。所以這玩意讓我眼前一亮，我倒要看看你是怎麼搞得。
先說結論：SOFABoot 的方案能從一定程度上解決問題，但是它依賴於我們編碼的時候指定哪些 Bean 是可以異步初始化的，這樣帶來的好處是不必考慮循環依賴、依賴注入等等各種複雜的情況了，壞處就是需要程序員自己去識別哪些類是可以異步初始化的。
我倒是覺得，程序員本來就應該具備“識別自己的項目中哪些類是可以異步初始化”的能力。
但是，一旦要求程序員來主動去識別了，就已經“輸了”，已經不夠驚豔了，在實現難度上就不是一個級別的事情了。人家 Spring 想的可是框架給你全部搞定，頂多給你留一個開關，你開箱即用，啥都不用管。
但是總的來說，作爲一次思路演變爲源碼的學習案例來說，還是很不錯的。
我們主要是看實現方案和具體邏輯代碼，以 SOFABoot 爲抓手，針對其“異步初始化方法”聚焦下鑽，把源碼當做紐帶，協同 Spring，打出一套“我看到了->我會用了->我拿過來->我看懂了->是我的了->寫進簡歷”的組合拳。
Demo
先搞個 Demo 出來，演示一波效果，先讓你直觀的看到這是個啥玩意。
這個 Demo 非常之簡單，幾行代碼就搞定。
先搞兩個 java 類，裏面有一個 init 方法：
然後把他們作爲 Bean 交給 Spring 管理，Demo 就搭建好了：
直接啓動項目，啓動時間只需要 1.152s，非常絲滑：
然後，注意，我要稍微的變一下形。
在注入 Bean 的時候觸發一下初始化方法，模擬實際項目中在 Bean 的初始化階段，既在 Spring 項目啓動過程中，做一些數據準備、配置拉取等相關操作：
再次重啓一下項目，因爲需要執行兩個 Bean 的初始化動作，各需要 5s 時間，而且是串行執行，所以啓動時間直接來到了 11.188s：
那麼接下來，就是見證奇蹟的時刻了。
我加上 @SofaAsyncInit 這樣的一個註解：
你先別管這個註解是哪裏來的，從這個註解的名稱你也知道它是幹啥的：異步執行初始化。
這個時候我再啓動項目：
從日誌中可以看到：
whyBean 和 maxBean 的 init 方法是由兩個不同的線程並行執行的。 啓動時間縮短到了 6.049s。
所以 @SofaAsyncInit 這個註解實現了“指定 Bean 的初始化方法實現異步化”。
你想想，如果你有 10 個 Bean，每個 Bean 都需要 1s 的時間做初始化，總計 10s。
但是這些 Bean 之間其實不需要串行初始化，那麼用這個註解，並行只需要 1s，搞定。
到這裏，你算是看到了這樣的東西存在，屬於“我看到了”。
接下來，我們進入到“我會用了”這個環節。
怎麼來的。
在解讀原理之前，我還得告訴你這個註解到底是怎麼來的。
它屬於 SOFABoot 框架裏面的註解，首先你得把你的 SpringBoot 修改爲 SOFABoot。
這一步參照官方文檔中的“快速開始”部分，非常的簡單：
https://www.sofastack.tech/projects/sofa-boot/quick-start/
第一步就是把項目中 pom.xml 中的：
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>${spring.boot.version}</version>
<relativePath/>
</parent>
替換爲：
<parent>
<groupId>com.alipay.sofa</groupId>
<artifactId>sofaboot-dependencies</artifactId>
<version>${sofa.boot.version}</version>
</parent>
這裏的 ${sofa.boot.version} 指定具體的 SOFABoot 版本，我這裏使用的是最新的 3.18.0 版本。
然後我們要使用 @SofaAsyncInit 註解，所以需要引入以下 maven：
<dependency>
<groupId>com.alipay.sofa</groupId>
<artifactId>runtime-sofa-boot-starter</artifactId>
</dependency>
對於 pom.xml 文件的變化，就只有這麼一點：
最後，在工程的 application.properties 文件下添加 SOFABoot 工程一個必須的參數配置，spring.application.name，用於標示當前應用的名稱
# Application Name
spring.application.name=SOFABoot Demo
就搞定了，我就完成了一個從 SpringBoot 切換爲 SOFABoot 這個大動作。
當然了，我這個是一個 Demo 項目，結構和 pom 依賴都非常簡單，所以切換起來也非常容易。如果你的項目比較大的話，可能會遇到一些兼容性的問題。
但是，注意我要說但是了。
你是在學習摸索階段，Demo 一定要簡單，越小越好，越純淨越好。所以這個切換的動作對你搭建的一個全新的 Demo 項目來說沒啥難度，不會遇到任何問題。
這個時候，你就可以使用 @SofaAsyncInit 註解了：
到這裏，恭喜你，會用了。
拿來吧你
不知道你看到這裏是什麼感受。
反正對於我來說，如果僅僅是爲了讓我能使用這個註解，達到異步初始化的目的，要讓我從熟悉的 SpringBoot 修改爲聽都沒聽過的 SOFABoot，即使這個框架背後有阿里給它背書，我肯定也是不會這麼幹的。
所以，對於這一類“人有我無”的東西，我都是採取“拿來吧你”策略。
你想，最開始的我就說了，SOFABoot 是 SpringBoot 的變種，它的底層還是 SpringBoot。
而 SOFABoot 又是開源的，整個項目的源碼我都有了：
https://github.com/sofastack/sofa-boot/blob/master/README_ZH.md
從其中剝離出一個基於 SpringBoot 做的小功能，融入到我自己的 SpringBoot 項目中，還玩意難道不是手到擒來的事情？
不過就是稍微高級一點的 cv 罷了。
首先，你得把 SOFABoot 的源碼下載下來，或者在另外的一個項目中引用它，把自己的項目恢復爲一個 SpringBoot 項目。
我這邊是直接把 SOFABoot 源碼搞下來了，先把源碼裏面的 @SofaAsyncInit 註解粘到項目裏面來，然後從 @SofaAsyncInit 註解入手，發現除了測試類只有一個 AsyncInitBeanFactoryPostProcessor 類在對其進行使用：
所以把這個類也搬運過來。
搬運過來之後你會發現有一些類找不到導致報錯：
針對這部分類，你可以採取無腦搬運的方式，也可以稍加思考替換一些。
比如我就分爲了兩種類型：
標號爲 ① 的部分，我是直接粘貼到自己的項目中，然後使用項目中的類。
標號爲 ② 的部分，比如 BeanLoadCostBeanFactory 和 SofaBootConstants，他們的目的是爲了獲取一個 moduleName 變量：
我也不知道這個 moduleName 是啥，所以我採取的策略是自己指定一個：
至於 ErrorCode 和 SofaLogger，日誌相關的，就用自己項目裏面的日誌就行了。
就是這個意思：
這樣處理完成之後，AsyncInitBeanFactoryPostProcessor 類不報錯了，接着看這個類在哪裏使用到了。
就這樣順藤摸瓜，最後搬運完成之後，就是這些類移過來了：
除了這些類之外，你還會把這個 spring.factories 搬運過來，在項目啓動時把這幾個相關的類加載進去：
然後再次啓動這個和 SOFABoot 沒有一點關係的項目：
你會發現，你的項目也具備異步初始化 Bean 的功能了。
你要再進一步，把它直接封裝爲一個 spring-boot-starter-asyncinitbean，發佈到你們公司的私服裏面。
其他團隊也能開箱即用的使用這個功能了。
別問，問就是你自己獨立開發出來的，掌握全部源碼，技術風險可控：
啃原理
在開始啃原理之前，我先多比比兩句。
我寫文章的時候，爲什麼要把“拿來吧你”這一小節放在“啃原理”之前，我是有考慮的。
當我們把“異步初始化”這個功能點剝離出來之後，你會發現，要實現這個功能，一共也沒涉及到幾個類。
聚焦點從一整個項目變成了幾個類而已，至少從感官上不會覺得那麼的難，對閱讀其源碼產生太大的抗拒心理。
而我之前很多關於源碼閱讀的文章，都強調過這一點：帶着疑問去調試源碼，要抓住主幹，謹防走偏。
前面這一小節，不過是把這一句話具化了而已。即使沒有把這些類剝離出來，你直接基於 SOFABoot 來調試這個功能。在你搞清楚“異步初始化”這個功能的實現原理之前，理論上你的關注點和注意力不應該被上面這些類之外的任何一個類給吸引走。
接下來，我們就帶你啃一下原理。
關於原理部分，我們的突破口肯定是看 @SofaAsyncInit 這個註解的在哪個地方被解析的。
你仔細看這個註解裏面有一個 value 屬性，默認爲 true，上面的註解說：用來標註是否應該對 init 方法進行異步調用。
而使用到這個 value 值的地方，就只有下面這一個地方：
com.alipay.sofa.runtime.spring.AsyncInitBeanFactoryPostProcessor#registerAsyncInitBean
判斷爲 true 的時候，執行了一個 registerAsyncInitBean 方法。
從方法名稱也知道，它是把可以異步執行的 init 方法的 Bean 收集起來。
所以看源碼可以看出，這裏面是用 Map 來進行的存儲，提供了一個 register 和 get 方法：
那麼這個 Map 裏面到底放的是啥呢？
我也不知道，打個斷點瞅一眼，不就行了：
通過斷點調試，我們知道這個裏面把項目中哪些 Bean 可以異步執行 init 方法通過 Map 存放了起來。
那麼問題就來了：它怎麼知道哪些 Bean 可以異步執行 init 呢？
很簡單啊，因爲我在對應的 Bean 上打上了 @SofaAsyncInit 註解。所以可以通過掃描註解的方式找到這些 Bean。
所以你說 AsyncInitBeanFactoryPostProcessor 這個類是在幹啥？
肯定核心邏輯就是在解析標註了 @SofaAsyncInit 註解的地方嘛。
到這裏，我們通過註解的 value 屬性，找到了 AsyncInitBeanHolder 這個關鍵類。
知道了這個類裏面有一個 Map，裏面維護的是所有可以異步執行 init 方法的 Bean 和其對應的 init 方法。
好，你思考一下，接下來應該幹啥？
接下來肯定是看哪個地方在從這個 Map 裏面獲取數據出來，獲取數據的時候，就說明是要異步執行這個 Bean 的 init 方法的時候。
不然它把數據放到 Map 裏面幹啥？玩嗎？
調用 getAsyncInitMethodName 方法的地方，也在 AsyncProxyBeanPostProcessor 類裏面：
com.alipay.sofa.runtime.spring.AsyncProxyBeanPostProcessor#postProcessBeforeInitialization
AsyncProxyBeanPostProcessor 類實現了 BeanPostProcessor 接口，並重新了其 postProcessBeforeInitialization 方法。
在這個 postProcessBeforeInitialization 方法裏面，執行了從 Map 裏面拿對象的動作。
如果獲取到了則通過 AOP 編程，編織進一個 AsyncInitializeBeanMethodInvoker 方法。
把 bean, beanName, methodName 都傳遞了進去：
所以關鍵點，就在 AsyncInitializeBeanMethodInvoker 裏面，因爲這個裏面有真正判斷是否要進行異步初始化的邏輯，主要解讀一下這個類。
首先，關注一下它的這三個參數：
initCountDownLatch：是 CountDownLatch 對象，其中 count 初始化爲 1 isAsyncCalling：表示是否正在異步執行 init 方法。 isAsyncCalled：表示是否已經異步執行過 init 方法。
通過這三個字段，就可以感知到一個 Bean 是否已經或者正在異步執行其 init 方法。
這個類的核心邏輯就是把可以異步執行、但是還沒有執行 init 方法的 bean ，把它的 init 方法扔到線程池裏面去執行：
看一下在上面的 invoke 方法中的 if 方法：
if (!isAsyncCalled && methodName.equals(asyncMethodName))
isAsyncCalled，首先判斷是否已經異步執行過這個 bean 的 init 方法了。
然後看看 methodName.equals(asyncMethodName)，要反射調用的方法是否是之前在 map 中維護的 init 方法。
如果都滿足，就扔到線程池裏面去執行，這樣就算是完成了異步 init。
如果不滿足呢？
首先，你想想不滿足的時候說明什麼情況？
是不是說明一個 Bean 的 init 方法在項目啓動過程中不只被調用一次。
就像是這樣：
雖然，我不知道爲什麼一個 Bean 要執行兩次 init 方法，大概率是代碼寫的有問題。
但是我不說，我也不給你拋出異常，我反正就是給你兼容了。
所以，這段代碼就是在處理這個情況：
如果發現有多次調用，那麼只要第一次異步初始化完成了，即 isAsyncCalling 爲 false ，你可以繼續執行反射調用初始化方法的動作。
這個 invoke 方法的邏輯就是這樣，主要是有一個線程池在裏面。
那麼這個線程池是哪裏來的呢？
com.alipay.sofa.runtime.spring.async.AsyncTaskExecutor
在第一次 submit 任務的時候，框架會幫我們初始化一個線程池出來。
然後通過這個線程池幫我們完成異步初始化的目標。
所以你想想，整個過程是非常清晰的。首先找出來哪些 Bean 上標註了 @SofaAsyncInit 註解，找個 Map 維護起來，接着搞個 AOP 切面，看看哪些 Bean 能在 Map 裏面找到，在線程池裏面通過動態代理，調用其 init 方法。
就完了。
對不對？
好，那麼問題就來了？
爲什麼我不直接在 init 方法裏面搞個線程池呢，就像是這樣。
先注入一個自定義線程池，同時註釋掉 @SofaAsyncInit 註解：
在指定 Bean 的 init 方法中使用該線程池：
這也不也是能達到“異步初始化”的目的嗎？
你說對不對？
不對啊，對個錘子對。
你看啓動日誌：
服務已經啓動完成了，但是 4s 之後，Bean 的 init 方法才執行完畢。
在這期間，如果有請求要使用對應的 Bean 怎麼辦？
拿着一個還未執行完成 init 方法的 Bean 框框一頓用，這畫面想想就很美。
所以怎麼辦？
我也不知道，看一下 SOFABoot 裏面是怎麼解決這個問題的。
在我們前面提到的線程池裏面，有這樣的一個方法：
com.example.asyncthreadpool.spring.AsyncTaskExecutor#ensureAsyncTasksFinish
在這個方法裏面，調用了 future 的 get 方法進行阻塞等待。當所有的 future 執行完成之後，會關閉線程池。
這個 FUTURES 是什麼玩意，怎麼來的？
它就是執行 submitTask 方法時，維護進行去的，裏面裝的就是一個個異步執行的 init 方法：
所以它通過這個方法可以確保能感知到所有的通過這個線程池執行的 init 方法都執行完畢。
現在，方法有了，你先思考一下，我們什麼時候觸發這個方法的調用呢？
是不是應該在 Spring 容器告訴你：小老弟，我這邊所有的 Bean 都搞定了，你這邊啥情況了？
這個時候你就需要調用一下這個方法。
而 Spring 容器加載完成之後，會發布這樣的一個事件。也就是它：
所以，SOFABoot 的做法就是監聽這個事件：
com.example.asyncthreadpool.spring.AsyncTaskExecutionListener
這樣，即可確保在異步線程中執行的 init 方法的 Bean 執行完成之後，容器纔算啓動成功，對外提供服務。
到這裏，原理部分我算是講完了。
但是寫到這裏的時候，我突然冒出了一個寫之前沒有過的想法：在整個實現的過程中，最關鍵的有兩個東西：
一個 Map：裏面維護的是所有可以異步執行 init 方法的 Bean 和其對應的 init 方法。 一個線程池：異步執行 init 方法。
而這個 Map 是怎麼來的？
不是通過掃描 @SofaAsyncInit 註解得到的嗎？
那麼掃描出來的 @SofaAsyncInit 怎麼來的？
不就是我寫代碼的時候主動標註上去的嗎？
所以，我們是不是可以完全不用 Map ，直接使用異步線程池：
剩去中間環節，直接一步到位，只需要留下兩個類即可：
我這裏把這個兩個類貼出來。
AsyncTaskExecutionListener：
public class AsyncTaskExecutionListener implements PriorityOrdered,
ApplicationListener<ContextRefreshedEvent>,
ApplicationContextAware {
private ApplicationContext applicationContext;
@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
if (applicationContext.equals(event.getApplicationContext())) {
AsyncTaskExecutor.ensureAsyncTasksFinish();
}
}
@Override
public int getOrder() {
return Ordered.HIGHEST_PRECEDENCE + 1;
}
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
}
AsyncTaskExecutor：
@Slf4j
public class AsyncTaskExecutor {
protected static final int CPU_COUNT = Runtime.getRuntime().availableProcessors();
protected static final AtomicReference<ThreadPoolExecutor> THREAD_POOL_REF = new AtomicReference<ThreadPoolExecutor>();
protected static final List<Future> FUTURES = new ArrayList<>();
public static Future submitTask(Runnable runnable) {
if (THREAD_POOL_REF.get() == null) {
ThreadPoolExecutor threadPoolExecutor = createThreadPoolExecutor();
boolean success = THREAD_POOL_REF.compareAndSet(null, threadPoolExecutor);
if (!success) {
threadPoolExecutor.shutdown();
}
}
Future future = THREAD_POOL_REF.get().submit(runnable);
FUTURES.add(future);
return future;
}
private static ThreadPoolExecutor createThreadPoolExecutor() {
int threadPoolCoreSize = CPU_COUNT + 1;
int threadPoolMaxSize = CPU_COUNT + 1;
log.info(String.format(
"create why-async-init-bean thread pool, corePoolSize: %d, maxPoolSize: %d.",
threadPoolCoreSize, threadPoolMaxSize));
return new ThreadPoolExecutor(threadPoolCoreSize, threadPoolMaxSize, 30,
TimeUnit.SECONDS, new LinkedBlockingQueue<>(), new ThreadPoolExecutor.CallerRunsPolicy());
}
public static void ensureAsyncTasksFinish() {
for (Future future : FUTURES) {
try {
future.get();
} catch (Throwable e) {
throw new RuntimeException(e);
}
}
FUTURES.clear();
if (THREAD_POOL_REF.get() != null) {
THREAD_POOL_REF.get().shutdown();
THREAD_POOL_REF.set(null);
}
}
}
你只需要把這兩個類,一共 68 行代碼，粘到你的項目中，然後把 AsyncTaskExecutionListener 以 @Bean 的方式注入：
@Bean
public AsyncTaskExecutionListener asyncTaskExecutionListener() {
return new AsyncTaskExecutionListener();
}
恭喜你，你項目中的 Bean 也可以異步執行 init 方法了，使用方法就像這樣式兒的：
但是，如果你要對比這兩種寫的法的話：
肯定是選註解嘛，優雅的一比。
所以，我現在問你一個問題：清理聊聊異步初始化 Bean 的思路。
然後在追問你一個問題：如果通過自定義註解的方式實現？需要用到 Spring 的那些擴展點？
還思考個毛啊，不就是這個過程嗎？
回想一下前面的內容，是不是品出點味道了，是不是有點感覺了，是不是覺得自己又行了？
其實說真的，這個方案，當需要人來主動標識哪些 Bean 是可以異步初始化的時候，就已經“輸了”，已經不夠驚豔了。
但是，你想想本文只是想教你“異步初始化”這個點嗎？
不是的，只是以“異步初始化”爲抓手，試圖教你一種源碼解讀的方法，找到撕開 Spring 框架的又一個口子，這纔是重要的。
最後，前兩天阿里開發者公衆號也發佈了一篇叫《Bean異步初始化，讓你的應用啓動飛起來》的文章，想要達成的目的一樣，但是最終的落地方案可以說差距很大。這篇文章沒有具體的源碼，但是也可以對比着看一下，取長補短，融會貫通。
行了，我就帶你走到這了，我只是給你指個路，剩下的路就要你自己走了。
天黑路滑，燈火昏暗，抓住主幹，及時回頭。