當前位置：首頁 > 前端技术 > javascript >内容正文

javascript

Spring是如何利用“三级缓存“巧妙解决Bean的循环依赖问题

發布時間：2024/1/23 javascript 35 豆豆

生活随笔收集整理的這篇文章主要介紹了 Spring是如何利用“三级缓存“巧妙解决Bean的循环依赖问题小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

前言

循環依賴：就是N個類循環(嵌套)引用。
通俗的講就是N個Bean互相引用對方，最終形成閉環。用一副經典的圖示可以表示成這樣（A、B、C都代表對象，虛線代表引用關系）：

注意：其實可以N=1，也就是極限情況的循環依賴：自己依賴自己

另需注意：這里指的循環引用不是方法之間的循環調用，而是對象的相互依賴關系。（方法之間循環調用若有出口也是能夠正常work的）

可以設想一下這個場景：如果在日常開發中我們用new對象的方式，若構造函數之間發生這種循環依賴的話，程序會在運行時一直循環調用最終導致內存溢出，示例代碼如下：

public class Main {public static void main(String[] args) throws Exception {System.out.println(new A());}}class A {public A() {new B();} }class B {public B() {new A();} }

運行報錯：

Exception in thread "main" java.lang.StackOverflowError

這是一個典型的循環依賴問題。本文說一下Spring是如果巧妙的解決平時我們會遇到的三大循環依賴問題的~

Spring Bean的循環依賴

談到Spring Bean的循環依賴，有的小伙伴可能比較陌生，畢竟開發過程中好像對循環依賴這個概念無感知。其實不然，你有這種錯覺，權是因為你工作在Spring的襁褓中，從而讓你“高枕無憂”~
我十分堅信，小伙伴們在平時業務開發中一定一定寫過如下結構的代碼：

@Service public class AServiceImpl implements AService {@Autowiredprivate BService bService;... } @Service public class BServiceImpl implements BService {@Autowiredprivate AService aService;... }

這其實就是Spring環境下典型的循環依賴場景。但是很顯然，這種循環依賴場景，Spring已經完美的幫我們解決和規避了問題。所以即使平時我們這樣循環引用，也能夠整成進行我們的coding之旅~

Spring中三大循環依賴場景演示

在Spring環境中，因為我們的Bean的實例化、初始化都是交給了容器，因此它的循環依賴主要表現為下面三種場景。為了方便演示，我準備了如下兩個類：

1、構造器注入循環依賴

@Service public class A {public A(B b) {} } @Service public class B {public B(A a) {} }

結果：項目啟動失敗拋出異常BeanCurrentlyInCreationException

Caused by: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java:339)at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:215)at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:318)at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)

構造器注入構成的循環依賴，此種循環依賴方式是無法解決的，只能拋出BeanCurrentlyInCreationException異常表示循環依賴。這也是構造器注入的最大劣勢（它有很多獨特的優勢，請小伙伴自行發掘）

根本原因：Spring解決循環依賴依靠的是Bean的“中間態”這個概念，而這個中間態指的是已經實例化，但還沒初始化的狀態。而構造器是完成實例化的東東，所以構造器的循環依賴無法解決~~~

2、field屬性注入（setter方法注入）循環依賴

這種方式是我們最最最最為常用的依賴注入方式（所以猜都能猜到它肯定不會有問題啦）：

@Service public class A {@Autowiredprivate B b; }@Service public class B {@Autowiredprivate A a; }

結果：項目啟動成功，能夠正常work

備注：setter方法注入方式因為原理和字段注入方式類似，此處不多加演示

2、prototype?field屬性注入循環依賴

prototype在平時使用情況較少，但是也并不是不會使用到，因此此種方式也需要引起重視。

@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) @Service public class A {@Autowiredprivate B b; }@Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) @Service public class B {@Autowiredprivate A a; }

結果：需要注意的是本例中啟動時是不會報錯的（因為非單例Bean默認不會初始化，而是使用時才會初始化），所以很簡單咱們只需要手動getBean()或者在一個單例Bean內@Autowired一下它即可

// 在單例Bean內注入@Autowiredprivate A a;

這樣子啟動就報錯：

org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mytest.TestSpringBean': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'b': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:596)at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:90)at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java:374)

如何解決？？？
可能有的小伙伴看到網上有說使用@Lazy注解解決：

@Lazy@Autowiredprivate A a;

此處負責任的告訴你這樣是解決不了問題的(可能會掩蓋問題)，@Lazy只是延遲初始化而已，當你真正使用到它（初始化）的時候，依舊會報如上異常。

對于Spring循環依賴的情況總結如下：

不能解決的情況：
1. 構造器注入循環依賴
2.?prototype?field屬性注入循環依賴

能解決的情況：
1. field屬性注入（setter方法注入）循環依賴

Spring解決循環依賴的原理分析

在這之前需要明白java中所謂的引用傳遞和值傳遞的區別。

說明：看到這句話可能有小伙伴就想噴我了。java中明明都是傳遞啊，這是我初學java時背了100遍的面試題，怎么可能有錯？？？
這就是我做這個申明的必要性：伙計，你的說法是正確的，java中只有值傳遞。但是本文借用引用傳遞來輔助講解，希望小伙伴明白我想表達的意思~

Spring的循環依賴的理論依據基于Java的引用傳遞，當獲得對象的引用時，對象的屬性是可以延后設置的。（但是構造器必須是在獲取引用之前，畢竟你的引用是靠構造器給你生成的，兒子能先于爹出生？哈哈）

Spring創建Bean的流程

首先需要了解是Spring它創建Bean的流程，我把它的大致調用棧繪圖如下：

對Bean的創建最為核心三個方法解釋如下：

createBeanInstance：例化，其實也就是調用對象的構造方法實例化對象
populateBean：填充屬性，這一步主要是對bean的依賴屬性進行注入(@Autowired)
initializeBean：回到一些形如initMethod、InitializingBean等方法

從對單例Bean的初始化可以看出，循環依賴主要發生在第二步（populateBean），也就是field屬性注入的處理。

Spring容器的'三級緩存'

在Spring容器的整個聲明周期中，單例Bean有且僅有一個對象。這很容易讓人想到可以用緩存來加速訪問。
從源碼中也可以看出Spring大量運用了Cache的手段，在循環依賴問題的解決過程中甚至不惜使用了“三級緩存”，這也便是它設計的精妙之處~

三級緩存其實它更像是Spring容器工廠的內的術語，采用三級緩存模式來解決循環依賴問題，這三級緩存分別指：

public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {...// 從上至下分表代表這“三級緩存”private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一級緩存private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二級緩存private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三級緩存.../** Names of beans that are currently in creation. */// 這個緩存也十分重要：它表示bean創建過程中都會在里面呆著~// 它在Bean開始創建時放值，創建完成時會將其移出~private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));/** Names of beans that have already been created at least once. */// 當這個Bean被創建完成后，會標記為這個注意：這里是set集合不會重復// 至少被創建了一次的都會放進這里~~~~private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256)); }

注：AbstractBeanFactory繼承自DefaultSingletonBeanRegistry~

singletonObjects：用于存放完全初始化好的 bean，從該緩存中取出的 bean 可以直接使用

earlySingletonObjects：提前曝光的單例對象的cache，存放原始的 bean 對象（尚未填充屬性），用于解決循環依賴

singletonFactories：單例對象工廠的cache，存放 bean 工廠對象，用于解決循環依賴

獲取單例Bean的源碼如下：

public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {...@Override@Nullablepublic Object getSingleton(String beanName) {return getSingleton(beanName, true);}@Nullableprotected Object getSingleton(String beanName, boolean allowEarlyReference) {Object singletonObject = this.singletonObjects.get(beanName);if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {synchronized (this.singletonObjects) {singletonObject = this.earlySingletonObjects.get(beanName);if (singletonObject == null && allowEarlyReference) {ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);if (singletonFactory != null) {singletonObject = singletonFactory.getObject();this.earlySingletonObjects.put(beanName, singletonObject);this.singletonFactories.remove(beanName);}}}}return singletonObject;}...public boolean isSingletonCurrentlyInCreation(String beanName) {return this.singletonsCurrentlyInCreation.contains(beanName);}protected boolean isActuallyInCreation(String beanName) {return isSingletonCurrentlyInCreation(beanName);}... }

先從一級緩存singletonObjects中去獲取。（如果獲取到就直接return）

如果獲取不到或者對象正在創建中（isSingletonCurrentlyInCreation()），那就再從二級緩存earlySingletonObjects中獲取。（如果獲取到就直接return）

如果還是獲取不到，且允許singletonFactories（allowEarlyReference=true）通過getObject()獲取。就從三級緩存singletonFactory.getObject()獲取。（如果獲取到了就從singletonFactories中移除，并且放進earlySingletonObjects。其實也就是從三級緩存移動（是剪切、不是復制哦~）到了二級緩存）

加入singletonFactories三級緩存的前提是執行了構造器，所以構造器的循環依賴沒法解決

getSingleton()從緩存里獲取單例對象步驟分析可知，Spring解決循環依賴的訣竅：就在于singletonFactories這個三級緩存。這個Cache里面都是ObjectFactory，它是解決問題的關鍵。

// 它可以將創建對象的步驟封裝到ObjectFactory中交給自定義的Scope來選擇是否需要創建對象來靈活的實現scope。具體參見Scope接口 @FunctionalInterface public interface ObjectFactory<T> {T getObject() throws BeansException; }

經過ObjectFactory.getObject()后，此時放進了二級緩存earlySingletonObjects內。這個時候對象已經實例化了，雖然還不完美，但是對象的引用已經可以被其它引用了。

此處說一下二級緩存earlySingletonObjects它里面的數據什么時候添加什么移除？？?

添加：向里面添加數據只有一個地方，就是上面說的getSingleton()里從三級緩存里挪過來
移除：addSingleton、addSingletonFactory、removeSingleton從語義中可以看出添加單例、添加單例工廠ObjectFactory的時候都會刪除二級緩存里面對應的緩存值，是互斥的

源碼解析

Spring容器會將每一個正在創建的Bean 標識符放在一個“當前創建Bean池”中，Bean標識符在創建過程中將一直保持在這個池中，而對于創建完畢的Bean將從當前創建Bean池中清除掉。
這個“當前創建Bean池”指的是上面提到的singletonsCurrentlyInCreation那個集合。

public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {...protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {...// Eagerly check singleton cache for manually registered singletons.// 先去獲取一次，如果不為null，此處就會走緩存了~~Object sharedInstance = getSingleton(beanName);...// 如果不是只檢查類型，那就標記這個Bean被創建了~~添加到緩存里也就是所謂的當前創建Bean池if (!typeCheckOnly) {markBeanAsCreated(beanName);}...// Create bean instance.if (mbd.isSingleton()) {// 這個getSingleton方法不是SingletonBeanRegistry的接口方法屬于實現類DefaultSingletonBeanRegistry的一個public重載方法~~~// 它的特點是在執行singletonFactory.getObject();前后會執行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName); // 也就是保證這個Bean在創建過程中，放入正在創建的緩存池里可以看到它實際創建bean調用的是我們的createBean方法~~~~sharedInstance = getSingleton(beanName, () -> {try {return createBean(beanName, mbd, args);} catch (BeansException ex) {destroySingleton(beanName);throw ex;}});bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);}}... }// 抽象方法createBean所在地這個接口方法是屬于抽象父類AbstractBeanFactory的實現在這個抽象類里 public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {...protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {...// 創建Bean對象，并且將對象包裹在BeanWrapper 中instanceWrapper = createBeanInstance(beanName, mbd, args);// 再從Wrapper中把Bean原始對象（非代理~~~）這個時候這個Bean就有地址值了，就能被引用了~~~// 注意：此處是原始對象，這點非常的重要final Object bean = instanceWrapper.getWrappedInstance();...// earlySingletonExposure 用于表示是否”提前暴露“原始對象的引用，用于解決循環依賴。// 對于單例Bean，該變量一般為 true 但你也可以通過屬性allowCircularReferences = false來關閉循環引用// isSingletonCurrentlyInCreation(beanName) 表示當前bean必須在創建中才行boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));if (earlySingletonExposure) {if (logger.isTraceEnabled()) {logger.trace("Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");}// 上面講過調用此方法放進一個ObjectFactory，二級緩存會對應刪除的// getEarlyBeanReference的作用：調用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()這個方法否則啥都不做// 也就是給調用者個機會，自己去實現暴露這個bean的應用的邏輯~~~// 比如在getEarlyBeanReference()里可以實現AOP的邏輯~~~ 參考自動代理創建器AbstractAutoProxyCreator 實現了這個方法來創建代理對象// 若不需要執行AOP的邏輯，直接返回BeanaddSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));}Object exposedObject = bean; //exposedObject 是最終返回的對象...// 填充屬于，解決@Autowired依賴~populateBean(beanName, mbd, instanceWrapper);// 執行初始化回調方法們~~~exposedObject = initializeBean(beanName, exposedObject, mbd);// earlySingletonExposure：如果你的bean允許被早期暴露出去也就是說可以被循環引用那這里就會進行檢查// 此段代碼非常重要~~~~~但大多數人都忽略了它if (earlySingletonExposure) {// 此時一級緩存肯定還沒數據，但是呢此時候二級緩存earlySingletonObjects也沒數據//注意，注意：第二參數為false 表示不會再去三級緩存里查了~~~// 此處非常巧妙的一點：：：因為上面各式各樣的實例化、初始化的后置處理器都執行了，如果你在上面執行了這一句// ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);// 那么此處得到的earlySingletonReference 的引用最終會是你手動放進去的Bean最終返回，完美的實現了"偷天換日" 特別適合中間件的設計// 我們知道，執行完此doCreateBean后執行addSingleton() 其實就是把自己再添加一次 **再一次強調，完美實現偷天換日**Object earlySingletonReference = getSingleton(beanName, false);if (earlySingletonReference != null) {// 這個意思是如果經過了initializeBean()后，exposedObject還是木有變，那就可以大膽放心的返回了// initializeBean會調用后置處理器，這個時候可以生成一個代理對象，那這個時候它哥倆就不會相等了走else去判斷吧if (exposedObject == bean) {exposedObject = earlySingletonReference;} // allowRawInjectionDespiteWrapping這個值默認是false// hasDependentBean：若它有依賴的bean 那就需要繼續校驗了~~~(若沒有依賴的就放過它~)else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {// 拿到它所依賴的Bean們~~~~ 下面會遍歷一個一個的去看~~String[] dependentBeans = getDependentBeans(beanName);Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);// 一個個檢查它所以Bean// removeSingletonIfCreatedForTypeCheckOnly這個放見下面在AbstractBeanFactory里面// 簡單的說，它如果判斷到該dependentBean并沒有在創建中的了的情況下,那就把它從所有緩存中移除~~~ 并且返回true// 否則（比如確實在創建中）那就返回false 進入我們的if里面~ 表示所謂的真正依賴//（解釋：就是真的需要依賴它先實例化，才能實例化自己的依賴）for (String dependentBean : dependentBeans) {if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {actualDependentBeans.add(dependentBean);}}// 若存在真正依賴，那就報錯（不要等到內存移除你才報錯，那是非常不友好的） // 這個異常是BeanCurrentlyInCreationException，報錯日志也稍微留意一下，方便定位錯誤~~~~if (!actualDependentBeans.isEmpty()) {throw new BeanCurrentlyInCreationException(beanName,"Bean with name '" + beanName + "' has been injected into other beans [" +StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +"] 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 " +"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");}}}}return exposedObject;}// 雖然是remove方法但是它的返回值也非常重要// 該方法唯一調用的地方就是循環依賴的最后檢查處~~~~~protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {// 如果這個bean不在創建中比如是ForTypeCheckOnly的那就移除掉if (!this.alreadyCreated.contains(beanName)) {removeSingleton(beanName);return true;}else {return false;}}}

這里舉例：例如是field屬性依賴注入，在populateBean時它就會先去完成它所依賴注入的那個bean的實例化、初始化過程，最終返回到本流程繼續處理，因此Spring這樣處理是不存在任何問題的。

這里有個小細節：

if (exposedObject == bean) {exposedObject = earlySingletonReference; }

這一句如果exposedObject == bean表示最終返回的對象就是原始對象，說明在populateBean和initializeBean沒對他代理過，那就啥話都不說了exposedObject = earlySingletonReference，最終把二級緩存里的引用返回即可~

流程總結（非常重要）

此處以如上的A、B類的互相依賴注入為例，在這里表達出關鍵代碼的走勢：

1、入口處即是實例化、初始化A這個單例Bean。AbstractBeanFactory.doGetBean("a")

protected <T> T doGetBean(...){... // 標記beanName a是已經創建過至少一次的~~~ 它會一直存留在緩存里不會被移除（除非拋出了異常）// 參見緩存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))if (!typeCheckOnly) {markBeanAsCreated(beanName);}// 此時a不存在任何一級緩存中，且不是在創建中所以此處返回null// 此處若不為null，然后從緩存里拿就可以了(主要處理FactoryBean和BeanFactory情況吧)Object beanInstance = getSingleton(beanName, false);...// 這個getSingleton方法非常關鍵。//1、標注a正在創建中~//2、調用singletonObject = singletonFactory.getObject();（實際上調用的是createBean()方法）因此這一步最為關鍵//3、此時實例已經創建完成會把a移除整整創建的緩存中//4、執行addSingleton()添加進去。（備注：注冊bean的接口方法為registerSingleton，它依賴于addSingleton方法）sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); }); }

2、下面進入到最為復雜的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()環節，創建A的實例

protected Object doCreateBean(){...// 使用構造器/工廠方法 instanceWrapper是一個BeanWrapperinstanceWrapper = createBeanInstance(beanName, mbd, args);// 此處bean為"原始Bean" 也就是這里的A實例對象：A@1234final Object bean = instanceWrapper.getWrappedInstance();...// 是否要提前暴露（允許循環依賴）現在此處A是被允許的boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));// 允許暴露，就把A綁定在ObjectFactory上，注冊到三級緩存`singletonFactories`里面去保存著// Tips:這里后置處理器的getEarlyBeanReference方法會被促發，自動代理創建器在此處創建代理對象（注意執行時機為執行三級緩存的時候）if (earlySingletonExposure) {addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));}...// exposedObject 為最終返回的對象，此處為原始對象bean也就是A@1234,下面會有用處Object exposedObject = bean; // 給A@1234屬性完成賦值，@Autowired在此處起作用~// 因此此處會調用getBean("b")，so 會重復上面步驟創建B類的實例// 此處我們假設B已經創建好了為B@5678// 需要注意的是在populateBean("b")的時候依賴有beanA，所以此時候調用getBean("a")最終會調用getSingleton("a")，//此時候上面說到的getEarlyBeanReference方法就會被執行。這也解釋為何我們@Autowired是個代理對象，而不是普通對象的根本原因populateBean(beanName, mbd, instanceWrapper);// 實例化。這里會執行后置處理器BeanPostProcessor的兩個方法// 此處注意：postProcessAfterInitialization()是有可能返回一個代理對象的，這樣exposedObject 就不再是原始對象了特備注意哦~~~// 比如處理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在這個時間里生成代理對象的（有坑，請小心使用@Aysnc）exposedObject = initializeBean(beanName, exposedObject, mbd);... // 至此，相當于A@1234已經實例化完成、初始化完成（屬性也全部賦值了~）// 這一步我把它理解為校驗：校驗：校驗是否有循環引用問題~~~~~if (earlySingletonExposure) {// 注意此處第二個參數傳的false，表示不去三級緩存里singletonFactories再去調用一次getObject()方法了~~~// 上面建講到了由于B在初始化的時候，會觸發A的ObjectFactory.getObject() 所以a此處已經在二級緩存earlySingletonObjects里了// 因此此處返回A的實例：A@1234Object earlySingletonReference = getSingleton(beanName, false);if (earlySingletonReference != null) {// 這個等式表示，exposedObject若沒有再被代理過，這里就是相等的// 顯然此處我們的a對象的exposedObject它是沒有被代理過的所以if會進去~// 這種情況至此，就全部結束了~~~if (exposedObject == bean) {exposedObject = earlySingletonReference;}// 繼續以A為例，比如方法標注了@Aysnc注解，exposedObject此時候就是一個代理對象，因此就會進到這里來//hasDependentBean(beanName)是肯定為true，因為getDependentBeans(beanName)得到的是["b"]這個依賴else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {String[] dependentBeans = getDependentBeans(beanName);Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);// A@1234依賴的是["b"]，所以此處去檢查b// 如果最終存在實際依賴的bean：actualDependentBeans不為空那就拋出異常證明循環引用了~for (String dependentBean : dependentBeans) {// 這個判斷原則是：如果此時候b并還沒有創建好，this.alreadyCreated.contains(beanName)=true表示此bean已經被創建過，就返回false// 若該bean沒有在alreadyCreated緩存里，就是說沒被創建過(其實只有CreatedForTypeCheckOnly才會是此倉庫)if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {actualDependentBeans.add(dependentBean);}}if (!actualDependentBeans.isEmpty()) {throw new BeanCurrentlyInCreationException(beanName,"Bean with name '" + beanName + "' has been injected into other beans [" +StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +"] 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 " +"'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");}}}} }

由于關鍵代碼部分的步驟不太好拆分，為了更具象表達，那么使用下面一副圖示幫助小伙伴們理解：

最后的最后，由于我太暖心了_，再來個純文字版的總結。
依舊以上面A、B類使用屬性field注入循環依賴的例子為例，對整個流程做文字步驟總結如下：

使用context.getBean(A.class)，旨在獲取容器內的單例A(若A不存在，就會走A這個Bean的創建流程)，顯然初次獲取A是不存在的，因此走A的創建之路~

實例化A（注意此處僅僅是實例化），并將它放進緩存（此時A已經實例化完成，已經可以被引用了）

初始化A：@Autowired依賴注入B（此時需要去容器內獲取B）

為了完成依賴注入B，會通過getBean(B)去容器內找B。但此時B在容器內不存在，就走向B的創建之路~

實例化B，并將其放入緩存。（此時B也能夠被引用了）

初始化B，@Autowired依賴注入A（此時需要去容器內獲取A）

此處重要：初始化B時會調用getBean(A)去容器內找到A，上面我們已經說過了此時候因為A已經實例化完成了并且放進了緩存里，所以這個時候去看緩存里是已經存在A的引用了的，所以getBean(A)能夠正常返回

B初始化成功（此時已經注入A成功了，已成功持有A的引用了），return（注意此處return相當于是返回最上面的getBean(B)這句代碼，回到了初始化A的流程中~）。

因為B實例已經成功返回了，因此最終A也初始化成功

到此，B持有的已經是初始化完成的A，A持有的也是初始化完成的B，完美~

站的角度高一點，宏觀上看Spring處理循環依賴的整個流程就是如此。希望這個宏觀層面的總結能更加有助于小伙伴們對Spring解決循環依賴的原理的了解，同時也順便能解釋為何構造器循環依賴就不好使的原因。

循環依賴對AOP代理對象創建流程和結果的影響

我們都知道Spring AOP、事務等都是通過代理對象來實現的，而事務的代理對象是由自動代理創建器來自動完成的。也就是說Spring最終給我們放進容器里面的是一個代理對象，而非原始對象。

本文結合循環依賴，回頭再看AOP代理對象的創建過程，和最終放進容器內的動作，非常有意思。

@Service public class HelloServiceImpl implements HelloService {@Autowiredprivate HelloService helloService;@Transactional@Overridepublic Object hello(Integer id) {return "service hello";} }

此Service類使用到了事務，所以最終會生成一個JDK動態代理對象Proxy。剛好它又存在自己引用自己的循環依賴。看看這個Bean的創建概要描述如下：

protected Object doCreateBean( ... ){...// 這段告訴我們：如果允許循環依賴的話，此處會添加一個ObjectFactory到三級緩存里面，以備創建對象并且提前暴露引用~// 此處Tips：getEarlyBeanReference是后置處理器SmartInstantiationAwareBeanPostProcessor的一個方法，它的功效為：// 保證自己被循環依賴的時候，即使被別的Bean @Autowire進去的也是代理對象~~~~ AOP自動代理創建器此方法里會創建的代理對象~~~// Eagerly cache singletons to be able to resolve circular references// even when triggered by lifecycle interfaces like BeanFactoryAware.boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));if (earlySingletonExposure) { // 需要提前暴露（支持循環依賴），就注冊一個ObjectFactory到三級緩存addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));}// 此處注意：如果此處自己被循環依賴了那它會走上面的getEarlyBeanReference，從而創建一個代理對象從三級緩存轉移到二級緩存里// 注意此時候對象還在二級緩存里，并沒有在一級緩存。并且此時可以知道exposedObject仍舊是原始對象~~~populateBean(beanName, mbd, instanceWrapper);exposedObject = initializeBean(beanName, exposedObject, mbd);// 經過這兩大步后，exposedObject還是原始對象（注意此處以事務的AOP為例子的，// 因為事務的AOP自動代理創建器在getEarlyBeanReference創建代理后，initializeBean就不會再重復創建了，二選一的，下面會有描述~~~）...// 循環依賴校驗（非常重要）~~~~if (earlySingletonExposure) {// 前面說了因為自己被循環依賴了，所以此時候代理對象還在二級緩存里~~~（備注：本利講解的是自己被循環依賴了的情況）// so，此處getSingleton，就會把里面的對象拿出來，我們知道此時候它已經是個Proxy代理對象~~~// 最后賦值給exposedObject 然后return出去，進而最終被addSingleton()添加進一級緩存里面去 // 這樣就保證了我們容器里**最終實際上是代理對象**，而非原始對象~~~~~Object earlySingletonReference = getSingleton(beanName, false);if (earlySingletonReference != null) {if (exposedObject == bean) { // 這個判斷不可少（因為如果initializeBean改變了exposedObject ，就不能這么玩了，否則就是兩個對象了~~~）exposedObject = earlySingletonReference;}}...}}

上演示的是代理對象+自己存在循環依賴的case：Spring用三級緩存很巧妙的進行解決了。
若是這種case：代理對象，但是自己并不存在循環依賴，過程稍微有點不一樣兒了，如下描述：

protected Object doCreateBean( ... ) {...// 這些語句依舊會執行，三級緩存里是會加入的表示它支持被循環引用嘛~~~addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));...// 此處注意，因為它沒有被其它Bean循環引用（注意是循環引用，而不是直接引用~）,所以上面getEarlyBeanReference不會執行~// 也就是說此時二級緩存里并不會存在它~~~ 知曉這點特別的重要populateBean(beanName, mbd, instanceWrapper);// 重點在這：AnnotationAwareAspectJAutoProxyCreator自動代理創建器此處的postProcessAfterInitialization方法里，會給創建一個代理對象返回// 所以此部分執行完成后，exposedObject **已經是個代理對象**而不再是個原始對象了~~~~ 此時二級緩存里依舊無它，更別提一級緩存了exposedObject = initializeBean(beanName, exposedObject, mbd);...// 循環依賴校驗if (earlySingletonExposure) {// 前面說了一級、二級緩存里都木有它，然后這里傳的又是false（表示不看三級緩存~~）// 所以毋庸置疑earlySingletonReference = null so下面的邏輯就不用看了，直接return出去~~// 然后執行addSingleton()方法，由此可知容器里最終存在的也還是代理對象~~~~~~Object earlySingletonReference = getSingleton(beanName, false);if (earlySingletonReference != null) {if (exposedObject == bean) { // 這個判斷不可少（因為如果initializeBean改變了exposedObject ，就不能這么玩了，否則就是兩個對象了~~~）exposedObject = earlySingletonReference;}}.........} }

分析可知，即使自己只需要代理，并不被循環引用，最終存在Spring容器里的仍舊是代理對象。（so此時別人直接@Autowired進去的也是代理對象呀~~~）

終極case：如果我關閉Spring容器的循環依賴能力，也就是把allowCircularReferences設值為false，那么會不會造成什么問題呢？

// 它用于關閉循環引用（關閉后只要有循環引用現象就直接報錯~~） @Component public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {@Overridepublic void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {((AbstractAutowireCapableBeanFactory) beanFactory).setAllowCircularReferences(false);} }

若關閉了循環依賴后，還存在上面A、B的循環依賴現象，啟動便會報錯如下：

注意此處異常類型也是BeanCurrentlyInCreationException異常，但是文案內容和上面強調的有所區別~~
它報錯位置在：DefaultSingletonBeanRegistry.beforeSingletonCreation這個位置~

報錯淺析：在實例化A后給其屬性賦值時，會去實例化B。B實例化完成后會繼續給B屬性賦值，這時由于此時我們關閉了循環依賴，所以不存在提前暴露引用這么一說來給實用。因此B無法直接拿到A的引用地址，因此只能又去創建A的實例。而此時我們知道A其實已經正在創建中了，不能再創建了。so，就報錯了~

@Service public class HelloServiceImpl implements HelloService {// 因為管理了循環依賴，所以此處不能再依賴自己的// 但是：我們的此bean還是需要AOP代理的~~~//@Autowired//private HelloService helloService;@Transactional@Overridepublic Object hello(Integer id) {return "service hello";} }

這樣它的大致運行如下：

protected Object doCreateBean( ... ) {// 毫無疑問此時候earlySingletonExposure = false 也就是Bean都不會提前暴露引用了顯然就不能被循環依賴了~boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));...populateBean(beanName, mbd, instanceWrapper);// 若是事務的AOP 在這里會為源生Bean創建代理對象（因為上面沒有提前暴露這個代理）exposedObject = initializeBean(beanName, exposedObject, mbd);if (earlySingletonExposure) {... 這里更不用說，因為earlySingletonExposure=false 所以上面的代理對象exposedObject 直接return了~} }

可以看到即使把這個開關給關了，最終放進容器了的仍舊是代理對象，顯然@Autowired給屬性賦值的也一定是代理對象。

最后，以AbstractAutoProxyCreator為例看看自動代理創建器是怎么配合實現：循環依賴+創建代理

AbstractAutoProxyCreator是抽象類，它的三大實現子類InfrastructureAdvisorAutoProxyCreator、AspectJAwareAdvisorAutoProxyCreator、AnnotationAwareAspectJAutoProxyCreator小伙伴們應該會更加的熟悉些

該抽象類實現了創建代理的動作：

// @since 13.10.2003 它實現代理創建的方法有如下兩個 // 實現了SmartInstantiationAwareBeanPostProcessor 所以有方法getEarlyBeanReference來只能的解決循環引用問題：提前把代理對象暴露出去~ public abstract class AbstractAutoProxyCreator extends ProxyProcessorSupport implements SmartInstantiationAwareBeanPostProcessor, BeanFactoryAware {...// 下面兩個方法是自動代理創建器創建代理對象的唯二的兩個節點~// 提前暴露代理對象的引用它肯定在postProcessAfterInitialization之前執行// 所以它并不需要判斷啥的~~~~ 創建好后放進緩存earlyProxyReferences里注意此處value是原始Bean@Overridepublic Object getEarlyBeanReference(Object bean, String beanName) {Object cacheKey = getCacheKey(bean.getClass(), beanName);this.earlyProxyReferences.put(cacheKey, bean);return wrapIfNecessary(bean, beanName, cacheKey);}// 因為它會在getEarlyBeanReference之后執行，所以此處的重要邏輯是下面的判斷@Overridepublic Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {if (bean != null) {Object cacheKey = getCacheKey(bean.getClass(), beanName);// remove方法返回被移除的value，上面說了它記錄的是原始bean// 若被循環引用了，那就是執行了上面的`getEarlyBeanReference`方法，所以此時remove返回值肯定是==bean的（注意此時方法入參的bean還是原始對象）// 若沒有被循環引用，getEarlyBeanReference()不執行所以remove方法返回null，所以就進入if執行此處的創建代理對象方法~~~if (this.earlyProxyReferences.remove(cacheKey) != bean) {return wrapIfNecessary(bean, beanName, cacheKey);}}return bean;}... }

由上可知，自動代理創建器它保證了代理對象只會被創建一次，而且支持循環依賴的自動注入的依舊是代理對象。

上面分析了三種case，現給出結論如下：
不管是自己被循環依賴了還是沒有，甚至是把Spring容器的循環依賴給關了，它對AOP代理的創建流程有影響，但對結果是無影響的。
也就是說Spring很好的對調用者屏蔽了這些實現細節，使得使用者使用起來完全的無感知~

總結

解決此類問題的關鍵是要對SpringIOC和DI的整個流程做到心中有數，要理解好本文章，建議有【相關閱讀】里文章的大量知識的鋪墊，同時呢本文又能進一步的幫助小伙伴理解到Spring Bean的實例化、初始化流程。

本文還是花了我一番心思的，個人覺得對Spring這部分的處理流程描述得還是比較詳細的，希望我的總結能夠給大家帶來幫助。
另外為了避免循環依賴導致啟動問題而又不會解決，有如下建議：

業務代碼中盡量不要使用構造器注入，即使它有很多優點。

業務代碼中為了簡潔，盡量使用field注入而非setter方法注入

若你注入的同時，立馬需要處理一些邏輯（一般見于框架設計中，業務代碼中不太可能出現），可以使用setter方法注入輔助完成

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的Spring是如何利用“三级缓存“巧妙解决Bean的循环依赖问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： AutoML 在表数据中的研究与应用
下一篇：使用@Async异步注解导致该Bean在