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）：
-
遍歷傳入的bean factory post processor，將其中的bean definition registry post processor和一般的bean factory post processor分開，並用其中的bean definition registry post processor的postProcessBeanDefinitionRegistry方法處理app ctx的bean factory
-
然後再從app ctx的bean factory中取出所有PriorityOrdered型別的bean definition registry post processor型別的bean，排序後，用其postProcessBeanDefinitionRegistry方法依次處理app ctx的bean factory，並將其儲存下來以供去重。
-
然後再從app ctx的bean factory中取出所有只是Ordered型別的沒用過的bean definition registry post processor型別的bean，排序後，用其postProcessBeanDefinitionRegistry方法依次處理app ctx的bean factory，並將其儲存下來以供去重。
-
然後再取出剩下的普通優先順序的沒用過的bean definition registry post processor，用其postProcessBeanDefinitionRegistry方法r處理app ctx的bean factory。注意由於postProcessBeanDefinitionRegistry時可能會向bean factory中註冊新的bean definition registry post processor型別的bean，因此用廣度優先的方式進行不斷的迭代，直到沒有為止。
-
將上面的這些bean definition registry post processor按照同樣的順序，使用其postProcessBeanFactory方法來處理bean factory
-
將入參中的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中（在子類中重寫）。
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。