說明:
1. 本文基於Spring-Framework 5.1.x版本講解
2. 建議讀者對建立物件部分原始碼有一定了解
概述
這篇講講Spring迴圈依賴的問題，網上講迴圈依賴的帖子太多太多了，相信很多人也多多少少了解一點，那我還是把這個問題自己梳理一遍，主要是基於以下出發點：
1. Spring到底如何解決的迴圈依賴問題，有沒有’黑科技‘；
2. 有時專案會因為迴圈依賴問題導致啟動失敗，由於不瞭解其機制，排查耗費時間
3. 網上眾說風雲，沒有形成自己的思考
還有其他文章說Spring使用三級快取是為了解決迴圈依賴問題，為了解決代理下的迴圈依賴問題？ 那廢話不多說，直接開始吧
迴圈依賴簡介
迴圈依賴的含義： BeanA依賴BeanB，BeanB又依賴BeanA ， 如下圖
這就是迴圈依賴， 我們來分析下會有什麼問題？
1. 例項化BeanA
2. BeanA在屬性注入階段從容器裡面找BeanB
3. 如果BeanB已經在容器裡面建立好，那萬事大吉，沒迴圈依賴的問題
4. 如果BeanB還沒有在容器裡面建立好，這時候Spring會建立BeanB
5. 建立BeanB的時候又發現依賴BeanA，但此時BeanA也沒有建立完，在沒有開啟迴圈依賴開關的情況下就會報錯：Requested bean is currently in creation: Is there an unresolvable circular reference?
從軟體程式碼分層結構來講，如果分層合理，這種情況一般可以避免掉，但是避免不了同一個層次中的Bean互相引用，好那既然迴圈依賴肯定會出現，我們自己先來思考下，如果是我們自己寫一個IOC容器，這個問題如何解決？
如何解決迴圈依賴？
從上面的4步可以看出來，問題所在就是BeanB在建立過程中，無法找到正在建立中的BeanA，那我們是不是可以找一個地方把正在建立的BeanA(為了行文方便，把Bean正在建立中的狀態稱為半狀態)先給儲存起來，等BeanB用到的時候賦值給它不就行了，這時候步驟如下：
1. 例項化BeanA
2. BeanA在屬性注入之前先把自己放到一個Map裡面(此時BeanA為半狀態)
3. BeanA在屬性注入階段從容器裡面找BeanB
4. 如果BeanB還沒有在容器裡面建立好，這時候Spring會建立BeanB
5. 建立BeanB的時候又發現依賴BeanA，由於BeanA已經在Map裡面了(雖然是半狀態，但不影響最終使用，反正現在又不暴露給使用者使用) ，所以注入成功，BeanB建立完成
6. 由於BeanB已建立完成，意味著BeanA注入BeanB成功，此時從Map中移除BeanA的半狀態
7. 容器初始化完成
到這裡有什麼大的問題沒有？ 其實是沒有的，Bean確實會建立成功 ， 容器可以正常啟動完成。 那我們在來看下啟用動態代理情況下，使用一個Map(一級快取)會不會有問題? 為了說明簡單，我們只生成BeanA的代理物件BeanA_Proxy,BeanB無需建立：
1. 例項化BeanA，並生成BeanA的代理物件BeanA_Proxy ，此時上下文中有BeanA、BeanA_Proxy兩個物件
2. BeanA在屬性注入之前先把代理物件BeanA_Proxy放到Map裡面
3. BeanA在屬性注入階段從容器裡面找BeanB
4. 如果BeanB還沒有在容器裡面建立好，這時候Spring會建立BeanB
5. 建立BeanB的時候又發現依賴BeanA，由於BeanA的代理物件BeanA_Proxy已經在Map裡面了，所以把BeanA_Proxy注入BeanB，此時BeanB建立完成
6. 由於BeanB已建立完成，意味著BeanA注入BeanB成功，此時從Map中移除BeanA_Proxy
7. 容器把BeanA_Proxy暴露給使用者使用，並初始化完成
從上面可以看出，即使使用代理的情況下，使用一個Map(一級快取)來解決迴圈依賴問題也是可以的。
為什麼是三級快取？
從上面可以看出，把半狀態的Bean或者代理物件無腦的放入一級快取之後，確實可以解決迴圈依賴的問題，那為什麼Spring要使用三級快取來解決這個問題呢？ 讓我們來回憶下Bean的整個生命週期： 1. 例項化Bean 2. 屬性注入 3. 初始化Bean 。 這是建立一個Bean必經的幾個步驟，而我們上面是為了解決迴圈依賴問題而強行加了一個往一級快取裡面放物件的步驟，而對於不存在迴圈依賴的物件，這一步無疑是多餘的；還有另外一個問題： 把半狀態的Bean和建立完成的Bean物件放入同一個快取裡面也不太好管理，違背單一職能原則
所以這裡我們要解決2個問題：
1. 解決迴圈依賴的程式碼(也就說生成半狀態物件的過程)不能放到建立Bean的主流程中；
2. 半狀態的物件需要與建立完成的物件所在的容器隔離開。
為了解決問題一我們可以考慮在檢測到有迴圈依賴的時候才把半狀態物件暴露給BeanB使用，就是說說BeanB發現BeanA正在建立的時候，在把半狀態BeanA賦值給BeanB。 但是問題又來了：這個半物件BeanA哪來的？ 誰建立出來的？ 這無疑變成了蛋和雞的問題， 所以我們還是要在剛開始建立BeanA的時候以最小的代價(這裡指執行時間最短) 把半物件給儲存起來，BeanB檢測到迴圈依賴的時候，在把BeanA給取出來。那Spring其實就是使用另一個Map儲存匿名函式的方式來解決這個問題的， 因為你要考慮直接暴露BeanA的代價(比如說暴露給BeanB是一個代理物件，那要考慮建立BeanA代理物件的執行成本)。 這裡我們簡單貼下Spring的原始碼:
/**
* 實際生成Bean的核心方法
*/
protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
throws BeanCreationException {
// 省略上下文中其他不重要的程式碼
// 這裡註冊一個匿名函式,把匿名函式放到一個臨時快取裡面(其實就是所謂的三級快取)
addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}
/**
* 作用： 獲取提前要暴露給其他Bean的引用
* 這個方法只有在Spring檢測到有迴圈引用的情況下才會調進來
*/
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
Object exposedObject = bean;
for (BeanPostProcessor bp : getBeanPostProcessors()) {
if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
// 獲取要提前暴露的物件,這裡有可能產生代理物件以及其他非入參Bean的物件
exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
}
}
return exposedObject;
}好，看到這裡其實我們已經順便把上述第二個問題也一起解決掉了，因為儲存匿名函式的Map和最終儲存物件例項的Map不是同一個，而且儲存匿名函式的Map在解決完迴圈依賴問題之後會清空掉，這樣我們就可以以延遲載入的方式解決掉迴圈依賴的問題。 那在BeanA會產生代理的情況下會不會有問題？？？ 請你自己思考下
但這裡還有一個問題，考慮下面一種場景：
BeanA與BeanB、BeanC的關係是互相引用， 套用我們上面的理論， 在建立BeanA的主流程中我們只是插入了一個獲取半狀態物件的匿名函式，而不是要暴露給外部的最終物件，當BeanC也需要注入BeanA的時候，還是要執行一次匿名函式來獲取最終暴露的物件，這裡有兩個問題：
1. 匿名函式重複執行，其實是沒有必要的。
2. 更為嚴重的是，有可能每次呼叫函式返回的是不同的物件，這樣會導致注入給BeanB和BeanC的物件不一致，這就是大問題了。 (那有人會問如果保證獲取最終暴露物件的介面SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference中返回同一個物件不就行了? 站在解決問題的角度確實是這樣的，但是站在容器的角度來講就不一樣了，介面只是一個擴充點，他的執行邏輯是不可控的，所以還是要在容器級別來解決這個問題)
為了解決以上兩個問題，Spring採用了第三個快取，把已經暴露出去的物件給快取起來，這樣問題就完美解決以上兩個問題。
getEarlyBeanReference
在上面我們已經解釋了為什麼要用三級快取來解決迴圈依賴的問題，我們在簡單說下SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference介面，其實這個介面沒有什麼高深的地方，只是為了獲取迴圈依賴下需要提前暴露給其他Bean的物件，這裡要注意一下：僅僅在檢測到有迴圈依賴的情況下才會調進來，我們看下介面定義
/**
* Extension of the {@link InstantiationAwareBeanPostProcessor} interface,
* adding a callback for predicting the eventual type of a processed bean.
*
* <p><b>NOTE:</b> This interface is a special purpose interface, mainly for
* internal use within the framework. In general, application-provided
* post-processors should simply implement the plain {@link BeanPostProcessor}
* interface or derive from the {@link InstantiationAwareBeanPostProcessorAdapter}
* class. New methods might be added to this interface even in point releases.
*
* @author Juergen Hoeller
* @since 2.0.3
* @see InstantiationAwareBeanPostProcessorAdapter
*/
public interface SmartInstantiationAwareBeanPostProcessor extends InstantiationAwareBeanPostProcessor {
default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
return bean;
}
}從類註釋中”This interface is a special purpose interface, mainly for internal use within the framework“可以看到，這個介面僅僅是Spring內部為了解決某些問題提供的介面，並不希望暴露給上層使用者使用，所以我們在實際工作中一般用不到的
但是我們要特別注意一個坑： 我們知道在Bean後置處理介面BeanPostProcessor中也有可能返回代理物件，如果這裡返回的物件和迴圈依賴暴露出去的物件不一致的話就會報以下錯誤：
Error creating bean with name 'serviceA': Bean with name 'serviceA' has been injected into other beans [serviceB] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'serviceA': Bean with name 'serviceA' has been injected into other beans [serviceB] in its raw version as part of a circular reference, but has eventually been wrapped. This means that said other beans do not use the final version of the bean. This is often the result of over-eager type matching - consider using 'getBeanNamesForType' with the 'allowEagerInit' flag turned off, for example.
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:622)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:514)
at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:321)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:319)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:866)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550)
at test.circle_ref.CircleRefTests.run(CircleRefTests.java:13)從邏輯上來講報錯也是合理的，因為既然提前暴露出去的Bean，像是一種承諾，後續就不能修改了，修改意味著Spring容器中Bean的’狀態‘是不一致的。 所以在有迴圈依賴的情況下，一定要保證getEarlyBeanReference和BeanPostProcessor 返回的Bean是同一個。
小結
本篇文章介紹了Spring為什麼用三級快取才解決迴圈依賴問題，並且介紹了SmartInstantiationAwareBeanPostProcessor#getEarlyBeanReference介面的含義以及在實際情況中可能遇到的坑，那我們總結下Spring的三級快取的作用：
一級快取: 儲存已經建立完的Bean物件，我們常用的BeanFactory#getBean方法就是從這裡獲取；
二級快取: 快取在迴圈依賴中暴露給其他Bean的半狀態物件，防止注入物件不一致的問題；
三級快取: 快取獲取提前暴露的Bean的匿名函式 ，為的是以最小的代價減少對Spring建立物件主幹流程的影響
關於迴圈依賴的問題就介紹到這，不得不說Spring考慮問題真是的非常全面，設計相當合理。如有疑問，歡迎交流?