前言
在 2021 年這個小學作文中的未來年份，沒有想象中的汽車滿天飛，也沒有實現機器人滿地跑。但牛逼的是我們都有一個共識： 知乎達到了人均 “謝邀~ 人在美國剛下飛機”的生活水平，虎撲的人均收入也在 30W+ ，還有就是程序員都人均精通 SpringBoot ，哪怕和算法聊技術一言不合就滿嘴 SpringCould 分布式、微服務，然而實際操作可能是 分步試 、偽服務 ... 你一個小小系統開這么多應用啟動不難受？(不難受因為可以裝 13) SpringBoot 這啟動速度也確實令人捉急，每個應用 5 分鍾改個小功能，編碼五分鍾部署倆小時。 so 如何更加優雅快速的 啟動 SpringBoot 應用 (滿足裝 13 的欲望) 呢？
其實我們都比較清楚大部分的啟動時間是由於 Spring 需要加載各種 Bean 導致啟動速度下降的，那么對於那些不是特別重要的 Bean 我們是不是可以讓他再起一個線程做 Bean 初始化，不阻塞主線程啟動，這樣啟動速度不就起來了么，說干就干！
那你肯定會問，我們咋判斷一個 Bean 加載時間長短，找出那些 拉跨的Bean 呢？內心一陣嘲諷，嘴角泛出一陣冷笑后 不慌不忙的道來：“這對於精通 Spring 框架的我來說不是小菜一碟么 ”。我掐指一算，就知道是哪幾個 Bean 拉跨。
統計 Bean 初始化時間
簡單做法就是通過 BeanPostProcessor ，祭出這個神器就能干倒一半的 LSP，很多使用 Spring 的 LSP 其實都不太知道這個玩意，那他到底是個什么玩意呢？簡單來講就是 Spring 初始化 Bean 的鈎子函數。 Bean 是否加載，加載的是哪個 Bean 以及修改 Bean 的相關屬性都可以通過這個鈎子函數搞定。這就是一個活生生的 Spring 后門，學會了他 Spring 框架任你擺布。
后面我會專門開一篇文章去講解 BeanPostProcessor 如何幫你加載 Bean，以及如何利用這個后門搞事情。
所以我們現在講講如何用 BeanPostProcessor 統計 Bean 的初始化時間。不多 BB 直接上代碼：
我們編寫了 BeanInitCostTimeBeanPostProcessor 繼承了 BeanPostProcessor 實現了 postProcessBeforeInitialization 和 postProcessAfterInitialization 分別代表了 Bean 初始化之前和之后，簡單記錄了 Bean 初始化開始時間，然后用結束時間減去開始時間就得到了具體的初始化時間。
我專門在 Spring 容器中放了一個加載時間很長的測試 Bean ，代碼如下
效果如下：
異步 Bean 實操
異步 Bean 異步 Bean ，首先這個 Bean 需要是個異步的，那如何將一個 Bean 包裝成異步的呢？首先異步 Bean 肯定需要繼承原來的 Bean 需要保證是同一種類型的，然后重寫他的 init 方法。代碼操作如下：
但是這么寫並不是很優雅，假如我們還需要在初始化 Bean 的時候做一些其他操作，直接繼承是不方便的。所以必須祭出 Spring 中的另外一個組件了，工廠 Bean，學名 FactoryBean 這個要和另外一個叫做 BeanFactory 的大佬區分開。 工廠 Bean 顧名思義就是這個玩意也是一個 Bean 只是他的主要職責是作為工廠，通常用於生成特定類型的 Bean ，那么我們就有一個騷操作了，讓這個工廠生產的 Bean 就是它自己，而且中間還能定義很多額外的邏輯，不多 BB 上代碼
然后通過異步 Bean 去加載我們看看前后的差別
優化之前：
優化之后：
可以看到優化后 1.4s 應用就啟動完成了，而且耗時的 Bean 可以讓他慢慢加載，在應用啟動完成后這個 Bean 才完全被加載。
嘮叨
最近有點忙成狗，從四月就斷更到現在了，今天抽個周末的時候終於寫完了。
不過最近看了好幾本書，也准備抽點時間寫寫讀后感了，非常推薦大家看看 《零秒思考》 ，同時寫點個人的小思考： 一旦適應了用語言表達腦海中的意向和感覺，漸漸地就不會為如何表達自己的心情和想法而苦惱，流暢清晰的表達能夠更快的與對方溝通讓對方心領神會。表達不善往往便會產生一種想也是白想的放棄心理，由此甚至連思考本身也放棄了，不思考人就不會成長，不經歷思考解決手頭的事情人就會失去干勁變得無聊。