IOC總結
1. IOC概述
三個問題：
- IOC是什么
- 為什么用它
- 怎么用
1.1 是什么？
兩個概念：控制反轉，依賴注入
來看一下傳統的干活方式：在對象單一職責原則的基礎上，一個對象很少有不依賴其他對象而完成自己的工作，所以這個時候就會出現對象之間的依賴。而體現在我們的開發中，就是需要什么對象的時候，就創建什么對象，此時對象創建的控制權在我們自己手里。當對象創建的太多的時候，就會出現一個對象更改，就得更改所有依賴它的對象，耦合性大。自主性體現的同時也出現了對象耦合嚴重的情況。
這個時候，我們就會思考，能不能我們在用的時候直接拿到這個對象去用，而將創建對象的能力交給第三方，這樣我們就不需要關心對象是怎么創建的了。即將自己的控制權交出去。這就是控制反轉
這個時候，就會有另一個問題產生了，對象怎么才能直接被我們拿來用呢。對象創建的時候，我們把這個對象注入到這個對象中，然后就可以使用了。這就是依賴注入
另一個問題，耦合性怎么被解決掉的？通過控制反轉我們僅僅使用了這個對象，如果對象發生了修改，我們僅僅需要修改第三方創建對象的方式即可，這個時候難道還會出現所謂的對象耦合嗎？😄
完成這些工作的就是IOC容器，它幫助我們創建對象，然后在對象被使用的時候，將對象注入到這個對象中。而由於IOC創建對象是通過反射來創建的，所以其速度不如直接new對象
還不理解？？？放心，聽筆者講一個故事，筆者最喜歡講故事了
前段時間，天氣逐漸回暖，鑒於家里沒有短袖的情況，筆者只能選擇購買了。這個時候筆者有兩種選擇，第一、去生產衣服的廠家直接去買(便宜)；第二、去實體店或者網店購買(較昂貴)。之后，由於筆者屬於宅男大軍的一員，直接網上購物。
這個場景就是一個典型的控制反轉的過程。筆者不需要關注衣服怎么生產的，而是僅僅去淘寶（IOC容器）上，尋找自己想要的衣服(對象)，然后直接拿過來用即可。但是由於存在中間商賺差價，所以價格更貴（時間更長）🙈
最后兩句話：
控制反轉：將自己的控制權交給自己信任的第三方，甲乙之間不存在依賴關系
依賴注入：開放一個端口留給A，然后在需要的時候，將B注入到A中。
1.2 為什么用
在上面，筆者已經很清晰的描述了為什么要使用IOC，主要原因就是由於對象之間的耦合。
1.3 怎么用
1.3.1 XML
通過書寫XML配置文件，向容器中添加需要注入的Bean
1.3.2 Annotation
通過@Configuration注解指定配置類。
2. IOC架構
一個圖搞定，這個就是IOC的架構思路，這不是其執行流程圖。
我們接下來一步一步來解讀。
2.1 白話版
在第一章中我們了解了IOC是來幫助我們管理和創建對象的。
這個時候我們需要一個承載我們需要創建信息的容器，即圖中的XML或者注解，那么有了我們自己的BeanDefiniton信息以后，我們需要一個接口用來讀取這些信息，於是出現了BeanDefinitionReader用來讀取我們自己的Bean信息。
那么我們需要考慮一個問題了，那么多的對象怎么生產呢？
答案就是工廠模式。Spring默認的工廠是DefaultListableBeanFactory，沒錯，Spring中的所有對象(容器對象和我們自己創建的對象)都是由他創建的。大批量生產對象
這個時候又有了一個問題，我們不想通過BeanFactory直接生產了，需要對這個工廠進行一些特定處理，於是出現了BeanFactoryPostProcessor，用來對工廠做一些特定的處理。我們自己可以通過實現這個接口，進行自定義BeanFactory。又有兄弟說了：我想單獨創建一些我喜歡的對象，安排，FactoryBean誕生了，它可以幫助我們創建一個我們需要的對象（第四部分詳細解釋他們之間的區別）。
那又有兄弟說了：我想讓統一的對象創建之前按照我的方式進行一些特殊的行為，簡單，安排🙈
BeanPostProcessor出現了，他提供了兩個方法：一個在對象實例化之后初始化之前，執行內部的Before方法，在初始化之后，執行After方法。（Bean生命周期，第四部分詳解）
這個時候有兄弟有疑問了，不是說BeanPostProcessor在創建對象之前執行嗎？怎么是創建完畢以后才執行的Before方法。
如果各位兄弟了解過指令重排序這個概念，那么一定會聽過一個案例，創建一個對象需要三步
- 創建空間(實例化)
- 初始化
- 賦值
其中在初始化和賦值會出現指令重排序
根據這個點，應該可以get到一個點，實例化和初始化不一樣。
所以又引出了一個點，我們對Bean進行一些操作，怎么操作，肯定是修改屬性，或者添加一些屬性等等，需要等待其在堆中開辟空間即實例化完成以后執行吧。
所以BeanPostProcessor的before方法在實例化之后執行，初始化之前執行。
經歷過前面一大堆的操作以后，終於我們的對象進入我們兜里了(容器里)。
關於銷毀，一般情況下我們通過ApplicationContext拿不到其銷毀方法，只能通過其子類實現獲取，關於銷毀同樣的流程，先執行一個銷毀之前的操作，然后再銷毀。
2.2 實際工作流程
看過Spring源碼或者聽過的都知道里面有一個方法叫做refresh，他完成了好多事情。當然他的行為也代表了整個IOC容器加載和實例化對象的過程。第三章的代碼解讀中我們仔細看
執行過程：
- 加載配置文件，初始化系統環境
Environment接口 - 准備上下文環境，初始化一些配置資源
- 創建一個工廠
- 為工廠添加各種環境
- 獲取子類自己重寫的
BeanFactoryPostProcessor - 執行容器和我們自己的
BeanFactoryPostProcessor - 注冊
BeanPostProcessor - 國際化處理
- 轉播器
- 子類初始化
Bean - 注冊監聽器，觀察者模式
- 完成
Bean創建 - 發布相應的事件,監聽器
3. IOC源碼解讀
寫在之前：IOC的源碼比較復雜，所以個人建議視頻方式學習，大家可以B站搜索閣主梧桐(筆者認為講的不錯的一個解讀)，如果大家不喜歡視頻的方式，又想深度學習IOC源碼那么推薦程序員囧輝它的博客對於IOC的講解非常深入。另外本文接下來的Spring源碼，主要是通過圖示的方法梳理其流程，作者水平有限。如有錯誤請留言。
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)
這個類，涉及到了兩個接口。
BeanFactoryPostProcessorBeanDefinitionRegistryPostProcessor接口，這個接口是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()
觀察者模式的實現
protected void registerListeners() {
// 拿到當前容器中的監聽器，注冊到多播器中
for (ApplicationListener<?> listener : getApplicationListeners()) {
getApplicationEventMulticaster().addApplicationListener(listener);
}
//拿到容器中為監聽器的Bean，注冊
String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
for (String listenerBeanName : listenerBeanNames) {
getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
}
// 清空開始的事件，到廣播器中
Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
this.earlyApplicationEvents = null;
if (earlyEventsToProcess != null) {
for (ApplicationEvent earlyEvent : earlyEventsToProcess) {
getApplicationEventMulticaster().multicastEvent(earlyEvent);
}
}
}
3.3.11 finishBeanFactoryInitialization
這一部分的內容太多了，所以采用代碼和圖解的方式來講解。
/**
* Finish the initialization of this context's bean factory,
* initializing all remaining singleton beans.
在上下文工廠中完成所有Bean 的初始化
*/
protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
// 初始化上下文轉換服務Bean
if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&
beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {
beanFactory.setConversionService(
beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));
}
//如果不存在前入值解析器，則注冊一個默認的嵌入值解析器，主要是注解屬性解析
if (!beanFactory.hasEmbeddedValueResolver()) {
beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));
}
// 初始化LoadTimeWeaverAware
String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);
for (String weaverAwareName : weaverAwareNames) {
getBean(weaverAwareName);
}
// Stop using the temporary ClassLoader for type matching.
beanFactory.setTempClassLoader(null);
// Allow for caching all bean definition metadata, not expecting further changes.
beanFactory.freezeConfiguration();
// Instantiate all remaining (non-lazy-init) singletons.
//實例化，重點
beanFactory.preInstantiateSingletons();
}
下圖是創建Bean的主要流程
按照途中的序號一個一個說：
BeanDefinition是否需要合並。BeanDefinition根據不同類型的配置文件信息，會將Bean封裝到不同的Bean信息定義類中。比如我們常用的配置文件版的GenericBeanDefinition；注解掃描版的ScannedGenericBeanDefinition等等。
而在這個過程中就出現了，父定義和子定義，我們需要在實際處理定義信息的時候進行合並處理，主要有一下三個方面
- 存在父定義信息，使用父定義信息創建一個
RootBeanDefinition，然后將自定義信息作為參數傳入。 - 不存在父定義信息，並且當前
BeanDefinition是RootBeanDefintion類型的，直接返回一份RootBeanDefintion的克隆 - 不存在父定義信息，並且當前
BeanDefintion不是RootBeanDefintiton類型的，直接通過該BeanDefintion構建一個RootBeanDefintion返回
上面的流程也是源碼中的執行流程
isFactoryBean。判斷是否為FactoryBean
簡單介紹一下：FactoryBean是讓開發者創建自己需要Bean接口。內部提供了三個方法
T getObject() throws Exception;//返回的Bean信息
Class<?> getObjectType();//返回的Bean類型
default boolean isSingleton() {return true;}//是否單例
當我們通過GetBean直接該Bean的時候，獲取到的是該工廠指定返回的Bean類型。如果想要獲取該Bean本身，需要通過一個前綴獲得&
@Override
public boolean isFactoryBean(String name) throws NoSuchBeanDefinitionException {
String beanName = transformedBeanName(name); //解析真正的BeanName
Object beanInstance = getSingleton(beanName, false);//獲取容器中的bean
if (beanInstance != null) {//如果容器中存在，直接返回該Bean是否為FactoryBea類型
return (beanInstance instanceof FactoryBean);
}
//沒有Bean信息，檢查這個Bean信息
if (!containsBeanDefinition(beanName) && getParentBeanFactory() instanceof ConfigurableBeanFactory) {
// 從父工廠中獲取
return
((ConfigurableBeanFactory) getParentBeanFactory()).isFactoryBean(name);
}
//MergedBeanDefinition來檢查beanName對應的Bean是否為FactoryBean
return isFactoryBean(beanName, getMergedLocalBeanDefinition(beanName));
}
再來看一個點,這個就是從容器中獲取Bean的主要方法，也是解決循環依賴的邏輯
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
//查看當前容器中是否存在該Bean
Object singletonObject = this.singletonObjects.get(beanName);
//如果不存在，且當前Bean正在被創建
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
synchronized (this.singletonObjects) {
//從早期的容器中獲取Bean
singletonObject = this.earlySingletonObjects.get(beanName);
//如果早期容器也沒有且允許創建早期引用
if (singletonObject == null && allowEarlyReference) {
//獲取該Bean的ObjectFactory工廠
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
//如果當前工廠不為空
if (singletonFactory != null) {
//創建一個對象實例，此時處於半初始化狀態
singletonObject = singletonFactory.getObject();
//添加到早期引用中
this.earlySingletonObjects.put(beanName, singletonObject);
//移除創建早期引用的工廠，因為該Bean已經創建且添加到了早期容器中，不需要再次進行創建了。
this.singletonFactories.remove(beanName);
}
}
}
}
return singletonObject;
}
來聊一下它是怎么解決循環引用的？
它引入了一個三級緩存的概念
/**存放了所有的單例Bean */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256);
/** 存放了Bean創建需要的ObejctFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16);
/** 存放了早期創建的Bean，此時的Bean沒有進行屬性賦值，僅僅通過構造方法創建了一個實例 */
private final Map<String, Object> earlySingletonObjects = new HashMap<>(16);
//正在創建的Bean
private final Set<String> singletonsCurrentlyInCreation =
Collections.newSetFromMap(new ConcurrentHashMap<>(16));
在發生循環引用的時候，它首先通過ObejctFactory工廠將Bean創建出來，此時的對象並沒有進行屬性賦值，僅僅在堆中開辟了空間。然后將此時的Bean添加到earlySingletonObjects容器里，也就是說這個容器中保存的Bean都是半成品。而在之后的屬性賦值中，由於對象為單例的，所以其引用地址不會發生變化，即對象最終是完整的。
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
protected Object resolveBeforeInstantiation(String beanName, RootBeanDefinition mbd) {
Object bean = null;
if (!Boolean.FALSE.equals(mbd.beforeInstantiationResolved)) {
// Make sure bean class is actually resolved at this point.
//當前定義信息不是合並，且存在Bean增強器
if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
//獲取Bean的Class類型
Class<?> targetType = determineTargetType(beanName, mbd);
if (targetType != null) {
//如果不為null，則執行前置處理器
bean = applyBeanPostProcessorsBeforeInstantiation(targetType, beanName);
if (bean != null) {
//如果前置處理器不為null，則后置處理器執行，跳過spring默認初始化
bean = applyBeanPostProcessorsAfterInitialization(bean, beanName);
}
}
}
//代表已經再實例化之前進行了解析
mbd.beforeInstantiationResolved = (bean != null);
}
return bean;
}
來吧，繼續，看一下那個前置處理器邏輯
protected Object applyBeanPostProcessorsBeforeInstantiation(Class<?> beanClass, String beanName) {
for (BeanPostProcessor bp : getBeanPostProcessors()) {
//拿到工廠中的所有的BeanPostProcessor
if (bp instanceof InstantiationAwareBeanPostProcessor) {
//找到所有我們需要的增強器
InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
// 返回一個代理實例
Object result = ibp.postProcessBeforeInstantiation(beanClass, beanName);
if (result != null) {
return result;
}
}
}
return null;
}
后置處理器就不看了，就調用了所有的后置處理器，然后執行了一遍，沒有其他邏輯。
接下來繼續我們的正題：doCreateBean
其大致流程如上圖：
先判斷以后是否單例，然后從FactoryBean緩存中看一下是否存在正在創建的Bean，如果存在拿出，如果不存在則創建一個當前Bean的包裝類實例。然后拿到這個類的實例和實例類型，執行以后后置處理器。
當前Bean是否為單例，是否允許循環依賴，時候正在進行創建，如果是，創建一個當前Bean的ObejctFactory以解決循環依賴的問題
填充Bean的屬性，進行Bean的實例化。
查看早期容器緩存中(緩存中的二級緩存中是否有該Bean)。如果有，則說明存在循環依賴，則進行處理
先看循環依賴吧
if (earlySingletonExposure) {
//從早期的Bean容器中拿到實例對象，此時的Bean必然存在循環依賴
Object earlySingletonReference = getSingleton(beanName, false);
if (earlySingletonReference != null) {
if (exposedObject == bean) {
exposedObject = earlySingletonReference;
} else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
//獲取依賴的全部Bean信息
String[] dependentBeans = getDependentBeans(beanName);
Set < String > actualDependentBeans = new LinkedHashSet < > (dependentBeans.length);
for (String dependentBean: dependentBeans) {
//清除這些Bean信息，此時的Bean已經是臟數據了
if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
//無法清理存入actualDependentBeans中
actualDependentBeans.add(dependentBean);
}
}
if (!actualDependentBeans.isEmpty()) {
throw new BeanCurrentlyInCreationException
}
}
}
}
// Register bean as disposable.
try {
registerDisposableBeanIfNecessary(beanName, bean, mbd);
} catch (BeanDefinitionValidationException ex) {
throw new BeanCreationException(
mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
}
接着來，createBeanInstance
Spring提供了三種方式創建對象的包裝：
- 通過供給者對象對象直接創建。
obtainFromSupplier - 通過工廠方法直接創建。
- 默認創建。
- 構造方法是否需要自動注入
- 構造方法不需要自動注入，調用默認的構造方法
這個方法執行完畢以后，你應該知曉的一個點是：此時對象實例已經創建了，剩下的就是執行一系列增強器和初始化方法，屬性填充等等。
我們按照代碼執行順序來，屬性填充即populateBean
這個方法執行邏輯：
首先判斷傳入的Bean是否為null，如果為null則判斷Bean定義信息中是否存在屬性值，如果存在，異常；如果不存在跳過
當前Bean定義信息是否為合並以后的，如果是且此時的工廠中存在InstantiationAwareBeanPostProcessors，那么在屬性填充之前進行修改Bean的信息
拿到所有的屬性值，解析屬性值的自動注入方式，Type或者Name，進行自動注入
判斷是否存在InstantiationAwareBeanPostProcessors,修改之前設置的屬性
判斷是否存在依賴檢查，檢查依賴
屬性賦值
接下來看執行初始化方法，就是調用BeanPostprocessor，init等方法
這個就是這個方法的執行流程圖，相信到這個地方，大家應該對於為什么BeanPostProcessor的before方法會在init方法執行了解了。這個方法的作用僅僅是用來進行一個生命周期的打印，對象在之前已經創建了。
接下來看一下銷毀的方法。registerDisposableBeanIfNecessary
對於單例Bean來說,Spring將需要銷毀的Bean存放到了disposableBeans緩存中，通過DisposableBeanAdapter封裝了銷毀Bean
對於其他作用域來說，自定義了銷毀回調函數，不過最后還是封裝為DisposableBeanAdapter
在封裝為DisposableBeanAdapter的過程中，會首先判斷該Bean中是否存在destroy方法，然后給賦值給destroyMethodName變量。再次判斷這個方法的參數，如果參數的個數大於1，則拋出異常
3.3.12 finishRefresh
這個方法進行了一系列的資源清理和
protected void finishRefresh() {
// 清空上下文資源緩存
clearResourceCaches();
// 初始化生命周期處理器
initLifecycleProcessor();
// 將已經刷新完畢的處理器傳播（扔到）生命周期處理器中
getLifecycleProcessor().onRefresh();
// 推送上下文刷新完畢的時間到相應的監聽器
publishEvent(new ContextRefreshedEvent(this));
// Participate in LiveBeansView MBean, if active.
LiveBeansView.registerApplicationContext(this);
}
initLifecycleProcessor，這個方法極具簡單，就看一下當前Bean中是否存在生命周期處理器，如果存在直接使用這個，如果不存在則創建一個默認的，並且注冊為一個單例的扔到容器中。
4. 常見題目
4.1 Bean的生命周期？
Spring官方解釋在BeanDefinition接口的注釋里
答：Bean完整的生命周期是：
- 設置一系列
Aware接口的功能 - 實例化Bean
- 調用
BeanPostProcessor的before方法 - 執行
InitializingBean接口方法afterPropertiesSet - 執行
init方法 - 調用
BeanPostProcessor的postProcessAfterInitialization方法 - 調用
DestructionAwareBeanPostProcessors接口的postProcessBeforeDestruction方法 - 調用
destory方法
4.2 FactoryBean和BeanFactory的區別
答：BeanFactory是Spring默認生產對象的工廠。
FactoryBean是Spring提供的一個生產特定類型和特定對象的工廠。例如Mybatis-spring中的SqlSessionFactoryBean就是通過這種方法創建的。
4.3 什么是循環依賴？Spring如何處理循環依賴的？
答：循環依賴是指：在創建A對象的時候需要注入B對象；在創建B對象的時候需要注入A對象，兩者互相依賴。
出現循環依賴有兩種情況：
- 構造器依賴(無法解決)
- 屬性注入（可以解決）
解決循環依賴，Spring引入了三級緩存的概念。上面的源碼講解中介紹過
singletonObjects存放了所有的單例Bean，此時所有的Bean信息都是完整的earlySingletonObjects存放了早期的Bean，此時僅僅創建了一個Bean實例，未進行屬性填充singletonFactories存放了Bean的工廠
Spring通過將創建Bean的工廠暴露出來，然后在出現循環依賴的時候通過這個工廠常見一個bean，然后將這個Bean注入，由於對象是單例的，所以在接下來的屬性填充中，可以保證為同一個對象，至此，循環依賴解除。
使用三太子敖丙的一句話：解決循環依賴的過程就是力扣中的第一題兩數之和的過程
4.4 什么是IOC
答：IOC存在兩個點：
- 控制反轉。將常見對象的控制權交給第三方，這里的第三方就是
Spring - 依賴注入。在類中需要使用到的對象，全部通過反射從第三方容器注入而不是自己創建。這里的第三方容器即
Spring
4.5 ApplicationContext和BeanFactory的區別
答：
ApplicationContext采用了立即加載，即加載配置文件的時候就創建了對象。BeanFactory采用了延時加載的方式，使用的時候才創建。- 對於
BeanPostProcessor和BeanFactoryProcessor而言，BeanFactory是手動注冊，ApplicationContext采用了自動注冊。
4.6 Spring 框架中都用到了哪些設計模式？
答：
- 單例模式。這個不需要多說
- 代理模式。
AOP使用到的 - 裝飾着模式。
BeanWrapper - 工廠模式。BeanFactory，創建對象的時候
- 模板方法模式。JDBCTemplate
- 觀察者模式。各種事件監聽
- ……
更多原創文章和Java系列教程關注公眾號@MakerStack