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

本文來自博客園，作者：林一gg，轉載請注明原文鏈接：https://www.cnblogs.com/linyigg/p/16949517.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/539134.html

標籤：Java

上一篇：【Java面試指北】Exception Error Throwable 你分得清么？

下一篇：SpringCloud Alibaba學習筆記