天天看點
傳回

面試必殺技，講一講Spring中的循環依賴前言什麼是循環依賴？什麼情況下循環依賴可以被處理？Spring是如何解決的循環依賴？總結一道思考題

本系列文章： 聽說你還沒學Spring就被源碼編譯勸退了？30+張圖帶你玩轉Spring編譯 讀源碼，我們可以從第一行讀起 你知道Spring是怎麼解析配置類的嗎？ 配置類為什麼要添加@Configuration注解？ 談談Spring中的對象跟Bean，你知道Spring怎麼建立對象的嗎？ 這篇文章，我們來談一談Spring中的屬性注入 Spring中AOP相關的API及源碼解析，原來AOP是這樣子的 你知道Spring是怎麼将AOP應用到Bean的生命周期中的嗎? 推薦閱讀： Spring官網閱讀 | 總結篇 Spring雜談 本系列文章将會帶你一行行的将Spring的源碼吃透，推薦閱讀的文章是閱讀源碼的基礎！

@

TOC

前言

Spring中的循環依賴一直是Spring中一個很重要的話題，一方面是因為源碼中為了解決循環依賴做了很多處理，另外一方面是因為面試的時候，如果問到Spring中比較高階的問題，那麼循環依賴必定逃不掉。如果你回答得好，那麼這就是你的必殺技，反正，那就是面試官的必殺技，這也是取這個标題的原因，當然，本文的目的是為了讓你在之後的所有面試中能多一個必殺技，專門用來絕殺面試官！

本文的核心思想就是，

當面試官問：

“請講一講Spring中的循環依賴。”的時候，

我們到底該怎麼回答？

主要分下面幾點

  1. 什麼是循環依賴？
  2. 什麼情況下循環依賴可以被處理？
  3. Spring是如何解決的循環依賴？

同時本文希望糾正幾個目前業界内經常出現的幾個關于循環依賴的錯誤的說法

  1. 隻有在setter方式注入的情況下，循環依賴才能解決（錯）
  2. 三級緩存的目的是為了提高效率（錯）

OK，鋪墊已經做完了，接下來我們開始正文

從字面上來了解就是A依賴B的同時B也依賴了A，就像下面這樣

展現到代碼層次就是這個樣子

@Component
public class A {
    // A中注入了B
    @Autowired
    private B b;
}

@Component
public class B {
    // B中也注入了A
    @Autowired
    private A a;
}

當然，這是最常見的一種循環依賴，比較特殊的還有

// 自己依賴自己
@Component
public class A {
    // A中注入了A
    @Autowired
    private A a;
}

雖然展現形式不一樣，但是實際上都是同一個問題----->循環依賴

在回答這個問題之前首先要明确一點，Spring解決循環依賴是有前置條件的

  1. 出現循環依賴的Bean必須要是單例
  2. 依賴注入的方式不能全是構造器注入的方式（很多部落格上說，隻能解決setter方法的循環依賴，這是錯誤的）

其中第一點應該很好了解，第二點：不能全是構造器注入是什麼意思呢？我們還是用代碼說話

@Component
public class A {
//    @Autowired
//    private B b;
    public A(B b) {

    }
}


@Component
public class B {

//    @Autowired
//    private A a;

    public B(A a){

    }
}

在上面的例子中，A中注入B的方式是通過構造器，B中注入A的方式也是通過構造器，這個時候循環依賴是無法被解決，如果你的項目中有兩個這樣互相依賴的Bean，在啟動時就會報出以下錯誤：

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?

為了測試循環依賴的解決情況跟注入方式的關系，我們做如下四種情況的測試

依賴情況 依賴注入方式 循環依賴是否被解決
AB互相依賴（循環依賴） 均采用setter方法注入 是
均采用構造器注入 否
A中注入B的方式為setter方法，B中注入A的方式為構造器
B中注入A的方式為setter方法，A中注入B的方式為構造器

具體的測試代碼跟簡單，我就不放了。從上面的測試結果我們可以看到，不是隻有在setter方法注入的情況下循環依賴才能被解決，即使存在構造器注入的場景下，循環依賴依然被可以被正常處理掉。

那麼到底是為什麼呢？Spring到底是怎麼處理的循環依賴呢？不要急，我們接着往下看

關于循環依賴的解決方式應該要分兩種情況來讨論

  1. 簡單的循環依賴（沒有AOP）
  2. 結合了AOP的循環依賴

我們先來分析一個最簡單的例子，就是上面提到的那個demo

@Component
public class A {
    // A中注入了B
    @Autowired
    private B b;
}

@Component
public class B {
    // B中也注入了A
    @Autowired
    private A a;
}

通過上文我們已經知道了這種情況下的循環依賴是能夠被解決的，那麼具體的流程是什麼呢？我們一步步分析

首先，我們要知道Spring在建立Bean的時候預設是按照自然排序來進行建立的，是以第一步Spring會去建立A。

與此同時，我們應該知道，Spring在建立Bean的過程中分為三步

  1. 執行個體化，對應方法：

    AbstractAutowireCapableBeanFactory

     中的

    createBeanInstance

     方法
  2. 屬性注入，對應方法：

    AbstractAutowireCapableBeanFactory

     的

    populateBean
  3. 初始化，對應方法：

    AbstractAutowireCapableBeanFactory

    initializeBean

這些方法在之前源碼分析的文章中都做過詳細的解讀了，如果你之前沒看過我的文章，那麼你隻需要知道

  1. 執行個體化，簡單了解就是new了一個對象
  2. 屬性注入，為執行個體化中new出來的對象填充屬性
  3. 初始化，執行aware接口中的方法，初始化方法，完成

    AOP

     代理

基于上面的知識，我們開始解讀整個循環依賴處理的過程，整個流程應該是以A的建立為起點，前文也說了，第一步就是建立A嘛！

建立A的過程實際上就是調用

getBean

方法，這個方法有兩層含義

  1. 建立一個新的Bean
  2. 從緩存中擷取到已經被建立的對象

我們現在分析的是第一層含義，因為這個時候緩存中還沒有A嘛！

調用getSingleton(beanName)

首先調用

getSingleton(a)

方法，這個方法又會調用

getSingleton(beanName, true)

，在上圖中我省略了這一步

public Object getSingleton(String beanName) {
    return getSingleton(beanName, true);
}

getSingleton(beanName, true)

這個方法實際上就是到緩存中嘗試去擷取Bean，整個緩存分為三級

  1. singletonObjects

     ，一級緩存，存儲的是所有建立好了的單例Bean

  2. earlySingletonObjects

     ，完成執行個體化，但是還未進行屬性注入及初始化的對象

  3. singletonFactories

     ，提前暴露的一個單例工廠，二級緩存中存儲的就是從這個工廠中擷取到的對象

因為A是第一次被建立，是以不管哪個緩存中必然都是沒有的，是以會進入

getSingleton

的另外一個重載方法

getSingleton(beanName, singletonFactory)

。

調用getSingleton(beanName, singletonFactory)

這個方法就是用來建立Bean的，其源碼如下：

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
    Assert.notNull(beanName, "Bean name must not be null");
    synchronized (this.singletonObjects) {
        Object singletonObject = this.singletonObjects.get(beanName);
        if (singletonObject == null) {

            // ....
            // 省略異常處理及日志
            // ....

            // 在單例對象建立前先做一個标記
            // 将beanName放入到singletonsCurrentlyInCreation這個集合中
            // 标志着這個單例Bean正在建立
            // 如果同一個單例Bean多次被建立，這裡會抛出異常
            beforeSingletonCreation(beanName);
            boolean newSingleton = false;
            boolean recordSuppressedExceptions = (this.suppressedExceptions == null);
            if (recordSuppressedExceptions) {
                this.suppressedExceptions = new LinkedHashSet<>();
            }
            try {
                // 上遊傳入的lambda在這裡會被執行，調用createBean方法建立一個Bean後傳回
                singletonObject = singletonFactory.getObject();
                newSingleton = true;
            }
            // ...
            // 省略catch異常處理
            // ...
            finally {
                if (recordSuppressedExceptions) {
                    this.suppressedExceptions = null;
                }
                // 建立完成後将對應的beanName從singletonsCurrentlyInCreation移除
                afterSingletonCreation(beanName);
            }
            if (newSingleton) {
                // 添加到一級緩存singletonObjects中
                addSingleton(beanName, singletonObject);
            }
        }
        return singletonObject;
    }
}

上面的代碼我們主要抓住一點，通過

createBean

方法傳回的Bean最終被放到了一級緩存，也就是單例池中。

那麼到這裡我們可以得出一個結論：一級緩存中存儲的是已經完全建立好了的單例Bean

調用addSingletonFactory方法

如下圖所示：

在完成Bean的執行個體化後，屬性注入之前Spring将Bean包裝成一個工廠添加進了三級緩存中，對應源碼如下：

// 這裡傳入的參數也是一個lambda表達式，() -> getEarlyBeanReference(beanName, mbd, bean)
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
    Assert.notNull(singletonFactory, "Singleton factory must not be null");
    synchronized (this.singletonObjects) {
        if (!this.singletonObjects.containsKey(beanName)) {
            // 添加到三級緩存中
            this.singletonFactories.put(beanName, singletonFactory);
            this.earlySingletonObjects.remove(beanName);
            this.registeredSingletons.add(beanName);
        }
    }
}

這裡隻是添加了一個工廠，通過這個工廠（

ObjectFactory

）的

getObject

方法可以得到一個對象，而這個對象實際上就是通過

getEarlyBeanReference

這個方法建立的。那麼，什麼時候會去調用這個工廠的

getObject

方法呢？這個時候就要到建立B的流程了。

當A完成了執行個體化并添加進了三級緩存後，就要開始為A進行屬性注入了，在注入時發現A依賴了B，那麼這個時候Spring又會去

getBean(b)

，然後反射調用setter方法完成屬性注入。

因為B需要注入A，是以在建立B的時候，又會去調用

getBean(a)

，這個時候就又回到之前的流程了，但是不同的是，之前的

getBean

是為了建立Bean，而此時再調用

getBean

不是為了建立了，而是要從緩存中擷取，因為之前A在執行個體化後已經将其放入了三級緩存

singletonFactories

中，是以此時

getBean(a)

的流程就是這樣子了

從這裡我們可以看出，注入到B中的A是通過

getEarlyBeanReference

方法提前暴露出去的一個對象，還不是一個完整的Bean，那麼

getEarlyBeanReference

到底幹了啥了，我們看下它的源碼

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

它實際上就是調用了後置處理器的

getEarlyBeanReference

，而真正實作了這個方法的後置處理器隻有一個，就是通過

@EnableAspectJAutoProxy

注解導入的

AnnotationAwareAspectJAutoProxyCreator

。也就是說如果在不考慮

AOP

的情況下，上面的代碼等價于：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    return exposedObject;
}

也就是說這個工廠啥都沒幹，直接将執行個體化階段建立的對象傳回了！是以說在不考慮

AOP

的情況下三級緩存有用嘛？講道理，真的沒什麼用，我直接将這個對象放到二級緩存中不是一點問題都沒有嗎？如果你說它提高了效率，那你告訴我提高的效率在哪?

那麼三級緩存到底有什麼作用呢？不要急，我們先把整個流程走完，在下文結合

AOP

分析循環依賴的時候你就能體會到三級緩存的作用！

到這裡不知道小夥伴們會不會有疑問，B中提前注入了一個沒有經過初始化的A類型對象不會有問題嗎？

答：不會

這個時候我們需要将整個建立A這個Bean的流程走完，如下圖：

從上圖中我們可以看到，雖然在建立B時會提前給B注入了一個還未初始化的A對象，但是在建立A的流程中一直使用的是注入到B中的A對象的引用，之後會根據這個引用對A進行初始化，是以這是沒有問題的。

之前我們已經說過了，在普通的循環依賴的情況下，三級緩存沒有任何作用。三級緩存實際上跟Spring中的

AOP

相關，我們再來看一看

getEarlyBeanReference

的代碼：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }
        }
    }
    return exposedObject;
}

如果在開啟

AOP

的情況下，那麼就是調用到

AnnotationAwareAspectJAutoProxyCreator

getEarlyBeanReference

方法，對應的源碼如下：

public Object getEarlyBeanReference(Object bean, String beanName) {
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    this.earlyProxyReferences.put(cacheKey, bean);
    // 如果需要代理，傳回一個代理對象，不需要代理，直接傳回目前傳入的這個bean對象
    return wrapIfNecessary(bean, beanName, cacheKey);
}

回到上面的例子，我們對A進行了

AOP

代理的話，那麼此時

getEarlyBeanReference

将傳回一個代理後的對象，而不是執行個體化階段建立的對象，這樣就意味着B中注入的A将是一個代理對象而不是A的執行個體化階段建立後的對象。

看到這個圖你可能會産生下面這些疑問

  1. 在給B注入的時候為什麼要注入一個代理對象？

答：當我們對A進行了

AOP

代理時，說明我們希望從容器中擷取到的就是A代理後的對象而不是A本身，是以把A當作依賴進行注入時也要注入它的代理對象

  1. 明明初始化的時候是A對象，那麼Spring是在哪裡将代理對象放入到容器中的呢？

在完成初始化後，Spring又調用了一次

getSingleton

方法，這一次傳入的參數又不一樣了，false可以了解為禁用三級緩存，前面圖中已經提到過了，在為B中注入A時已經将三級緩存中的工廠取出，并從工廠中擷取到了一個對象放入到了二級緩存中，是以這裡的這個

getSingleton

方法做的時間就是從二級緩存中擷取到這個代理後的A對象。

exposedObject == bean

可以認為是必定成立的，除非你非要在初始化階段的後置處理器中替換掉正常流程中的Bean，例如增加一個後置處理器：

@Component
public class MyPostProcessor implements BeanPostProcessor {
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        if (beanName.equals("a")) {
            return new A();
        }
        return bean;
    }
}

不過，請不要做這種騷操作，徒增煩惱！

  1. 初始化的時候是對A對象本身進行初始化，而容器中以及注入到B中的都是代理對象，這樣不會有問題嗎？

答：不會，這是因為不管是

cglib

代理還是

jdk

動态代理生成的代理類，内部都持有一個目标類的引用，當調用代理對象的方法時，實際會去調用目标對象的方法，A完成初始化相當于代理對象自身也完成了初始化

  1. 三級緩存為什麼要使用工廠而不是直接使用引用？換而言之，為什麼需要這個三級緩存，直接通過二級緩存暴露一個引用不行嗎？

答：這個工廠的目的在于延遲對執行個體化階段生成的對象的代理，隻有真正發生循環依賴的時候，才去提前生成代理對象，否則隻會建立一個工廠并将其放入到三級緩存中，但是不會去通過這個工廠去真正建立對象

我們思考一種簡單的情況，就以單獨建立A為例，假設AB之間現在沒有依賴關系，但是A被代理了，這個時候當A完成執行個體化後還是會進入下面這段代碼：

// A是單例的，mbd.isSingleton()條件滿足
// allowCircularReferences：這個變量代表是否允許循環依賴，預設是開啟的，條件也滿足
// isSingletonCurrentlyInCreation：正在在建立A，也滿足
// 是以earlySingletonExposure=true
boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                                  isSingletonCurrentlyInCreation(beanName));
// 還是會進入到這段代碼中
if (earlySingletonExposure) {
    // 還是會通過三級緩存提前暴露一個工廠對象
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

看到了吧，即使沒有循環依賴，也會将其添加到三級緩存中，而且是不得不添加到三級緩存中，因為到目前為止Spring也不能确定這個Bean有沒有跟别的Bean出現循環依賴。

假設我們在這裡直接使用二級緩存的話，那麼意味着所有的Bean在這一步都要完成

AOP

代理。這樣做有必要嗎？

不僅沒有必要，而且違背了Spring在結合

AOP

跟Bean的生命周期的設計！Spring結合

AOP

跟Bean的生命周期本身就是通過

AnnotationAwareAspectJAutoProxyCreator

這個後置處理器來完成的，在這個後置處理的

postProcessAfterInitialization

方法中對初始化後的Bean完成

AOP

代理。如果出現了循環依賴，那沒有辦法，隻有給Bean先建立代理，但是沒有出現循環依賴的情況下，設計之初就是讓Bean在生命周期的最後一步完成代理而不是在執行個體化後就立馬完成代理。

三級緩存真的提高了效率了嗎？

現在我們已經知道了三級緩存的真正作用，但是這個答案可能還無法說服你，是以我們再最後總結分析一波，三級緩存真的提高了效率了嗎？分為兩點讨論：

  1. 沒有進行

    AOP

     的Bean間的循環依賴

從上文分析可以看出，這種情況下三級緩存根本沒用！是以不會存在什麼提高了效率的說法

  1. 進行了

    AOP

就以我們上的A、B為例，其中A被

AOP

代理，我們先分析下使用了三級緩存的情況下，A、B的建立流程

假設不使用三級緩存，直接在二級緩存中

上面兩個流程的唯一差別在于為A對象建立代理的時機不同，在使用了三級緩存的情況下為A建立代理的時機是在B中需要注入A的時候，而不使用三級緩存的話在A執行個體化後就需要馬上為A建立代理然後放入到二級緩存中去。對于整個A、B的建立過程而言，消耗的時間是一樣的

綜上，不管是哪種情況，三級緩存提高了效率這種說法都是錯誤的！

總結

面試官：”Spring是如何解決的循環依賴？“

答：Spring通過三級緩存解決了循環依賴，其中一級緩存為單例池（

singletonObjects

）,二級緩存為早期曝光對象

earlySingletonObjects

，三級緩存為早期曝光對象工廠（

singletonFactories

）。當A、B兩個類發生循環引用時，在A完成執行個體化後，就使用執行個體化後的對象去建立一個對象工廠，并添加到三級緩存中，如果A被AOP代理，那麼通過這個工廠擷取到的就是A代理後的對象，如果A沒有被AOP代理，那麼這個工廠擷取到的就是A執行個體化的對象。當A進行屬性注入時，會去建立B，同時B又依賴了A，是以建立B的同時又會去調用getBean(a)來擷取需要的依賴，此時的getBean(a)會從緩存中擷取，第一步，先擷取到三級緩存中的工廠；第二步，調用對象工工廠的getObject方法來擷取到對應的對象，得到這個對象後将其注入到B中。緊接着B會走完它的生命周期流程，包括初始化、後置處理器等。當B建立完後，會将B再注入到A中，此時A再完成它的整個生命周期。至此，循環依賴結束！

面試官：”為什麼要使用三級緩存呢？二級緩存能解決循環依賴嗎？“

答：如果要使用二級緩存解決循環依賴，意味着所有Bean在執行個體化後就要完成AOP代理，這樣違背了Spring設計的原則，Spring在設計之初就是通過

AnnotationAwareAspectJAutoProxyCreator

這個後置處理器來在Bean生命周期的最後一步來完成AOP代理，而不是在執行個體化後就立馬進行AOP代理。

一道思考題

為什麼在下表中的第三種情況的循環依賴能被解決，而第四種情況不能被解決呢？

提示：Spring在建立Bean時預設會根據自然排序進行建立，是以A會先于B進行建立

如果本文對你由幫助的話，記得點個贊吧！也歡迎關注我的公衆号，微信搜尋：程式員DMZ，或者掃描下方二維碼，跟着我一起認認真真學Java,踏踏實實做一個coder。

我叫DMZ，一個在學習路上匍匐前行的小菜鳥！

存儲 緩存 java 程式員 api spring 容器 spring二級緩存java spring環境變量docker spring docker問題 java spring緩存 spring經典面試
上一篇: 資料治理中 PyODPS 的正确使用方式
下一篇: 阿裡雲輕量級應用伺服器是什麼？阿裡雲伺服器和VPS有什麼差別

繼續閱讀