1. IOC概述

1.1 是什么？

兩個概念：控制反轉，依賴注入

來看一下傳統的干活方式：在對象單一職責原則的基礎上，一個對象很少有不依賴其他對象而完成自己的工作，所以這個時候就會出現對象之間的依賴。而體現在我們的開發中，就是需要什么對象的時候，就創建什么對象，此時對象創建的控制權在我們自己手里。當對象創建的太多的時候，就會出現一個對象更改，就得更改所有依賴它的對象，耦合性大。自主性體現的同時也出現了對象耦合嚴重的情況。

這個時候，我們就會思考，能不能我們在用的時候直接拿到這個對象去用，而將創建對象的能力交給第三方，這樣我們就不需要關心對象是怎么創建的了。即將自己的控制權交出去。這就是控制反轉
這個時候，就會有另一個問題產生了，對象怎么才能直接被我們拿來用呢。對象創建的時候，我們把這個對象注入到這個對象中，然后就可以使用了。這就是依賴注入
另一個問題，耦合性怎么被解決掉的？通過控制反轉我們僅僅使用了這個對象，如果對象發生了修改，我們僅僅需要修改第三方創建對象的方式即可，這個時候難道還會出現所謂的對象耦合嗎？

2. IOC架構

一個圖搞定，這個就是IOC的架構思路，這不是其執行流程圖。

我們接下來一步一步來解讀。

2.1 白話版

在第一章中我們了解了IOC是來幫助我們管理和創建對象的。

這個時候我們需要一個承載我們需要創建信息的容器，即圖中的XML或者注解，那么有了我們自己的BeanDefiniton信息以后，我們需要一個接口用來讀取這些信息，于是出現了BeanDefinitionReader用來讀取我們自己的Bean信息。

那么我們需要考慮一個問題了，那么多的對象怎么生產呢？

答案就是工廠模式。Spring默認的工廠是DefaultListableBeanFactory，沒錯，Spring中的所有對象(容器對象和我們自己創建的對象)都是由他創建的。大批量生產對象

這個時候又有了一個問題，我們不想通過BeanFactory直接生產了，需要對這個工廠進行一些特定處理，于是出現了BeanFactoryPostProcessor，用來對工廠做一些特定的處理。我們自己可以通過實現這個接口，進行自定義BeanFactory。又有兄弟說了：我想單獨創建一些我喜歡的對象，安排，FactoryBean誕生了，它可以幫助我們創建一個我們需要的對象（第四部分詳細解釋他們之間的區別）。

那又有兄弟說了：我想讓統一的對象創建之前按照我的方式進行一些特殊的行為，簡單，安排：see_no_evil

BeanPostProcessor出現了，他提供了兩個方法：一個在對象實例化之后初始化之前，執行內部的Before方法，在初始化之后，執行After方法。（Bean生命周期，第四部分詳解）

這個時候有兄弟有疑問了，不是說BeanPostProcessor在創建對象之前執行嗎？怎么是創建完畢以后才執行的Before方法。

如果各位兄弟了解過指令重排序這個概念，那么一定會聽過一個案例，創建一個對象需要三步

創建空間(實例化)
初始化
賦值

其中在初始化和賦值會出現指令重排序

根據這個點，應該可以get到一個點，實例化和初始化不一樣。

所以又引出了一個點，我們對Bean進行一些操作，怎么操作，肯定是修改屬性，或者添加一些屬性等等，需要等待其在堆中開辟空間即實例化完成以后執行吧。

所以BeanPostProcessor的before方法在實例化之后執行，初始化之前執行。

經歷過前面一大堆的操作以后，終于我們的對象進入我們兜里了(容器里)。

關于銷毀，一般情況下我們通過ApplicationContext拿不到其銷毀方法，只能通過其子類實現獲取，關于銷毀同樣的流程，先執行一個銷毀之前的操作，然后再銷毀。

其中在初始化和賦值會出現指令重排序

根據這個點，應該可以get到一個點，實例化和初始化不一樣。

所以BeanPostProcessor的before方法在實例化之后執行，初始化之前執行。

經歷過前面一大堆的操作以后，終于我們的對象進入我們兜里了(容器里)。

2.2 實際工作流程

看過Spring源碼或者聽過的都知道里面有一個方法叫做refresh，他完成了好多事情。當然他的行為也代表了整個IOC容器加載和實例化對象的過程。第三章的代碼解讀中我們仔細看

執行過程：

加載配置文件，初始化系統環境Environment接口
準備上下文環境，初始化一些配置資源
創建一個工廠
為工廠添加各種環境
獲取子類自己重寫的BeanFactoryPostProcessor
執行容器和我們自己的BeanFactoryPostProcessor
注冊BeanPostProcessor
國際化處理
轉播器
子類初始化Bean
注冊監聽器，觀察者模式
完成Bean創建
發布相應的事件,監聽器

3. IOC源碼解讀

3.1 上下文配置啟動

在創建ClassPathXmlApplicationContext的時候，構造方法中執行了這些方法。

說白了，加載了一個解析配置文件路徑的加載器；然后又通過系統環境變量拿到這個配置文件，進行一些配置文件的去空格，轉換表達式等等操作(沒有進行解析)；最后就是那個被我標成紅色東東，refresh方法中它完成了幾乎所有的工作。下面細聊

3.2 refresh

這個方法幾乎完成了所有的操作，創建工廠，執行Processor等等，實例化對象，開啟事件監聽等等。

接下來細聊

3.3.1 prepareRefresh()

這個方法的主要作用是為應用上下文的刷新做一些準備性的工作。校驗資源文件，設置啟動時間和活躍狀態等。

3.3.2 obtainFreshBeanFactory()

可以get到，它主要就是創建了一個工廠BeanFactory，并且解析了配置文件，加載了Bean定義信息（面試的時候直接答這個點就夠了，如果想說的可以將下面的bean信息加載聊聊）沒錯，標紅的就是咱接下來細聊的點

這個就是加載配置文件的過程，注意：此時仍然沒有解析，解析在標紅的下面

這個就是讀取的過程，具體解析流程來自parse中，這個直接調用了JAVA中的解析XML的類庫，有興趣自行翻閱，最后返回了一個Document對象。

通過Document對象，讀取內部的標簽，執行不同的方法，邏輯和MyBatis中解析配置文件的思想相同，大家自行翻閱。

此時所有的Bean定義信息都被保存到了BeanDefinitionRegistry接口，然后走子類DefaultListableBeanFactory工廠的注冊方法

3.3.3 prepareBeanFactory(beanFactory)

為BeanFactory準備一些環境，方便在實例化的時候使用，同時添加容器自己的BeanPostProcessor

3.3.4 postProcessBeanFactory

留給子類擴展的BeanFactoryPostProcessor，

3.3.5 invokeBeanFactoryPostProcessors(beanFactory)

這個類，涉及到了兩個接口。

BeanFactoryPostProcessor
BeanDefinitionRegistryPostProcessor接口，這個接口是BeanFactoryPostProcessor的子接口，它的優先級比BeanFactoryPostProcessor更高

它的總體執行流程是：先執行BeanDefinitionRegistryPostProcessor的BeanFactoryPostProcessor，然后再執行BeanFactoryPostProcessor

下圖是BeanDefinitionRegistryPostProcessor接口的處理過程

BeanFactoryPostProcessor的處理邏輯

總邏輯就是先分類，已經處理過的直接跳過，沒有處理過的，分類處理，邏輯和上面的相同。

3.3.6 registerBeanPostProcessors

這個方法的邏輯和上面的一樣，只不過上面是直接執行了BeanFactoryPostProcessor，而這個僅僅注冊沒執行。

首先拿到工廠中所有的BeanPostProcessor類型的Bean，然后分類處理，排序注冊。

3.3.7 initMessageSource()

執行國際化內容

3.3.8 initApplicationEventMulticaster

創建了一個多播器，為添加Listener提供支持。

主要邏輯：

容器中是否存在applicationEventMulticaster，如果存在直接注冊
如果不存在，創建一個SimpleApplicationEventMulticaster，注冊到容器中。

3.3.9 onRefresh()

子類擴展

3.3.10 registerListeners()

觀察者模式的實現

3.3.11 finishBeanFactoryInitialization

這一部分的內容太多了，所以采用代碼和圖解的方式來講解。

下圖是創建Bean的主要流程

按照圖中的序號一個一個說：

BeanDefinition是否需要合并。BeanDefinition根據不同類型的配置文件信息，會將Bean封裝到不同的Bean信息定義類中。比如我們常用的配置文件版的GenericBeanDefinition；注解掃描版的ScannedGenericBeanDefinition等等。

而在這個過程中就出現了，父定義和子定義，我們需要在實際處理定義信息的時候進行合并處理，主要有以下三個方面

存在父定義信息，使用父定義信息創建一個RootBeanDefinition，然后將自定義信息作為參數傳入。
不存在父定義信息，并且當前BeanDefinition是RootBeanDefintion類型的，直接返回一份RootBeanDefintion的克隆
不存在父定義信息，并且當前BeanDefintion不是RootBeanDefintiton類型的，直接通過該BeanDefintion構建一個RootBeanDefintion返回

上面的流程也是源碼中的執行流程

isFactoryBean。判斷是否為FactoryBean

簡單介紹一下：FactoryBean是讓開發者創建自己需要Bean接口。內部提供了三個方法

當我們通過GetBean直接該Bean的時候，獲取到的是該工廠指定返回的Bean類型。如果想要獲取該Bean本身，需要通過一個前綴獲得&

再來看一個點,這個就是從容器中獲取Bean的主要方法，也是解決循環依賴的邏輯

來聊一下它是怎么解決循環引用的？

它引入了一個三級緩存的概念

在發生循環引用的時候，它首先通過ObejctFactory工廠將Bean創建出來，此時的對象并沒有進行屬性賦值，僅僅在堆中開辟了空間。然后將此時的Bean添加到earlySingletonObjects容器里，也就是說這個容器中保存的Bean都是半成品。而在之后的屬性賦值中，由于對象為單例的，所以其引用地址不會發生變化，即對象最終是完整的。

1.getBean。通過這個方法直接創建了所有的對象，這也是Spring最核心的方法了，先來看一下它整體的一個流程

它的主要邏輯是：

先拿到當前要實例化的Bean的真實名字，主要是為了處理FactoryBean，拿到以后，從當前容器中看是否已經創建過該Bean，如果存在直接返回。
如果不存在，獲取其父工廠，如果父工廠不為空，而且當前容器中不存在當前Bean的信息，則嘗試從父工廠中獲取Bean定義信息，進行Bean實例化
如果父工廠為空，將當前Bean信息存放到alreadyCreated緩存中。
獲取當前Bean的合并信息(getMergedLocalBeanDefinition)，查看當前Bean是否存在依賴，如果存在則判斷當前Bean和依賴 Bean 是否為循環依賴，如果不是循環依賴則先創建依賴Bean
判斷當前Bean的作用域。
如果當前Bean是單例對象，直接創建Bean實例
如果當前Bean是多例對象，將當前Bean信息添加到正在創建多例緩存中，創建完畢以后移除
如果當前Bean是其他類型，如Requtst，Session等類型，則自定義一個ObejctFacotry工廠，重寫getObject方法，創建對象
對象創建以后，判斷當前對象是否為自己需要的對象，如果是直接返回；如果不是進行類型轉換，如果類型轉換失敗，直接拋異常

接下來看一眼CreateBean的執行

這個方法主要完成的事情是：通過Bean的名字拿到對應的Class對象；如果當前Bean獲取到的Class對象不為空且該RootDefintiton可以直接獲取到該Bean，克隆一份Bean定義信息，方便之后使用。

驗證當前Bean上的@Override信息。執行BeanPostProcessor，返回一個代理對象(如果存在代理的話)，如果不存在代理，則直接創建Bean

接下來我們來聊一下這個玩意——resolveBeforeInstantiation

來吧，繼續，看一下那個前置處理器邏輯

后置處理器就不看了，就調用了所有的后置處理器，然后執行了一遍，沒有其他邏輯。

接下來繼續我們的正題：doCreateBean

其大致流程如上圖：

先判斷以后是否單例，然后從FactoryBean緩存中看一下是否存在正在創建的Bean，如果存在拿出，如果不存在則創建一個當前Bean的包裝類實例。然后拿到這個類的實例和實例類型，執行以后后置處理器。

當前Bean是否為單例，是否允許循環依賴，時候正在進行創建，如果是，創建一個當前Bean的ObejctFactory以解決循環依賴的問題

填充Bean的屬性，進行Bean的實例化。

查看早期容器緩存中(緩存中的二級緩存中是否有該Bean)。如果有，則說明存在循環依賴，則進行處理

先看循環依賴吧

接著來，createBeanInstance

Spring提供了三種方式創建對象的包裝：

通過供給者對象對象直接創建。obtainFromSupplier
通過工廠方法直接創建。
默認創建。構造方法是否需要自動注入構造方法不需要自動注入，調用默認的構造方法

這個方法執行完畢以后，你應該知曉的一個點是：此時對象實例已經創建了，剩下的就是執行一系列增強器和初始化方法，屬性填充等等。

我們按照代碼執行順序來，屬性填充即populateBean

這個方法執行邏輯：

首先判斷傳入的Bean是否為null，如果為null則判斷Bean定義信息中是否存在屬性值，如果存在，異常；如果不存在跳過
當前Bean定義信息是否為合并以后的，如果是且此時的工廠中存在InstantiationAwareBeanPostProcessors，那么在屬性填充之前進行修改Bean的信息
拿到所有的屬性值，解析屬性值的自動注入方式，Type或者Name，進行自動注入
判斷是否存在InstantiationAwareBeanPostProcessors,修改之前設置的屬性
判斷是否存在依賴檢查，檢查依賴
屬性賦值