摘要：我們知道為我們完全實例化好一個一定會經過一下三步實例化，其實也就是調用對象的構造方法實例化對象。循環依賴的產生定會發生在步驟和中，因為是利用構造方法，是利用屬性賦值。

基于Spring5+

什么是循環依賴？

循環依賴有幾種？

Spring可以解決哪幾種，為什么不能解決這幾種？

Spring是如何判斷存在循環依賴的？

什么是循環依賴？我們都知道Spring最大的作用就是來替我們管理Bean的，當然也包括Bean的創建以及整個生命周期，但是有這么一種情況，假設有三個類A、B、C需要交給Spring來管理，但A實例的創建需要先有B實例，而B實例的創建需要先有C實例，C實例的創建需要先有A實例，這樣三個類就自然形成了一個環狀結構，如果用代碼來表示，如下：

public class TestA {
    TestB testB;
    get;
    set;
}

public class TestB {
    TestC testC;
    get;
    set;
}

public class TestC {
    TestA testA;
    get;
    set;
}

這樣，三個類就彼此形成了一個環狀，那么Spring是如何來處理這樣的狀況呢？

有三種情況：

基于構造方法的循環依賴

基于setter構造的循環依賴(網上也叫field屬性依賴)

基于prototype范圍的依賴

首先說一下結論：除了第二種Spring可以幫我們解決，其它兩種都不能解決。我們知道Spring為我們完全實例化好一個Bean一定會經過一下三步：

createBeanInstance：實例化，其實也就是調用對象的構造方法實例化對象。

populateBean：填充屬性，這一步主要是多bean的依賴屬性進行填充。

initializeBean：調用默認的或者自定義的init方法。

循環依賴的產生定會發生在步驟1和2中，因為1是利用構造方法，2是利用屬性賦值。

先說結論基于構造器的循環依賴Spring是無法解決的，是因為沒有加入提前曝光的集合中，加入集合的條件是已經創建了Bean的包裝對象，而構造注入的時候，并沒有完成對象的創建，下面會有代碼說明。

測試用例：

xml文件：

測試類：

/**
 * description:測試通過有參構造方式注入產生的循環依賴問題
 * @author 70KG
 * @date 2018/12/21
 */
public class Test02 {

    @Test
    public void m1() {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("test02.xml");
    }

}

分析上面代碼：

Spring容器創建testA的Bean實例，首先去"當前創建Bean池"，查找是否當前Bean正在創建，如果沒發現，則繼續準備其需要的構造器參數testB，并將testA標識符放到"當前創建Bean池"。

Spring容器創建testB的Bean實例，首先去"當前創建Bean池"，查找是否當前Bean正在創建，如果沒發現，則繼續準備其需要的構造器參數testC，并將testB標識符放到"當前創建Bean池"。

Spring容器創建testC的Bean實例，首先去"當前創建Bean池"，查找是否當前Bean正在創建，如果沒發現，則繼續準備其需要的構造器參數testA，并將testC標識符放到"當前創建Bean池"。

到此為止Spring容器要去創建testA，但發現該Bean的標志符在"當前創建Bean池"中，表示了循環依賴，于是拋出BeanCurrentlyInCreationException異常。

其中"當前創建Bean池"就是一個Set集合，DefaultSingletonBeanRegistry類中beforeSingletonCreation方法，代碼如下：

protected void beforeSingletonCreation(String beanName) {
    if (!this.inCreationCheckExclusions.contains(beanName) && !this.singletonsCurrentlyInCreation.add(beanName)) {
        throw new BeanCurrentlyInCreationException(beanName);
    }
}

然后我們來到創建Bean實例的地方：

AbstractAutowireCapableBeanFactory類的543行，通過這個方法返回一個這個Bean的包裝對象：

--> instanceWrapper = createBeanInstance(beanName, mbd, args);----> 進入這個方法

--> AbstractAutowireCapableBeanFactory類的1129行

// Need to determine the constructor...
// 需要確定構造函數，也就是說構造方法的循環依賴會在這兒return
Constructor[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
if (ctors != null ||
        mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
        mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
    return autowireConstructor(beanName, mbd, ctors, args);
}

// No special handling: simply use no-arg constructor.
// 無需特殊處理，僅使用無參構造即可，setter的循環依賴會在這個地方return
return instantiateBean(beanName, mbd);

在上面代碼中返回Bean的包裝對象下面緊接著才是將這個對象曝光，也就是加入到SingletonFactory集合中，所以構造方法的循環引用，Spring是無法解決的，來到AbstractAutowireCapableBeanFactory的574行。

addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

首先說結論：Spring是可以為我們解決這樣的依賴的，原理說白了就是用了緩存處理，也就是常說的提前曝光，為什么叫提前曝光呢？因為這個緩存中的Bean是一個還未進行賦值的Bean，僅僅是一個引用而已。

xml文件：

測試類：

/**
 * description:通過setter注入產生的循環依賴問題
 * @author 70KG
 */
public class Test03 {
    @Test
    public void m1() {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("test03.xml");
    }
}

代碼分析：

Spring容器創建單例"loopA"，首先根據無參構造創建Bean，并暴露到Map(singletonFactories)中，并將"loopA"標志符放到當前創建正在創建的Bean池(singletonsCurrentlyInCreation)中，然后進行setter注入"loopB"。

Spring容器創建單例"loopB"，首先根據無參構造創建Bean，并暴露到Map(singletonFactories)中，并將"loopA"標志符放到當前創建正在創建的Bean池(singletonsCurrentlyInCreation)中，然后進行setter注入"loopC"。

Spring容器創建單例"loopC"，首先根據無參構造創建Bean，并暴露到Map(singletonFactories)中，并將"loopA"標志符放到當前創建正在創建的Bean池(singletonsCurrentlyInCreation)中，然后進行setter注入"loopA"。在注入"loopA"的時候，由于提前暴露在singletonFactories集合中了，利用它就可以取到"loopA"正在創建的Bean對象。

最后依賴注入"testB"，"testA"，完成setter注入。

查看控制臺輸出日志：

// 正在創建testA對象
Creating shared instance of singleton bean "testA"
Creating instance of bean "testA"
// 在緩存早期引用，目的是防止循環引用問題
Eagerly caching bean "testA" to allow for resolving potential circular references
Creating shared instance of singleton bean "testB"
Creating instance of bean "testB"
Eagerly caching bean "testB" to allow for resolving potential circular references
Creating shared instance of singleton bean "testC"
Creating instance of bean "testC"
Eagerly caching bean "testC" to allow for resolving potential circular references
// 在創建testC的時候會去緩存中拿原來存儲的testA，并返回，但此時的testA是一個不完全的對象，也就是尚未初始化
Returning eagerly cached instance of singleton bean "testA" that is not fully initialized yet - a consequence of a circular reference
// 緊接著完成C的創建，順便其它的也完成了
Finished creating instance of bean "testC"
Finished creating instance of bean "testB"
Finished creating instance of bean "testA"
Returning cached instance of singleton bean "testB"
Returning cached instance of singleton bean "testC"

基于setter的循環依賴利用了提前曝光機制，這一步的關鍵代碼，在AbstractAutowireCapableBeanFactory的574行，代碼如下：

addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

在加入SingletonFactory的前提是此Bean已經創建出來，才能夠加入到這個Map集合中，也就是提前曝光，可以讓別的Bean在初始化的時候從中拿到。否則是沒有機會加入到Map中的。

首先說結論，對于多例情況下的循環依賴，是無法解決的，因為Spring容器不進行緩存，更無法提前暴露。

測試用例：

xml文件：

測試類：

/**
 * description:通過setter注入產生的循環依賴問題
 * @author 70KG
 */
public class Test03 {

    @Test
    public void m1() {
        ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("test03.xml");
        LoopA loopA = context.getBean(LoopA.class);
        System.out.println(loopA);
    }

}

會拋出BeanCurrentlyInCreationException異常。

來到AbstractBeanFactory的246行，代碼如下：

Object sharedInstance = getSingleton(beanName);

這一步是從緩存中獲取以前創建的實例，如果發現存在，那么就存在循環依賴。

到此，全文完，自我感覺比其他的整理還算詳細，如有疑問，請留言。