面試官必問：說說 Spring Bean 的實例化過程？

來源：juejin.cn/post/6929672218322731022

• 不貼代碼，Spring的Bean實例化過程應(yīng)該是怎樣的？
• 兩個階段
• 容器啟動階段
• Bean實例化階段

不貼代碼，Spring的Bean實例化過程應(yīng)該是怎樣的？

對于寫Java的程序員來說，Spring已經(jīng)成為了目前最流行的第三方開源框架之一，在我們充分享受Spring IOC容器帶來的紅利的同時，我們也應(yīng)該考慮一下Spring這個大工廠是如何將一個個的Bean生產(chǎn)出來的，本期我們就一起來討論一下Spring中Bean的實例化過程。

這里我們并不會詳細的分析源代碼，只是給出Spring在完成哪些工作的時候使用到了什么類，這些類具體的職責(zé)都是什么，如果我們要弄清楚Spring Bean實例化的內(nèi)幕與詳細信息，那么可以看哪些源代碼? 至于具體的詳細的代碼信息，大家可以查看Spring相關(guān)類的代碼。

兩個階段

這里首先聲明一下，Spring將管理的一個個的依賴對象稱之為Bean,這從xml配置文件中也可以看出。

Spring IOC容器就好像一個生產(chǎn)產(chǎn)品的流水線上的機器，Spring創(chuàng)建出來的Bean就好像是流水線的終點生產(chǎn)出來的一個個精美絕倫的產(chǎn)品。既然是機器，總要先啟動，Spring也不例外。因此Bean的一生從總體上來說可以分為兩個階段：

1. 容器啟動階段
2. Bean實例化階段

容器的啟動階段做了很多的預(yù)熱工作，為后面Bean的實例化做好了充分的準(zhǔn)備，我們首先看一下容器的啟動階段都做了哪些預(yù)熱工作。

容器啟動階段

1、配置元信息

我們說Spring IOC容器將對象實例的創(chuàng)建與對象實例的使用分離，我們的業(yè)務(wù)中需要依賴哪個對象不再依靠我們自己手動創(chuàng)建，只要向Spring要，Spring就會以注入的方式交給我們需要的依賴對象。但是，你不干，我不干，總要有人干，既然我們將對象創(chuàng)建的任務(wù)交給了Spring，那么Spring就需要知道創(chuàng)建一個對象所需要的一些必要的信息。而這些必要的信息可以是Spring過去支持最完善的xml配置文件，或者是其他形式的例如properties的磁盤文件，也可以是現(xiàn)在主流的注解，甚至是直接的代碼硬編碼。總之，這些創(chuàng)建對象所需要的必要信息稱為配置元信息。

"role"?class="com.wbg.springxmlbean.entity.Role">
????
????"id"?value="1"/>
????"roleName"?value="高級工程師"/>
????"note"?value="重要人員"/>

2、BeanDefination

我們大家都知道，在Java世界中，萬物皆對象，散落于程序代碼各處的注解以及保存在磁盤上的xml或者其他文件等等配置元信息，在內(nèi)存中總要以一種對象的形式表示，就好比我們活生生的人對應(yīng)到Java世界中就是一個Person類，而Spring選擇在內(nèi)存中表示這些配置元信息的方式就是BeanDefination，這里我們不會去分析BeanDefination的代碼，感興趣的可以去看相關(guān)源碼，*這里我們只是需要知道配置元信息被加載到內(nèi)存之后是以BeanDefination的形存在的即可。 *

3、BeanDefinationReader

大家肯定很好奇，我們是看得懂Spring中xml配置文件中一個個的Bean定義，但是Spring是如何看懂這些配置元信息的呢？這個就要靠我們的BeanDefinationReader了。

不同的BeanDefinationReader就像葫蘆兄弟一樣，各自擁有各自的本領(lǐng)。如果我們要讀取xml配置元信息，那么可以使用XmlBeanDefinationReader。如果我們要讀取properties配置文件，那么可以使用PropertiesBeanDefinitionReader加載。而如果我們要讀取注解配置元信息，那么可以使用 AnnotatedBeanDefinitionReader加載。我們也可以很方便的自定義BeanDefinationReader來自己控制配置元信息的加載。例如我們的配置元信息存在于三界之外，那么我們可以自定義From天界之外BeanDefinationReader。

總的來說，BeanDefinationReader的作用就是加載配置元信息，并將其轉(zhuǎn)化為內(nèi)存形式的BeanDefination，存在某一個地方，至于這個地方在哪里，不要著急，接著往下看！

4、BeanDefinationRegistry

執(zhí)行到這里，總算不遺余力的將存在于各處的配置元信息加載到內(nèi)存，并轉(zhuǎn)化為BeanDefination的形式，這樣我們需要創(chuàng)建某一個對象實例的時候，找到相應(yīng)的BeanDefination然后創(chuàng)建對象即可。那么我們需要某一個對象的時候，去哪里找到對應(yīng)的BeanDefination呢？這種通過Bean定義的id找到對象的BeanDefination的對應(yīng)關(guān)系或者說映射關(guān)系又是如何保存的呢？這就引出了BeanDefinationRegistry了。

Spring通過BeanDefinationReader將配置元信息加載到內(nèi)存生成相應(yīng)的BeanDefination之后，就將其注冊到BeanDefinationRegistry中，BeanDefinationRegistry就是一個存放BeanDefination的大籃子，它也是一種鍵值對的形式，通過特定的Bean定義的id，映射到相應(yīng)的BeanDefination。

5、BeanFactoryPostProcessor

BeanFactoryPostProcessor是容器啟動階段Spring提供的一個擴展點，主要負責(zé)對注冊到BeanDefinationRegistry中的一個個的BeanDefination進行一定程度上的修改與替換。例如我們的配置元信息中有些可能會修改的配置信息散落到各處，不夠靈活，修改相應(yīng)配置的時候比較麻煩，這時我們可以使用占位符的方式來配置。例如配置Jdbc的DataSource連接的時候可以這樣配置:

"dataSource"
????class="org.apache.commons.dbcp.BasicDataSource"
????destroy-method="close">
????"maxIdle"?value="${jdbc.maxIdle}">
????"maxActive"?value="${jdbc.maxActive}">
????"maxWait"?value="${jdbc.maxWait}">
????"minIdle"?value="${jdbc.minIdle}">

????"driverClassName"
????????value="${jdbc.driverClassName}">
????
????"url"?value="${jdbc.url}">

????"username"?value="${jdbc.username}">
????"password"?value="${jdbc.password}">

BeanFactoryPostProcessor就會對注冊到BeanDefinationRegistry中的BeanDefination做最后的修改，替換$占位符為配置文件中的真實的數(shù)據(jù)。

至此，整個容器啟動階段就算完成了，容器的啟動階段的最終產(chǎn)物就是注冊到BeanDefinationRegistry中的一個個BeanDefination了，這就是Spring為Bean實例化所做的預(yù)熱的工作。讓我們再通過一張圖的形式回顧一下容器啟動階段都是搞了什么事吧。

Bean實例化階段

需要指出，容器啟動階段與Bean實例化階段存在多少時間差，Spring把這個決定權(quán)交給了我們程序員(是不是瞬間開心了一點點！）。如果我們選擇懶加載的方式，那么直到我們伸手向Spring要依賴對象實例之前，其都是以BeanDefinationRegistry中的一個個的BeanDefination的形式存在，也就是Spring只有在我們需要依賴對象的時候才開啟相應(yīng)對象的實例化階段。而如果我們不是選擇懶加載的方式，容器啟動階段完成之后，將立即啟動Bean實例化階段，通過隱式的調(diào)用所有依賴對象的getBean方法來實例化所有配置的Bean并保存起來。

接下來我們就聊一聊Bean實例化過程的那些事兒~

1、對象創(chuàng)建策略

到了這個時候，Spring就開始真刀真槍的干了，對象的創(chuàng)建采用了策略模式，借助我們前面BeanDefinationRegistry中的BeanDefination,我們可以使用反射的方式創(chuàng)建對象，也可以使用CGlib字節(jié)碼生成創(chuàng)建對象。同時我們可以靈活的配置來告訴Spring采用什么樣的策略創(chuàng)建指定的依賴對象。Spring中Bean的創(chuàng)建是策略設(shè)計模式的經(jīng)典應(yīng)用。這個時候，內(nèi)存中應(yīng)該已經(jīng)有一個我們想要的具體的依賴對象的實例了，但是故事的發(fā)展還沒有我們想象中的那么簡單。

關(guān)于策略模式有不了解的可以查閱相關(guān)書籍，或者網(wǎng)上相關(guān)資料，這是設(shè)計模式相關(guān)的內(nèi)容，本文主要關(guān)注Bean實例化的整體流程，設(shè)計模式相關(guān)知識不在討論。

2、BeanWrapper——對象的外衣

Spring中的Bean并不是以一個個的本來模樣存在的，由于Spring IOC容器中要管理多種類型的對象，因此為了統(tǒng)一對不同類型對象的訪問，*Spring給所有創(chuàng)建的Bean實例穿上了一層外套 *，這個外套就是BeanWrapper(關(guān)于BeanWrapper的具體內(nèi)容感興趣的請查閱相關(guān)源碼)。BeanWrapper實際上是對反射相關(guān)API的簡單封裝，使得上層使用反射完成相關(guān)的業(yè)務(wù)邏輯大大的簡化，我們要獲取某個對象的屬性，調(diào)用某個對象的方法，現(xiàn)在不需要在寫繁雜的反射API了以及處理一堆麻煩的異常，直接通過BeanWrapper就可以完成相關(guān)操作，簡直不要太爽了。

3、設(shè)置對象屬性

上一步包裹在BeanWrapper中的對象還是一個少不經(jīng)事的孩子，需要為其設(shè)置屬性以及依賴對象。

• 對于基本類型的屬性，如果配置元信息中有配置，那么將直接使用配置元信息中的設(shè)置值賦值即可，即使基本類型的屬性沒有設(shè)置值，那么得益于JVM對象實例化過程，屬性依然可以被賦予默認的初始化零值。
• 對于引用類型的屬性，Spring會將所有已經(jīng)創(chuàng)建好的對象放入一個Map結(jié)構(gòu)中，此時Spring會檢查所依賴的對象是否已經(jīng)被納入容器的管理范圍之內(nèi)，也就是Map中是否已經(jīng)有對應(yīng)對象的實例了。如果有，那么直接注入，如果沒有,那么Spring會暫時放下該對象的實例化過程，轉(zhuǎn)而先去實例化依賴對象，再回過頭來完成該對象的實例化過程。

這里有一個Spring中的經(jīng)典問題，那就是Spring是如何解決循環(huán)依賴的？

這里簡單提一下，Spring是通過三級緩存解決循環(huán)依賴，并且只能解決Setter注入的循環(huán)依賴，請大家思考一下如何解決？為何只能是Setter注入？詳細內(nèi)容可以查閱相關(guān)博客，文檔，書籍。

4、檢查Aware相關(guān)接口

我們知道，我們?nèi)绻胍蕾嘢pring中的相關(guān)對象，使用Spring的相關(guān)API,那么可以實現(xiàn)相應(yīng)的Aware接口，Spring IOC容器就會為我們自動注入相關(guān)依賴對象實例。Spring IOC容器大體可以分為兩種，BeanFactory提供IOC思想所設(shè)想所有的功能，同時也融入AOP等相關(guān)功能模塊，可以說BeanFactory是Spring提供的一個基本的IOC容器。ApplicationContext構(gòu)建于BeanFactory之上，同時提供了諸如容器內(nèi)的時間發(fā)布、統(tǒng)一的資源加載策略、國際化的支持等功能，是Spring提供的更為高級的IOC容器。

講了這么多，其實就是想表達對于BeanFactory來說，這一步的實現(xiàn)是先檢查相關(guān)的Aware接口，然后去Spring的對象池(也就是容器，也就是那個Map結(jié)構(gòu))中去查找相關(guān)的實例(例如對于ApplicationContextAware接口，就去找ApplicationContext實例)，也就是說我們必須要在配置文件中或者使用注解的方式，將相關(guān)實例注冊容器中，BeanFactory才可以為我們自動注入。

而對于ApplicationContext，由于其本身繼承了一系列的相關(guān)接口，所以當(dāng)檢測到Aware相關(guān)接口，需要相關(guān)依賴對象的時候，ApplicationContext完全可以將自身注入到其中，ApplicationContext實現(xiàn)這一步是通過下面要講到的東東——BeanPostProcessor。

例如ApplicationContext繼承自ResourceLoader和MessageSource，那么當(dāng)我們實現(xiàn)ResourceLoaderAware和MessageSourceAware相關(guān)接口時，就將其自身注入到業(yè)務(wù)對象中即可。

5、BeanPostProcessor前置處理

唉？剛才那個是什么Processor來？相信剛看這兩個東西的人肯定有點暈乎了，我當(dāng)初也是，不過其實也好區(qū)分，只要記住BeanFactoryPostProcessor存在于容器啟動階段而BeanPostProcessor存在于對象實例化階段，BeanFactoryPostProcessor關(guān)注對象被創(chuàng)建之前 * 那些配置的修修改改，縫縫補補，而BeanPostProcessor階段關(guān)注對象已經(jīng)被創(chuàng)建之后 * 的功能增強，替換等操作，這樣就很容易區(qū)分了。

BeanPostProcessor與BeanFactoryPostProcessor都是Spring在Bean生產(chǎn)過程中強有力的擴展點。如果你還對它感到很陌生，那么你肯定知道Spring中著名的AOP(面向切面編程)，其實就是依賴BeanPostProcessor對Bean對象功能增強的。

BeanPostProcessor前置處理就是在要生產(chǎn)的Bean實例放到容器之前，允許我們程序員對Bean實例進行一定程度的修改，替換等操作。

前面講到的ApplicationContext對于Aware接口的檢查與自動注入就是通過BeanPostProcessor實現(xiàn)的，在這一步Spring將檢查Bean中是否實現(xiàn)了相關(guān)的Aware接口，如果是的話，那么就將其自身注入Bean中即可。Spring中AOP就是在這一步實現(xiàn)的偷梁換柱，產(chǎn)生對于原生對象的代理對象，然后將對源對象上的方法調(diào)用，轉(zhuǎn)而使用代理對象的相同方法調(diào)用實現(xiàn)的。

6、自定義初始化邏輯

在所有的準(zhǔn)備工作完成之后，如果我們的Bean還有一定的初始化邏輯，那么Spring將允許我們通過兩種方式配置我們的初始化邏輯：(1)InitializingBean (2)配置init-method參數(shù)

一般通過配置init-method方法比較靈活。

7、BeanPostProcess后置處理

與前置處理類似，這里是在Bean自定義邏輯也執(zhí)行完成之后，Spring又留給我們的最后一個擴展點。我們可以在這里在做一些我們想要的擴展。

8、自定義銷毀邏輯

這一步對應(yīng)自定義初始化邏輯，同樣有兩種方式：(1)實現(xiàn)DisposableBean接口 (2)配置destory-method參數(shù)。

這里一個比較典型的應(yīng)用就是配置dataSource的時候destory-method為數(shù)據(jù)庫連接的close()方法。

9、使用

經(jīng)過了以上道道工序，我們終于可以享受Spring為我們帶來的便捷了，這個時候我們像對待平常的對象一樣對待Spring為我們產(chǎn)生的Bean實例，如果你覺得還不錯的話，動手試一下吧！

10、調(diào)用回調(diào)銷毀接口

Spring的Bean在為我們服務(wù)完之后，馬上就要消亡了(通常是在容器關(guān)閉的時候)，別忘了我們的自定義銷毀邏輯，這時候Spring將以回調(diào)的方式調(diào)用我們自定義的銷毀邏輯，然后Bean就這樣走完了光榮的一生！

我們再通過一張圖來一起看一看Bean實例化階段的執(zhí)行順序是如何的？

需要指出，容器啟動階段與Bean實例化階段之間的橋梁就是我們可以選擇自定義配置的延遲加載策略，如果我們配置了Bean的延遲加載策略，那么只有我們在真實的使用依賴對象的時候，Spring才會開始Bean的實例化階段。而如果我們沒有開啟Bean的延遲加載，那么在容器啟動階段之后，就會緊接著進入Bean實例化階段，通過隱式的調(diào)用getBean方法，來實例化相關(guān)Bean。