1. Spring IOC源碼研究筆記（2）——ApplicationContext系列 1.1. 繼承關係非web環境下，一般來說常用的就兩類ApplicationContext：配置形式為XML的：ClassPathXmlApplicationContext、FileSystemXmlApp ...

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進行後處理。

註意：

對於PriorityOrdered、Ordered優先順序的後處理器，它們在處理前都需要進行排序，而regular優先順序的不用排序。
對BDRPP和BFPP的處理不相同，BDRPP在後處理時可能引入新的BDRPP，因此採用廣度優先搜索的方式，需要多次遍歷Bean Factory中的BDRPP。而BFPP，直接遍歷一次Bean Factory中的BFPP，不進行廣度優先搜索。
上面的排序，一般使用AnnotationAwareOrderComparator來排序：實現了PriorityOrdered -> 實現了Ordered -> Spring的@Order -> javax的@Priority

整體的順序為：

非bean方式的BDRPP先postProcessBeanDefinitionRegistry
bean方式的並且是PriorityOrdered的BDRPP，排序後，postProcessBeanDefinitionRegistry
bean方式的並且是Ordered的BDRPP，排序後，postProcessBeanDefinitionRegistry
bean方式的非Ordered的BDRPP，postProcessBeanDefinitionRegistry
上面的BDRPP，相同順序來postProcessBeanFactory
非bean方式的BDRPP，postProcessBeanFactory
bean方式的並且是PriorityOrdered的BFPP，排序後，postProcessBeanFactory
bean方式的並且是Ordered的BFPP，排序後，postProcessBeanFactory
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的初始化：

如果bean factory中包含conversion service類型的bean，並且bean name為“conversionService，那麼就給bean factory設置conversion service
如果bean factory沒有設置embedded value resolver（StringValueResolver），那麼就用一個lambda表達式當它的StringValueResovler，它的功能就是說，根據appctx的environment的resolvePlaceholders方法來解析字元串
提前實例化所有LoadTimeWeaverAware類型的bean
設置bean factory的tmpClassLoader為null
然後凍結bean factory的configuration（DefaultListableBeanFactory）。
提前實例化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：

CAS設置closed狀態位，發佈ContextClosedEvent
調用lifecycle processor的onClose方法
銷毀bean factory中的所有單例bean
關閉BeanFactory——在子類中重寫：
- 對於GenericApplicationContext來說，只是將持有的BeanFactory的setSerializationId設置為null，依舊持有這個BeanFactory
- 對於AbstractRefreshableApplicationContext來說，它不僅將BeanFactory的setSerializationId設置為null，而且不再持有改beanfactory
將applicationListeners恢復到第一次refresh之前的狀態
設置active標記位
移除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中（在子類中重寫）。