Spring IOC原始碼研究筆記（2）——ApplicationContext系列

1. Spring IOC原始碼研究筆記（2）——ApplicationContext系列

1.1. 繼承關係

非web環境下，一般來說常用的就兩類ApplicationContext：

• 配置形式為XML的：ClassPathXmlApplicationContext、FileSystemXmlApplicationContext

• 配置形式為註解的：AnnotationConfigApplicationContext

前者的繼承鏈為：AbstractApplicationContext -> AbstractRefreshableApplicationContext -> AbstractRefreshableConfigApplicationContext -> AbstractXmlApplicationContext。

後者的繼承鏈為：AbstractApplicationContext -> GenericApplicationContext。

注意，AbstractRefreshableConfigApplicationContext實現了InitializingBean（回撥為如果自己沒有啟動，那麼就refresh）、BeanNameAware（表明如果它自己作為bean的時候，將會知道自己的bean name）。

GenericApplicationContext還實現了BeanDefinitionRegistry介面：委託給自己持有的DefaultListableBeanFactory實現。

1.2. ApplicationContext

介面，繼承了：ListableBeanFactory、HierachicalBeanFactory、ResourcePatternResovler、MessageSource、ApplicationEventPublisher、EnvironemntCapable。

• 返回：ID、name、display name、啟動時間、父app ctx、自己內部的autowire capable bean factory

1.3. ConfigurableApplicationContext

繼承自ApplicationContext、LifeCycle、Closable。

• 新增了一些配置的功能：

  • 設定id

  • 設定parent app ctx

  • 設定、獲取environment

  • 設定class loader

  • 新增protocol resolver（來自DefaultResourceLoader）

  • 新增bean factory post processor

  • 新增application listener

• 然後是涉及生命週期的一些方法：

  • refresh

  • close

  • 新增shutdown hook

  • 判斷是否active

1.4. AbstractApplicationContext

AbstractApplicationContext實現了ConfigurableApplicationContext介面。

AbstractApplicaitonContext繼承於DefaultResourceLoader從而實現了ApplicationContext要求的ResourceLoader的方法。

AbstractApplicationContext通過例項欄位持有一個ResourcePatternResolver例項（建構函式中使用自身作為resource loader來new一個PathMatchingResourcePatternResolver），從而通過委託的方式實現了ApplicationContext要求的ResourcePatternResolver的方法。

AbstractApplicationContext通過例項欄位持有一個MessageSource例項（initMessageSource時初始化），從而通過委託的方式實現了ApplicationContext要求的MessageSource中的方法。

AbstractApplicationContext的子類通過持有DefaultListableBeanFactory（AbstractRefreshableApplicationContext、GenericApplicationContext），從而實現了ApplicationContext、ConfigurableAppliationContext暴露BeanFactory的功能。

AbstractApplicationContext通過例項欄位持有LifeCycleProcessor從而通過委託的方式實現了AplicationContext要求的Lifecycle中的方法。

AbstractApplicationContext通過例項欄位持有ApplicationEventMulticaster從而實現了ApplicationContext要求的ApplicationEventMulticaster中的方法。

由上可見，對於ApplicationContext、ConfigurableApplicationContext中定義的方法其實就refresh值得看，其他的方法要不就是簡單的set方法，要麼就是其他的介面而來，被委託給其他類或者繼承自其他類，從而實現。

1.4.1. refresh方法

refresh方法是ApplicationContext最重要的方法了，它定義了

1.4.1.1. prepareRefresh

一個ConfigurableApplicationContext可能被refresh多次：

做了三件事：

• 設定狀態欄位：active（true）、closed（false）、startUpDate（currentTimeMillis）

• 屬性相關：initPropertySource（在Web環境下的ApplicationContext中重寫）、驗證標記為required的屬性是否都可以解析。

• 訊息釋出相關：把applicationListeners設定為第一次refresh之前的樣子。建立一個空的“早期事件容器”（registerListener步驟之前釋出的事件會暫存在這個容器中，在registerListener的時候，取出所有ApplicationListener新增到ApplicationEventMulticaster中，併發布這些暫存的事件，並將該容器置null。）

1.4.1.2. obtainFreshableBeanFactory

refreshBeanFactory是個抽象方法，在子類中實現。

• 對於GenericApplicationContext來說，它的建構函式中就將DefaultListableBeanFactory給new出來了，並持有它，refreshBeanFactory只是給它設定id、以及設定標記位。

• 對於AbstractRefreshableApplicationContext來說：它銷燬舊bean factory，然後建立一個新的bean factory，設定id後，就從xml檔案中載入bean definition。

1.4.1.3. prepareBeanFactory

對beanfactory進行了一些配置：

• 配件設定：

  • 設定beanfactory的bean classloader（application自己的，ResourceLoader中的方法——如果顯式set的話就用set的，沒有的話使用當前執行緒的context classloader，還沒有的話就用ClassUtils的classloader，再沒有的話就用system classloader）

  • bean expression resovler（StandardBeanExpressionResolver）

  • property editor registrar（ResourceEditorRegistrar）。

• 依賴設定：

  • 忽略掉bean一些依賴：EnvironmentAware、ResourceLoaderAware、ApplicationEventPublisherAware、ApplicationContextAware、MessageSourceAware、EmbeddedValueResovlerAware（就算bean依賴於這些型別的bean，也不為它注入這些依賴）。

  • 新增一些現成就能用的依賴：BeanFactory、ResourceLoader、ApplicationEventPublisher、ApplicaitonContext（如果bean依賴這些型別的bean，那麼直接將本AbstractApplicationContext將作為候選的注入值），當有bean依賴這種型別的bean時，直接返回本application context

• 新增bean post processor：ApplicationContextAwareProcessor、ApplicationListenerDetector。

• 如果存在loadTimeWeaver這個名稱的bean（跟aop相關，類載入時織入），那麼給beanfactory設定tempclass loader（bean factory的bean classloader建立一個ContextTypeMatchClassLoader），同時新增一個LoadTimeWeaverAwareProcessor（bpp，他給LoaderTimeWeaver型別的bean設定LoadTimeWeaver，這個LoadTimeWeaver來自bean factory）。

• 將environment中的一些資料封裝為單例bean例項註冊到beanfactory中。

1.4.1.4. postProcessBeanFactory

在AbstractApplicationContext中為空方法，在一些web環境下的子類中被重寫。

1.4.1.5. invokeBeanFactoryPostProcessors

如果bean factory沒有tempClassLoader但註冊了LoadTimeWeaver bean，那麼就新增一個LoadTimeWeaverAwareProcessor這個bpp，然後設定一個ContextTypeMatchClassLoader作為tmpClassLoader。

接下來由於邏輯太長比較複雜，專門抽到PostProcessorRegistrationDelegate類中：

傳入的beanFactoryPostProcessor是此前其他元件直接呼叫AppCtx的addBeanFactoryPostProcessor新增的bean factory postprocessor（在SpringBoot的情況下有：CachingMetadataReaderFactoryPostProcessor、ConfigurationWarningsPostProcessor、PropertySourceOrderingPostProcessor）。

另外一部分bean factory post processor是作為bean definition註冊在bean factory中。（AnnotationConfigApplicationContext在構造時會構造AnnotatedBeanDefinitionReader，進而會往新增一些用於註解處理的bfpp。）

• 如果bean factory實現了BeanDefinitionRegistry介面（一般來說肯定走這個邏輯，因為只有一個DefaultListableBeanFactory）：

  1. 遍歷傳入的bean factory post processor，將其中的bean definition registry post processor和一般的bean factory post processor分開，並用其中的bean definition registry post processor的postProcessBeanDefinitionRegistry方法處理app ctx的bean factory

  2. 然後再從app ctx的bean factory中取出所有PriorityOrdered型別的bean definition registry post processor型別的bean，排序後，用其postProcessBeanDefinitionRegistry方法依次處理app ctx的bean factory，並將其儲存下來以供去重。

  3. 然後再從app ctx的bean factory中取出所有只是Ordered型別的沒用過的bean definition registry post processor型別的bean，排序後，用其postProcessBeanDefinitionRegistry方法依次處理app ctx的bean factory，並將其儲存下來以供去重。

  4. 然後再取出剩下的普通優先順序的沒用過的bean definition registry post processor，用其postProcessBeanDefinitionRegistry方法r處理app ctx的bean factory。注意由於postProcessBeanDefinitionRegistry時可能會向bean factory中註冊新的bean definition registry post processor型別的bean，因此用廣度優先的方式進行不斷的迭代，直到沒有為止。

  5. 將上面的這些bean definition registry post processor按照同樣的順序，使用其postProcessBeanFactory方法來處理bean factory

  6. 將入參中的bean factory post processor的postProcessBeanFactory方法處理bean factory。

• 如果bean factory沒有實現BeanDefinitionRegistry介面（基本不可能走這裡）：

  • 遍歷入參中的bean factory post processor來postProcessBeanFactory。

最後取出BeanFactory中的BeanFactoryPostProcessor型別並且沒用過的Bean，按照PriorityOrdered -> Ordered -> Regular優先順序的順序對BeanFactory進行後處理。

注意：

1. 對於PriorityOrdered、Ordered優先順序的後處理器，它們在處理前都需要進行排序，而regular優先順序的不用排序。

2. 對BDRPP和BFPP的處理不相同，BDRPP在後處理時可能引入新的BDRPP，因此採用廣度優先搜尋的方式，需要多次遍歷Bean Factory中的BDRPP。而BFPP，直接遍歷一次Bean Factory中的BFPP，不進行廣度優先搜尋。

3. 上面的排序，一般使用AnnotationAwareOrderComparator來排序：實現了PriorityOrdered -> 實現了Ordered -> Spring的@Order -> javax的@Priority

整體的順序為：

1. 非bean方式的BDRPP先postProcessBeanDefinitionRegistry

2. bean方式的並且是PriorityOrdered的BDRPP，排序後，postProcessBeanDefinitionRegistry

3. bean方式的並且是Ordered的BDRPP，排序後，postProcessBeanDefinitionRegistry

4. bean方式的非Ordered的BDRPP，postProcessBeanDefinitionRegistry

5. 上面的BDRPP，相同順序來postProcessBeanFactory

6. 非bean方式的BDRPP，postProcessBeanFactory

7. bean方式的並且是PriorityOrdered的BFPP，排序後，postProcessBeanFactory

8. bean方式的並且是Ordered的BFPP，排序後，postProcessBeanFactory

9. bean方式的非Ordered的BFPP，postProcessBeanFactory

1.4.1.6. registerBeanPostProcessors

由於方法太長，委託給PostProcessorRegistrationDelegate這個靜態工具類處理。

新增一個BeanPostProcessorChecker。

再將隱式的以bean形式存在於容器中的BeanPostProcessor取出來：

• 先取出PriorityOrdered型別的，排序後，顯示地新增到bean factory中（addBeanPostProcessor）

• 再取出Ordered型別的，排序後，顯示地新增到bean factory中

• 再取出普通優先順序的，顯示地新增到bean factory中

• 如果上面的BeanPostProcessor還是MergedBeanDefinitionPostProcessor（被稱為internal bean post processor），排序後，再進行一次addBeanPostProcessor（注意這個操作會首先remove然後再add，相當於是說，如果再後面又add了一個之前add過的，就只是把這個往後挪而已。）

• 最後新增一個ApplicationListenerDetector（將其放在最後）。

1.4.1.7. initMessageSource

如果本地beanfactory中沒有messageSource這個bean，那麼new一個DelegatingMessageSource設定好它的parent後（DelegatingMessageSource是HierachicalMessageSource，這個parent要麼是當前app ctx的父app ctx內部的MessageSource，要麼就是父app ctx），交給application context，同時將其作為單例註冊到bean factory中。

1.4.1.8. initApplicationEventMulticaster

ApplicationContext實現了ApplicationEventPublisher介面，這個功能的實現是藉助ApplicationEventMulticaster的（作為欄位）。

這個欄位的例項化在initApplicationEventMulticaster方法中。

如果本地beanFactory中有ApplicaitonEventMulticaster型別的bean，那麼就採用這個bean。（注意一定是本地beanFactory，因為父級beanFactory在釋出事件的時候子beanFactory新增的ApplicationListener不會接收到，而子beanFactory釋出的事件，父beanFactory的application listener會接收到，見publishEvent方法）。

如果本地beanFactory中沒有註冊這個bean的話，原地例項化一個SimpleApplicationEventMulticaster作為欄位，並將其作為singleton註冊到beanFactory中。

1.4.1.9. onRefresh

在AbstractApplicationContext中為空方法，在一些web環境下的子類中被重寫。

1.4.1.10. registerListeners

appctx的ApplicationListener來源有兩個：

• addApplicationListener時新增的ApplicationListener

• 自己管理的ApplicationListener型別的bean。

將appctx的application listener新增到appctx的ApplicationEventMulticaster中，使用它釋出earlyApplicationEvent（appctx還沒有refresh的時候它的publishEvent方法就被呼叫）。

1.4.1.11. finishBeanFactoryInitialization

結束對bean factory的初始化：

1. 如果bean factory中包含conversion service型別的bean，並且bean name為“conversionService，那麼就給bean factory設定conversion service

2. 如果bean factory沒有設定embedded value resolver（StringValueResolver），那麼就用一個lambda表示式當它的StringValueResovler，它的功能就是說，根據appctx的environment的resolvePlaceholders方法來解析字串

3. 提前例項化所有LoadTimeWeaverAware型別的bean

4. 設定bean factory的tmpClassLoader為null

5. 然後凍結bean factory的configuration（DefaultListableBeanFactory）。

6. 提前例項化bean factory中所有singleton object

1.4.1.12. finishRefresh

• clearResourceCaches：DefaultResourceLoader中的方法。

• initLifecycleProcessor：如果bean factory中有LifecycleProcessor型別的bean並且bean name為“lifecycleProcessor“，就將其取出作為當前app ctx的lifecycleProcessor，否則就使用app ctx內部的bean factory來new一個DefaultLifecycleProcessor，將其作為bean註冊到bean factory中，並設定它為appct的lifecycleProcessor。

• 呼叫lifecycleProcessor的onRefresh方法。

• 釋出ContextRefreshedEvent

1.4.1.13. resetCommonCaches

1.4.2. registerShutdownHook方法

這個shutdown hook的作用就是在應用退出的時候，呼叫App Ctx的close方法。

1.4.3. close方法

只有當前還是active時，才會close：

1. CAS設定closed狀態位，釋出ContextClosedEvent

2. 呼叫lifecycle processor的onClose方法

3. 銷燬bean factory中的所有單例bean

4. 關閉BeanFactory——在子類中重寫：

   • 對於GenericApplicationContext來說，只是將持有的BeanFactory的setSerializationId設定為null，依舊持有這個BeanFactory

   • 對於AbstractRefreshableApplicationContext來說，它不僅將BeanFactory的setSerializationId設定為null，而且不再持有改beanfactory

5. 將applicationListeners恢復到第一次refresh之前的狀態

6. 設定active標記位

7. 移除shutdown hook

1.4.4. publishEvent方法

如果釋出的event不是ApplicationEvent，那麼包裝成PlayloadApplicationEvent。

如果此時ApplicationContext還沒有registerListener，那麼將event暫存，否則就將Event通過自己持有的AppliationEventMulticaster釋出出去，告知每個ApplicationListner。

最後將event釋出到父級Application Context中（子容器釋出的事件被父容器感知，父容器釋出的事件子容器不感知）。

1.5. GenericApplicationContext

GenericApplicationContext實現了BeanDefinitionRegistry這個介面，這個介面的功能委託給自己持有的DefaultListableBeanFactory（在建構函式中new這個bean factory）。

GenericApplicationContext還第一次提供了一系列registerBean這個方法，這些方法根據傳入的bean型別來構造出ClassDerivedBeanDefinition，然後registerBeanDefinition（BeanDefinitionRegistry中的方法，交給bean factory來實現。）

GenericApplicationContext繼承AbstractApplicationContext，但是它可以設定ResourceLoader。

如果它設定了ResourceLoader的話，那麼它對於ResourceLoader介面中的方法實現交給自己持有的resourceLoader，沒有的話才由父類實現。

對於ResourcePatternResolver中的方法，當它持有的resourceLoader是ResourcePatternResolver時，才委託，否則也是呼叫父類的同名方法。

注意：GenericApplicationContext的建構函式中不會呼叫refresh方法。

1.6. AnnotationConfigApplicationContext

AnnotationConfigApplicationContext實現了AnnotationConfigRegistry介面，它持有AnnotatedBeanDefinitionReader、ClassPathBeanDefinitionScanner（在建構函式中根據this建立。），這兩個配件是用來從Java Class中讀取註解配置來生成bean definition。

AnnotationConfigRegistry介面定義了兩個功能：

• 掃描給定的package下的Component Class（scan方法）

• 註冊給定的Component Class。（register方法）

scan方法委託給自己持有ClassPathBeanDefinitionScanner，register方法委託給AnnotatedBeanDefinitionReader。

重寫了AbstractApplicationContext的setEnvironment方法：還將給定的environment設定到AnnotatedBeanDefinitionReader、ClassPathBeanDefinitionScanner中去。

還又新增了兩個配件的設定方法：

• ScopeMetadataResolver

• BeanNameGenerator

這兩個配件都是設定到AnnotatedBeanDefinitionReader、ClassPathBeanDefinitionScanner中了。

重寫了GenericApplicationContext引入的registerBean方法，將其最終交給AnnotatedBeanDefinitionReader實現而不是讓bean factory來實現。

注意：構造AnnotationConfigApplicationContext的時候，只有提供class型別或者package名，才會呼叫register或者scan方法來載入bean definition並呼叫refresh方法，如果這兩者都不提供，那麼是不會refresh的，這時需要我們在手動的呼叫scan或register方法，再手動的refresh

1.7. AbstractRefreshableApplicationContext

定義了allowBeanDefinitionOverriding、allowCircularReferences這兩個引數欄位，這兩個欄位是用來設定自己持有的bean factory的。

AbstractRefreshableApplicationContext主要是重寫了AbstractApplicationContext中的refreshBeanFactory這個方法。

這個方法在obtainFreshableBeanFactory中的被呼叫。

refreshBeanFactory的邏輯是：

• 銷燬舊的bean factory（將其中的單例bean銷燬，然後不再持有舊bean factory）

• 建立帶層級的bean factory（DefaultListableBeanFactory，parent bf 從 parent app ctx中來）。

• 給bean factory設定序列化id為app ctx的id。

• allowBeanDefinitionOverriding、allowBeanDefinitionOverriding這兩個欄位如果設定了，設定bean factory

• 將bean definition載入到bean factory中（在子類中重寫）。

1.8. AbstractRefreshableConfigApplicationContext

AbstractRefreshableConfigApplicationContext新增了：新增配置檔案所在路徑的功能，傳入的配置檔案路徑，經過environment的的萬用字元解析替換之後，儲存在一個String陣列中。

然後它同時實現了InitializingBean、BeanNameAware介面。

• afterPropertiesSet方法中：如果沒有active，那麼就refresh

• setBeanName方法中：如果沒有設定id，那麼就設定id為這個bean name，並且設定display name

1.9. AbstractXmlApplicationContext

AbstractXmlApplicationContext主要重寫了AbstractRefreshableApplicationContext的loadBeanDefinitions方法。

使用XmlBeanDefinitionReader來生成bean definition然後註冊到bean factory中。

這些配置來來源有兩個：

• 一是AbstractRefreshableConfigApplicationContext中的配置檔案路徑陣列

• 二是子類重寫的getConfigResources返回的Resource型別的陣列。

1.10. ClassPathXmlApplicationContext

ClassPathXmlApplicationContext內部又持有了ClassPathResource陣列型別作為配置檔案的來源。

注意，在構造ClassPathXmlApplicationContext時，提供了配置路徑資訊後，才會自動refresh。