Spring迴圈依賴_ZenDei技術網路在線

說明: 1. 本文基於Spring-Framework 5.1.x版本講解 2. 建議讀者對創建對象部分源碼有一定瞭解概述這篇講講Spring迴圈依賴的問題，網上講迴圈依賴的帖子太多太多了，相信很多人也多多少少瞭解一點，那我還是把這個問題自己梳理一遍，主要是基於以下出發點： 1. Spring到 ...

說明:

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考慮問題真是的非常全面，設計相當合理。如有疑問，歡迎交流