主要分下面幾點(diǎn)：

1. 什么是循環(huán)依賴？
2. 什么情況下循環(huán)依賴可以被處理？
3. Spring是如何解決的循環(huán)依賴？

同時(shí)本文希望糾正幾個(gè)目前業(yè)界內(nèi)經(jīng)常出現(xiàn)的幾個(gè)關(guān)于循環(huán)依賴的錯(cuò)誤的說法：

• 只有在setter方式注入的情況下，循環(huán)依賴才能解決（錯(cuò)）
• 使用第三級緩存的目的是為了提高效率（錯(cuò)）

二、什么是循環(huán)依賴

通俗來講，循環(huán)依賴指的是一個(gè)實(shí)例或多個(gè)實(shí)例存在相互依賴的關(guān)系（類之間循環(huán)嵌套引用）。

舉個(gè)例子

@Component

public class AService {

? ? // A中注入了B

? ? @Autowired

? ? private BService bService;

}

?

@Component

public class BService {

? ? // B中也注入了A

? ? @Autowired

? ? private AService aService;

}

?

上述例子中?AService?依賴了?BService，BService?也依賴了?AService，這就是兩個(gè)對象之間的相互依賴。

當(dāng)然循環(huán)依賴還包括?自身依賴、多個(gè)實(shí)例之間相互依賴（A依賴于B，B依賴于C，C又依賴于A）。

// 自己依賴自己

@Component

public class A {

? ? // A中注入了A

? ? @Autowired

? ? private A a;

}

?

?

如果我們在普通Java環(huán)境下正常運(yùn)行上面的代碼調(diào)用?AService?對象并不會出現(xiàn)問題，也就是說普通對象就算出現(xiàn)循環(huán)依賴也不會存在問題，因?yàn)閷ο笾g存在依賴關(guān)系是很常見的，那么為什么被 Spring 容器管理后的對象有循環(huán)依賴的情況會出現(xiàn)問題呢？

三、Spring Bean 的循環(huán)依賴問題

被 Spring 容器管理的對象叫做 Bean，為什么 Bean 會存在循環(huán)依賴問題呢？

想要了解 Bean 的循環(huán)依賴問題，首先需要了解 Bean 是如何創(chuàng)建的（需要了解Bean的生命周期）。

3.1 Bean 的創(chuàng)建步驟

為了能更好的展示出現(xiàn)循環(huán)依賴問題的環(huán)節(jié)，所以這里的 Bean 創(chuàng)建步驟做了簡化：

1. 在創(chuàng)建 Bean 之前，Spring 會通過掃描獲取 BeanDefinition。
2. BeanDefinition就緒后會讀取 BeanDefinition 中所對應(yīng)的 class 來加載類。
3. 實(shí)例化階段：根據(jù)構(gòu)造函數(shù)來完成實(shí)例化 （未屬性注入以及初始化的對象 這里簡稱為 原始對象）
4. 屬性注入階段：對 Bean 的屬性進(jìn)行依賴注入 （這里就是發(fā)生循環(huán)依賴問題的環(huán)節(jié)）
5. 如果 Bean 的某個(gè)方法有AOP操作，則需要根據(jù)原始對象生成代理對象。
6. 最后把代理對象放入單例池（一級緩存singletonObjects）中。

兩點(diǎn)說明：

• 上面的 Bean 創(chuàng)建步驟是對于 單例（singleton） 作用域的 Bean。
• Spring 的 AOP 代理就是作為 BeanPostProcessor 實(shí)現(xiàn)的，而 BeanPostProcessor 是發(fā)生在屬性注入階段后的，所以 AOP 是在 屬性注入 后執(zhí)行的。

3.2 為什么 Spring Bean 會產(chǎn)生循環(huán)依賴問題？

通過上面的 Bean 創(chuàng)建步驟可知：實(shí)例化 Bean 后會進(jìn)行 屬性注入（依賴注入）。

如最初舉例的 AService 和 BService 的依賴關(guān)系，當(dāng) AService 創(chuàng)建時(shí)，會先對 AService 進(jìn)行實(shí)例化生成一個(gè)原始對象，然后在進(jìn)行屬性注入時(shí)發(fā)現(xiàn)了需要 BService 對應(yīng)的 Bean，此時(shí)就會去為 BService 進(jìn)行創(chuàng)建，在 BService 實(shí)例化后生成一個(gè)原始對象后進(jìn)行屬性注入，此時(shí)會發(fā)現(xiàn)也需要 AService 對應(yīng)的 Bean。

這樣就會造成?AService?和?BService?的 Bean 都無法創(chuàng)建，就會產(chǎn)生?循環(huán)依賴?問題。

而這種情況只會在將Bean交給Spring管理的時(shí)候才會出現(xiàn)，因?yàn)樯厦娴倪@些屬性注入操作都是Spring去做的，如果只是我們自己在Java中創(chuàng)建對象可以不去注入屬性，讓成員屬性為NULL也可以正常執(zhí)行的，這樣也就不會出現(xiàn)循環(huán)依賴的問題了。

3.3 什么情況下循環(huán)依賴可以被處理？

Spring 并不能解決所有 Bean 的循環(huán)依賴問題，接下來通過例子來看看哪些場景下的循環(huán)依賴問題是可以被解決的。

Spring中循環(huán)依賴場景有：?

（1）構(gòu)造器的循環(huán)依賴?

（2）field屬性的循環(huán)依賴。

在回答什么情況下循環(huán)依賴問題可以被解決前，首先要明確一點(diǎn)，Spring解決循環(huán)依賴是有前置條件的：

• 出現(xiàn)循環(huán)依賴的Bean必須要是單例
• 依賴注入的方式不能全是構(gòu)造器注入的方式（很多博客上說，只能解決setter方法的循環(huán)依賴，這是錯(cuò)誤的）

其中第一點(diǎn)應(yīng)該很好理解，如果原型的Bean出現(xiàn)循環(huán)依賴，Spring會直接報(bào)錯(cuò)，Spring 無法解決?原型作用域?出現(xiàn)的循環(huán)依賴問題。因?yàn)?Spring 不會緩存?原型?作用域的 Bean，而 Spring 依靠?緩存?來解決循環(huán)依賴問題，所以 Spring 無法解決?原型?作用域的 Bean。Spring Bean默認(rèn)都是單例的。

第二點(diǎn)：不能全是構(gòu)造器注入是什么意思呢？我們還是用代碼說話：

@Component

public class A {

? ? public A(B b) {

? ? }

}

@Component

public class B {

? ? public B(A a){

? ? }

}

在上面的例子中，A中注入B的方式是通過構(gòu)造器，B中注入A的方式也是通過構(gòu)造器，這個(gè)時(shí)候循環(huán)依賴是無法被解決，如果你的項(xiàng)目中有兩個(gè)這樣相互依賴的Bean，在啟動時(shí)就會報(bào)出以下錯(cuò)誤：

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?

?

以上報(bào)錯(cuò)說明 Spring 無法解決?構(gòu)造器注入?出現(xiàn)的循環(huán)依賴問題。因?yàn)?構(gòu)造器注入?發(fā)生在?實(shí)例化階段，而 Spring 解決循環(huán)依賴問題依靠的?三級緩存?在?屬性注入階段，也就是說調(diào)用構(gòu)造函數(shù)時(shí)還未能放入三級緩存中，所以無法解決?構(gòu)造器注入?的循環(huán)依賴問題。

?

?

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

具體的測試代碼跟簡單，我就不放了。從上面的測試結(jié)果我們可以看到，不是只有在setter方法注入的情況下循環(huán)依賴才能被解決（setter注入可以利用三級緩存解決循環(huán)依賴問題），即使存在構(gòu)造器注入的場景下，循環(huán)依賴依然被可以被正常處理掉。

那么到底是為什么呢？Spring到底是怎么處理的循環(huán)依賴呢？不要急，我們接著往下看。

四、Spring 如何解決循環(huán)依賴問題？

Spring的循環(huán)依賴的理論依據(jù)其實(shí)是基于Java的引用傳遞，當(dāng)我們獲取到對象的引用時(shí)，對象的field或則屬性是可以延后設(shè)置的(但是構(gòu)造器必須是在獲取引用之前)。

Spring 是靠?三級緩存?來解決循環(huán)依賴問題的，接下來了解一下?什么是三級緩存?以及?解決循環(huán)依賴問題的具體流程。

4.0 什么是三級緩存

那么Spring如何解決的循環(huán)依賴問題呢，對于單例來說，在Spring容器整個(gè)生命周期內(nèi)，有且只有一個(gè)對象，所以很容易想到這個(gè)對象應(yīng)該存在Cache中，Spring為了解決單例的循環(huán)依賴問題，使用了三級緩存。

這三個(gè)緩存都是定義在DefaultSingletonBeanRegistry類中的：

/** Cache of singleton objects: bean name --> bean instance */

// 單例對象的cache：一級緩存

private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);

?

/** Cache of early singleton objects: bean name --> bean instance */

// 提前暴光的單例對象的Cache：二級緩存

private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

?

/** Cache of singleton factories: bean name --> ObjectFactory */

// 單例對象工廠的cache：三級緩存

private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);

?

循環(huán)依賴主要的三級緩存分別是 ：

1. singletonObbjects：一級緩存單例池，主要存放最終形態(tài)的單例bean；我們一般獲取一個(gè)bean都是從這個(gè)緩存中獲?。恍枰f明的是并不是所有單例bean都存在這個(gè)緩存當(dāng)中，有些特殊的單例bean不存在這個(gè)緩存當(dāng)中

1. earlySingletonObjects：二級緩存，主要存放的是過渡bean（原始對象/原始對象的代理對象）；也就是從三級緩存當(dāng)中產(chǎn)生出來的對象；它的作用是防止在多級循環(huán)依賴的情況下重復(fù)從三級緩存當(dāng)中創(chuàng)建對象，其他對象都可以直接從二級緩存中獲取到原始對象（的代理對象）；因?yàn)槿壘彺娈?dāng)中創(chuàng)建對象是需要犧牲一定得性能；有了這個(gè)緩存可以一定程度上提高效率（但是提高的效率并不明顯）。只有在調(diào)用了三級緩存中的ObjectFactory的getObject() 方法獲取原始對象（的代理對象）時(shí)，才會將原始對象（的代理對象）放入二級緩存，而調(diào)用三級緩存中的ObjectFactory的getObject() 方法獲取原始對象（的代理對象）這種情況只會發(fā)生在有循環(huán)依賴的時(shí)候，所以，二級緩存在沒有循環(huán)依賴的情況下不會被使用到。二級緩存是為了提前暴露 Bean 來解決循環(huán)依賴問題，此時(shí)的 Bean 可能還沒有進(jìn)行屬性注入，只有等完成了屬性注入、初始化后的 Bean 才會上移到一級緩存（單例池）中。

1. singletonFactories 三級緩存，用于存放原始對象對應(yīng)的ObjectFactory，它的作用主要是為了產(chǎn)生一個(gè)對象；每生成一個(gè)原始對象，都會將這個(gè)原始對象對應(yīng)的ObjectFactory放到三級緩存中，通過調(diào)用ObjectFactory的getObject() 方法，就能夠在需要?jiǎng)討B(tài)代理的情況下為原始對象生成代理對象并返回，否則返回原始對象，以此來處理循環(huán)依賴時(shí)還需要?jiǎng)討B(tài)代理的情況。

因?yàn)檫@個(gè)緩存當(dāng)中存到的是一個(gè)工廠；可以產(chǎn)生特定對象；程序員可以去擴(kuò)展BeanPostProcessor來定制這個(gè)工廠產(chǎn)生對象的過程；比如AOP就是擴(kuò)展了這個(gè)工廠的產(chǎn)生過程；從而完成完整的aop功能；如果沒有這個(gè)緩存那么極端情況下會出現(xiàn)循環(huán)依賴注入的bean不是一個(gè)完整的bean，或者說是一個(gè)錯(cuò)誤的bean。

為什么會存在三級緩存，主要原因就是：延遲代理對象的創(chuàng)建。設(shè)想一下，如果在實(shí)例化出一個(gè)原始對象的時(shí)候，就直接將這個(gè)原始對象的代理對象創(chuàng)建出來（如果需要?jiǎng)?chuàng)建的話），然后就放在二級緩存中，似乎感覺三級緩存就沒有存在的必要了對吧，但是請打住，這里存在的問題就是，如果真這么做了，那么每一個(gè)對象在實(shí)例化出原始對象后，就都會去創(chuàng)建代理對象，而Spring的原始設(shè)計(jì)中，代理對象的創(chuàng)建應(yīng)該是由AnnotationAwareAspectJAutoProxyCreator這個(gè)后置處理器的postProcessAfterInitialization() 來完成，也就是：在對象初始化完畢后，再去創(chuàng)建代理對象。如果真的只用兩個(gè)緩存來解決循環(huán)依賴，那么就會打破Spring對AOP的一個(gè)設(shè)計(jì)思想。

下面我們就通過分析源碼，來講解Spring是如何解決循環(huán)依賴為題的。關(guān)于循環(huán)依賴的解決方式應(yīng)該要分兩種情況來討論：

1. 簡單的循環(huán)依賴（沒有AOP）
2. 結(jié)合了AOP的循環(huán)依賴

4.1 簡單的循環(huán)依賴（沒有AOP）

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

@Component

public class A {

? ? // A中注入了B

? ? @Autowired

? ? private B b;

}

?

@Component

public class B {

? ? // B中也注入了A

? ? @Autowired

? ? private A a;

}

通過上文我們已經(jīng)知道了這種情況下的循環(huán)依賴是能夠被解決的，那么具體的流程是什么呢？我們一步步分析。

首先，我們要知道Spring在創(chuàng)建Bean的時(shí)候默認(rèn)是按照自然排序來進(jìn)行創(chuàng)建的（按照Bean名稱字典序，比如A類就要早于B類被創(chuàng)建），所以第一步Spring會去創(chuàng)建A。

與此同時(shí)，我們應(yīng)該知道，Spring在創(chuàng)建Bean的過程中分為三步：

1. 實(shí)例化，其實(shí)也就是調(diào)用對象的構(gòu)造方法實(shí)例化對象。對應(yīng)方法：AbstractAutowireCapableBeanFactory中的createBeanInstance方法
2. 屬性注入，這一步主要是對bean的依賴屬性進(jìn)行填充。對應(yīng)方法：AbstractAutowireCapableBeanFactory的populateBean方法
3. 初始化，在屬性注入之后，Spring會調(diào)用設(shè)置的init()方法來進(jìn)行初始化，對Bean進(jìn)一步進(jìn)行處理完善。對應(yīng)方法：AbstractAutowireCapableBeanFactory的initializeBean方法

這些方法在之前源碼分析的文章中都做過詳細(xì)的解讀了，如果你之前沒看過我的文章，那么你只需要知道：

1. 實(shí)例化，簡單理解就是new了一個(gè)對象
2. 屬性注入，為實(shí)例化中new出來的對象填充屬性
3. 初始化，執(zhí)行aware接口中的方法，初始化方法，完成AOP代理

其實(shí)我們簡單的思考一下就發(fā)現(xiàn)，出現(xiàn)循環(huán)依賴的問題主要在 （1）和 （2）兩個(gè)步驟上，也就是也就是（1）實(shí)例化階段會造成構(gòu)造器循環(huán)依賴和（2）屬性注入階段會造成field循環(huán)依賴。

4.1.0 創(chuàng)建Bean的前期流程源碼分析

我們先講一下創(chuàng)建Bean的前期流程，這些內(nèi)容其實(shí)在之前IOC源碼筆記中已經(jīng)講過了，這里我們就簡要復(fù)習(xí)一下。

在Spring中，如果基于XML配置bean，那么使用的容器為ClassPathXmlApplicationContext，如果是基于注解配置bean，則使用的容器為AnnotationConfigApplicationContext。以AnnotationConfigApplicationContext為例，其構(gòu)造函數(shù)如下所示：

public AnnotationConfigApplicationContext(Class<?>... componentClasses) {

? ? this();

? ? register(componentClasses);

? ? // 初始化容器

? ? refresh();

}

?

在AnnotationConfigApplicationContext的構(gòu)造函數(shù)中會調(diào)用到AbstractApplicationContext的refresh() 方法，實(shí)際上無論是基于XML配置bean，還是基于注解配置bean，亦或者是Springboot中，在初始化容器時(shí)都會調(diào)用到AbstractApplicationContext的refresh() 方法中。下面看一下refresh() 方法：

public void refresh() throws BeansException, IllegalStateException {

? ? synchronized (this.startupShutdownMonitor) {

? ? ? ? StartupStep contextRefresh = this.applicationStartup.start("spring.context.refresh");

? ? ? ? // ......

? ? ? ? try {

? ? ? ? ? ?

? ? ? ? ? ? // ......

? ? ? ? ? ? // 初始化所有非延時(shí)加載的單例bean

? ? ? ? ? ? finishBeanFactoryInitialization(beanFactory);

? ? ? ? ? ? // ......

? ? ? ? }

? ? ? ? catch (BeansException ex) {

? ? ? ? ? ?

? ? ? ? ? ? // ......

? ? ? ? ? ? throw ex;

? ? ? ? }

? ? ? ? finally {

? ? ? ? ? ? resetCommonCaches();

? ? ? ? ? ? contextRefresh.end();

? ? ? ? }

? ? }

}

重點(diǎn)關(guān)心refresh()?方法中調(diào)用的finishBeanFactoryInitialization()?方法，該方法會初始化所有非延時(shí)加載的單例bean（也就是提前將非延遲加載的單例Bean裝配到Spring容器中），其實(shí)現(xiàn)如下：

protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {

? ? if (beanFactory.containsBean(CONVERSION_SERVICE_BEAN_NAME) &&

? ? ? ? ? ? beanFactory.isTypeMatch(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class)) {

? ? ? ? beanFactory.setConversionService(

? ? ? ? ? ? ? ? beanFactory.getBean(CONVERSION_SERVICE_BEAN_NAME, ConversionService.class));

? ? }

? ?

? ? if (!beanFactory.hasEmbeddedValueResolver()) {

? ? ? ? beanFactory.addEmbeddedValueResolver(strVal -> getEnvironment().resolvePlaceholders(strVal));

? ? }

? ? String[] weaverAwareNames = beanFactory.getBeanNamesForType(LoadTimeWeaverAware.class, false, false);

? ? for (String weaverAwareName : weaverAwareNames) {

? ? ? ? getBean(weaverAwareName);

? ? }

? ? beanFactory.setTempClassLoader(null);

? ? beanFactory.freezeConfiguration();

? ? // 初始化所有非延時(shí)加載的單例bean

? ? beanFactory.preInstantiateSingletons();

}

在finishBeanFactoryInitialization()?方法中會調(diào)用到DefaultListableBeanFactory的preInstantiateSingletons()?方法，如下所示：

public void preInstantiateSingletons() throws BeansException {

? ? // ......

? ? List<String> beanNames = new ArrayList<>(this.beanDefinitionNames);

? ? // 在這個(gè)循環(huán)中通過getBean()方法初始化bean

? ? for (String beanName : beanNames) {

? ? ? ? RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);

? ? ? ? if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {

? ? ? ? ? ? // 判斷是否是FactoryBean

? ? ? ? ? ? if (isFactoryBean(beanName)) {

? ? ? ? ? ? ? ? // ......

? ? ? ? ? ? }

? ? ? ? ? ? else {

? ? ? ? ? ? ? ? // 不是FactoryBean，則通過getBean()方法來初始化bean

? ? ? ? ? ? ? ? getBean(beanName);

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? // ......

}

到了這里我們就了解到Spring中初始化bean，是通過調(diào)用容器的getBean()?方法來完成，在getBean()?方法中如果獲取不到bean，此時(shí)就會初始化這個(gè)bean。所以開始創(chuàng)建Bean的流程是從AbstractBeanFactory的getBean()?方法開始的，這也是我們講解循環(huán)依賴的重點(diǎn)。AbstractBeanFactory的getBean()?方法的實(shí)現(xiàn)如下：

public Object getBean(String name) throws BeansException {

? ? // 有三種情況會調(diào)用到這里

? ? // 1. 容器啟動的時(shí)候初始化A，所以調(diào)用到這里以進(jìn)行A的初始化

? ? // 2. 初始化A的時(shí)候要屬性注入B，所以調(diào)用到這里以進(jìn)行B的初始化

? ? // 3. 初始化B的時(shí)候要屬性注入A，所以調(diào)用到這里以獲取A的bean

? ? return doGetBean(name, null, null, false); // 最終會調(diào)用doGetBean()

}

基于上面的知識，我們開始解讀整個(gè)循環(huán)依賴處理的過程，整個(gè)流程應(yīng)該是以A的創(chuàng)建為起點(diǎn)，前文也說了，第一步就是創(chuàng)建A嘛！

創(chuàng)建A的過程實(shí)際上就是調(diào)用getBean方法，這個(gè)方法有兩層含義：

1. 創(chuàng)建一個(gè)新的Bean
2. 從緩存中獲取到已經(jīng)被創(chuàng)建的對象

我們現(xiàn)在分析的是第一層含義，因?yàn)檫@個(gè)時(shí)候緩存中還沒有A嘛！

下面我們來從源碼的層面，梳理 Spring 解決 Bean 的循環(huán)依賴的整個(gè)流程。

4.1.1 創(chuàng)建A：調(diào)用doGetBean()

上面已經(jīng)分析過了，創(chuàng)建A的流程從 AbstractApplicationContext 的 refresh() 方法出發(fā)，進(jìn)入 finishBeanFactoryInitialization() 方法再進(jìn)入 preInstantiateSingletons() 方法再進(jìn)入 getBean() 方法再進(jìn)入 doGetBean() 方法。

下面我們來看看?doGetBean()?方法：

AbstractBeanFactory.java

@SuppressWarnings("unchecked")

? ? protected <T> T doGetBean(

? ? ? ? ? ? String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly)

? ? ? ? ? ? throws BeansException {

? ? String beanName = transformedBeanName(name);

? ? Object bean;

? ? // Eagerly check singleton cache for manually registered singletons.

? ? // 1、第一個(gè)getSingleton()方法，判斷此時(shí)緩存中是否有想要獲取的Bean了，如果有了直接從緩存中獲取。如果沒有則在后面的第二個(gè)調(diào)用的getSingleton()方法中去創(chuàng)建該Bean

? ? Object sharedInstance = getSingleton(beanName);

? ? if (sharedInstance != null && args == null) {

? ? ? ? ...

? ? }

? ? else {

? ? ? ? // Fail if we're already creating this bean instance:

? ? ? ? // We're assumably within a circular reference.

?// 非單例bean是無法支持循環(huán)依賴的，所以這里判斷是否是非單例bean的循環(huán)依賴場景，如果是則拋出異常

? ? ? ? if (isPrototypeCurrentlyInCreation(beanName)) {

? ? ? ? ? ? throw new BeanCurrentlyInCreationException(beanName);

? ? ? ? }

? ? ? ? // Check if bean definition exists in this factory.

? ? ? ? BeanFactory parentBeanFactory = getParentBeanFactory();

? ? ? ? if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {

? ? ? ? ? ? ...

? ? ? ? }

? ? ? ? if (!typeCheckOnly) {

? ? ? ? ? ? markBeanAsCreated(beanName);

? ? ? ? }

? ? ? ? try {

? ? ? ? ? ? RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);

? ? ? ? ? ? checkMergedBeanDefinition(mbd, beanName, args);

? ? ? ? ? ? // Guarantee initialization of beans that the current bean depends on.

? ? ? ? ? ? String[] dependsOn = mbd.getDependsOn();

? ? ? ? ? ? if (dependsOn != null) {

? ? ? ? ? ? ? ? ...

? ? ? ? ? ? }

? ? ? ? ? ? // Create bean instance.

? ? ? ? ? ? if (mbd.isSingleton()) {

? ? ? ? ? ? ? ? // 2、第二個(gè)getSingleton()方法，當(dāng)從三個(gè)緩存中都沒有找到這個(gè)Bean的話，就會執(zhí)行第二個(gè)getSingleton()，在getSingleton()方法中會去調(diào)用createBean() 創(chuàng)建一個(gè) Bean 對象出來。

? ? ? ? ? ? ? ? sharedInstance = getSingleton(beanName, () -> {

? ? ? ? ? ? ? ? ? ? try {

??? // 在上面的getSingleton()方法中會調(diào)用到createBean()方法

? ? ? ? ? ? ? ? ? ? ? ? return createBean(beanName, mbd, args);

? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? ? ? catch (BeansException ex) {

? ? ? ? ? ? ? ? ? ? ? ? // Explicitly remove instance from singleton cache: It might have been put there

? ? ? ? ? ? ? ? ? ? ? ? // eagerly by the creation process, to allow for circular reference resolution.

? ? ? ? ? ? ? ? ? ? ? ? // Also remove any beans that received a temporary reference to the bean.

? ? ? ? ? ? ? ? ? ? ? ? destroySingleton(beanName);

? ? ? ? ? ? ? ? ? ? ? ? throw ex;

? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? });

? ? ? ? ? ? ? ? bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);

? ? ? ? ? ? }

? ? .....

? ?

? ? return (T) bean;

}

其中的第一個(gè)?getSingleton(beanName)?是判斷?三個(gè)緩存?中是否有創(chuàng)建好的 Bean 對象，下面看它的源碼。

4.1.1.1 調(diào)用getSingleton(beanName)：調(diào)用的第一個(gè)名為getSingleton的方法，嘗試從緩存中獲取Bean

首先調(diào)用getSingleton(a)方法，這個(gè)方法又會調(diào)用getSingleton(beanName, true)，在上圖中我省略了這一步。

DefaultSingletonBeanRegistry.java

public Object getSingleton(String beanName) {

? ? return getSingleton(beanName, true);

}

DefaultSingletonBeanRegistry.java

@Nullable

// allowEarlyReference表示是否允許提前引用，如果為true，那么在Bean創(chuàng)建過程中，就可以通過第三級緩存獲取到該Bean，否則只能在Bean創(chuàng)建完成后才能獲取到該Bean。這個(gè)參數(shù)的作用在后面會講到。

protected Object getSingleton(String beanName, boolean allowEarlyReference) {

? ? // Quick check for existing instance without full singleton lock

? ? // 嘗試從一級緩存singletonObjects中獲取該Bean

? ? Object singletonObject = this.singletonObjects.get(beanName);

? ? // 如果一級緩存中沒有該Bean，并且該Bean正在被創(chuàng)建（只要這個(gè)beanName在SingletonCurrentlyInCreation集合中，就表明這個(gè)Bean正在被創(chuàng)建）

? ? if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {

? ? ? ? // 如果一級緩存中沒有該Bean，并且該Bean正在被創(chuàng)建，那么嘗試從二級緩存earlySingletonObjects中獲取該Bean

? ? ? ? singletonObject = this.earlySingletonObjects.get(beanName);

? ? ? ? // 如果二級緩存中沒有該Bean，并且當(dāng)前允許Bean可以被提前引用（不用等Bean完全創(chuàng)建完成），那么嘗試從三級緩存singletonFactories中獲取該Bean

? ? ? ? if (singletonObject == null && allowEarlyReference) {

? ? ? ? ? ? synchronized (this.singletonObjects) {

? ? ? ? ? ? ? ? // Consistent creation of early reference within full singleton lock

? ? ? ? ? ? ? ? singletonObject = this.singletonObjects.get(beanName);

? ? ? ? ? ? ? ? if (singletonObject == null) {

? ? ? ? ? ? ? ? ? ? singletonObject = this.earlySingletonObjects.get(beanName);

? ? ? ? ? ? ? ? ? ? if (singletonObject == null) {

? ? ? ? ? ? ? ? ? ? ? ? // 從三級緩存singletonFactories中獲取該Bean的BeanFactory

? ? ? ? ? ? ? ? ? ? ? ? ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);

? ? ? ? ? ? ? ? ? ? ? ? if (singletonFactory != null) {

??????????????????????????????????????????????????? // 通過三級緩存中這個(gè)Bean的工廠類來獲取這個(gè)Bean的實(shí)例化對象（此時(shí)返回的只是完成實(shí)例化的Bean，并沒有完成屬性注入和初始化，所以并不是一個(gè)完整的Bean），具體的源碼細(xì)節(jié)會在后面創(chuàng)建B類的時(shí)候講解

? ? ? ? ? ? ? ? ? ? ? ? ? ? singletonObject = singletonFactory.getObject();

??????????????????????????? // 通過singletonFactory工廠類獲取到的bean添加到二級緩存中（如果這個(gè)Bean沒有AOP增強(qiáng)，那么加入到二級緩存的就是這個(gè)Bean原始的實(shí)例化對象；如果這個(gè)Bean有AOP增強(qiáng)，那么工廠類返回的就是這個(gè)Bean的代理對象，就會將代理對象添加到二級緩存中）

? ? ? ? ? ? ? ? ? ? ? ? ? ? this.earlySingletonObjects.put(beanName, singletonObject);

??????????????????????????????????????????????????? // 將三級緩存中這個(gè)Bean的工廠類移除

? ? ? ? ? ? ? ? ? ? ? ? ? ? this.singletonFactories.remove(beanName);

? ? ? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? }

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? return singletonObject;

}

getSingleton(beanName, true)這個(gè)方法實(shí)際上就是到緩存中嘗試去獲取Bean，整個(gè)緩存分為三級（這三個(gè)緩存其實(shí)就相當(dāng)于一個(gè)Map，key就是BeanName，value就是各自要存儲的對象）：

1. singletonObjects，一級緩存，存儲的是所有創(chuàng)建好了的單例Bean
2. earlySingletonObjects，完成實(shí)例化，但是還未進(jìn)行屬性注入及初始化的對象
3. singletonFactories，提前暴露的一個(gè)單例工廠，二級緩存中存儲的就是從這個(gè)工廠中獲取到的對象

通過上面的源碼可以看到這里分別去每一級的緩存中取數(shù)據(jù)，依次從第一級開始取數(shù)據(jù)，如果取得到則直接返回，取不到則往下一級查找，步驟如下：

1. Spring首先從一級緩存singletonObjects中獲取。
2. 如果獲取不到，并且對象正在創(chuàng)建中，就再從二級緩存earlySingletonObjects中獲取。
3. 如果還是獲取不到且允許singletonFactories通過getObject()獲取，就從三級緩存singletonFactory.getObject()(三級緩存)獲取。
4. 如果從三級緩存中獲取后，就將這個(gè)Bean放入earlySingletonObjects中，并將這個(gè)singletonFactory從singletonFactories中移除。其實(shí)也就是從三級緩存移動到了二級緩存。

通過源碼可以看到在第三級緩存中調(diào)用了 singletonFactories.get(beanName) 按照上文所說的會觸發(fā)執(zhí)行有 AOP 操作返回代理對象，沒有AOP操作就直接返回原始對象，并且在這里會判斷是否成功從三級緩存中取出了singletonFactory對象，如果成功獲取則通過singletonFactory獲取Bean，然后將這個(gè)半成品Bean添加到二級緩存中并刪除三級緩存中這個(gè)Bean的singletonFactory數(shù)據(jù)。

從三級緩存的分析來看，Spring解決循環(huán)依賴的訣竅就在于singletonFactories這個(gè)第三級cache。這個(gè)cache的類型是ObjectFactory，定義如下：

/**

?* 定義一個(gè)可以返回對象實(shí)例的工廠

?* @param <T>

?*/

public interface ObjectFactory<T> {

? ? T getObject() throws BeansException;

}

?

因?yàn)锳是第一次被創(chuàng)建，所以不管哪個(gè)緩存中必然都是沒有的，因此會進(jìn)入getSingleton的另外一個(gè)重載方法getSingleton(beanName, singletonFactory)。第二個(gè)?getSingleton()?其實(shí)就是去執(zhí)行傳入的singletonFactory的lambda表達(dá)式中的?createBean()?來創(chuàng)建一個(gè) Bean 對象出來。

4.1.1.2 調(diào)用getSingleton(beanName, singletonFactory)：調(diào)用的第二個(gè)名為getSingleton的方法，去創(chuàng)建Bean

這個(gè)方法傳入的ObjectFactory<?>實(shí)際是一個(gè)Lambdas表達(dá)式，所以調(diào)用傳入?yún)?shù)singletonFactory的getObject()?方法，就會調(diào)用到createBean()?方法來創(chuàng)建Bean，創(chuàng)建好的Bean會加入到一級緩存中。其源碼如下：

DefaultSingletonBeanRegistry.java

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) {

? ? ? ? ? ? // ....

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

? ? ? ? ? ? // ....

? ? ? ? ? ? // 在單例對象創(chuàng)建前先做一個(gè)標(biāo)記

? ? ? ? ? ? // 將beanName放入到singletonsCurrentlyInCreation這個(gè)集合中（這個(gè)集合相當(dāng)于一個(gè)Set集合）

? ? ? ? ? ? // 標(biāo)志著這個(gè)單例Bean正在創(chuàng)建

? ? ? ? ? ? // 如果同一個(gè)單例Bean多次被創(chuàng)建，這里會拋出異常

? ? ? ? ? ? // 加入到這個(gè)集合的BeanName就表示這個(gè)Bean正在被創(chuàng)建，這一個(gè)標(biāo)記很關(guān)鍵，后面還會用到

? ? ? ? ? ? beforeSingletonCreation(beanName);

? ? ? ? ? ? boolean newSingleton = false;

? ? ? ? ? ? boolean recordSuppressedExceptions = (this.suppressedExceptions == null);

? ? ? ? ? ? if (recordSuppressedExceptions) {

? ? ? ? ? ? ? ? this.suppressedExceptions = new LinkedHashSet<>();

? ? ? ? ? ? }

? ? ? ? ? ? try {

? ? ? ? ? ? ? ? // 上游傳入的lambda（也就是一個(gè)工廠類singletonFactory）在這里會被執(zhí)行，調(diào)用singletonFactory.getObject()方法會觸發(fā)執(zhí)行在lambda表達(dá)式中調(diào)用的createBean方法，去創(chuàng)建一個(gè)Bean后返回

? ? ? ? ? ? ? ? // 此時(shí)這個(gè)Bean相當(dāng)于通過createBean()方法被實(shí)例化出來了，實(shí)例化對象賦值給了singletonObject

?? // 這里得到的singletonObject就是初始化后得到的bean（或者代理bean）

? ? ? ? ? ? ? ? singletonObject = singletonFactory.getObject();

? ? ? ? ? ? ? ? newSingleton = true;

? ? ? ? ? ? }

? ? ? ? ? ? // ...

? ? ? ? ? ? // 省略catch異常處理

? ? ? ? ? ? // ...

? ? ? ? ? ? finally {

? ? ? ? ? ? ? ? if (recordSuppressedExceptions) {

? ? ? ? ? ? ? ? ? ? this.suppressedExceptions = null;

? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? // 創(chuàng)建完成后將對應(yīng)的beanName從singletonsCurrentlyInCreation移除（表示這個(gè)Bean已經(jīng)創(chuàng)建完成了，不再是創(chuàng)建中的狀態(tài)了）

? ? ? ? ? ? ? ? afterSingletonCreation(beanName);

? ? ? ? ? ? }

? ? ? ? ? ? if (newSingleton) {

? ? ? ? ? ? ? ? // 創(chuàng)建好的Bean，會添加到一級緩存singletonObjects中，同時(shí)將這個(gè)Bean從二級緩存和三級緩存中移除。

? ? ? ? ? ? ? ? addSingleton(beanName, singletonObject);

? ? ? ? ? ? }

? ? ? ? }

? ? ? ? // 返回創(chuàng)建好的Bean

? ? ? ? return singletonObject;

? ? }

}

?

// 將完全創(chuàng)建好的Bean添加到一級緩存中

protected void addSingleton(String beanName, Object singletonObject) {

? ? synchronized (this.singletonObjects) {

? ? ? ? // 將完全創(chuàng)建完成的Bean添加到一級緩存中

? ? ? ? this.singletonObjects.put(beanName, singletonObject);

? ? ? ? // 將Bean從三級緩存中移除

? ? ? ? this.singletonFactories.remove(beanName);

? ? ? ? // 將Bean從二級緩存中移除

? ? ? ? this.earlySingletonObjects.remove(beanName);

? ? ? ? // 將完成創(chuàng)建的Bean添加到已注冊的單例Bean集合中

? ? ? ? this.registeredSingletons.add(beanName);

? ? }

}

?

上面getSingleton()的代碼我們主要抓住一點(diǎn)，通過createBean方法返回的創(chuàng)建完成的Bean最終通過addSingleton()方法添加到了一級緩存，也就是單例池中。

那么到這里我們可以得出一個(gè)結(jié)論：一級緩存中存儲的是已經(jīng)完全創(chuàng)建好了的單例Bean。

?

4.1.1.2.1 createBean()方法：創(chuàng)建Bean

我們再展開講一下創(chuàng)建Bean的過程，創(chuàng)建Bean本質(zhì)是通過執(zhí)行?createBean()?方法中的?doCreateBean()?方法來創(chuàng)建的。源碼如下：

AbstractAutowireCapableBeanFactory.java

@Override

protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)

? ? ? ? throws BeanCreationException {

? ? if (logger.isTraceEnabled()) {

? ? ? ? logger.trace("Creating instance of bean '" + beanName + "'");

? ? }

// 拿到BeanDefinition(Bean定義)

? ? RootBeanDefinition mbdToUse = mbd;

?

? ? // Make sure bean class is actually resolved at this point, and

? ? // clone the bean definition in case of a dynamically resolved Class

? ? // which cannot be stored in the shared merged bean definition.

? ? Class<?> resolvedClass = resolveBeanClass(mbd, beanName);

? ? if (resolvedClass != null && !mbd.hasBeanClass() && mbd.getBeanClassName() != null) {

? ? ? ? mbdToUse = new RootBeanDefinition(mbd);

? ? ? ? mbdToUse.setBeanClass(resolvedClass);

? ? }

? ? // Prepare method overrides.

? ? try {

? ? ? ? mbdToUse.prepareMethodOverrides();

? ? }

? ? catch (BeanDefinitionValidationException ex) {

? ? ? ? throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),

? ? ? ? ? ? ? ? beanName, "Validation of method overrides failed", ex);

? ? }

? ? try {

? ? ? ? // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.

? ? ? ? Object bean = resolveBeforeInstantiation(beanName, mbdToUse);

? ? ? ? if (bean != null) {

? ? ? ? ? ? return bean;

? ? ? ? }

? ? }

? ? catch (Throwable ex) {

? ? ? ? throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,

? ? ? ? ? ? ? ? "BeanPostProcessor before instantiation of bean failed", ex);

? ? }

? ? try {

? ? ? ? // 通過調(diào)用doCreateBean()來創(chuàng)建完整的Bean

? ? ? ? Object beanInstance = doCreateBean(beanName, mbdToUse, args);

? ? ? ? if (logger.isTraceEnabled()) {

? ? ? ? ? ? logger.trace("Finished creating instance of bean '" + beanName + "'");

? ? ? ? }

? ? ? ? return beanInstance;

? ? }

? ? catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {

? ? ? ? // A previously detected exception with proper bean creation context already,

? ? ? ? // or illegal singleton state to be communicated up to DefaultSingletonBeanRegistry.

? ? ? ? throw ex;

? ? }

? ? catch (Throwable ex) {

? ? ? ? throw new BeanCreationException(

? ? ? ? ? ? ? ? mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);

? ? }

}

AbstractAutowireCapableBeanFactory.java

/**

?* 實(shí)際創(chuàng)建指定的bean的方法。 這個(gè)方法完成了 1、Bean的實(shí)例化 ? 2、Bean的屬性注入 ? 3、Bean的初始化

?* 此時(shí)，預(yù)創(chuàng)建處理已經(jīng)發(fā)生，

?* 例如 檢查{@code postProcessBeforeInstantiation}回調(diào)。

?* 區(qū)分默認(rèn)bean實(shí)例化、使用工廠方法和自動裝配構(gòu)造函數(shù)。

?*/

protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) {

? ? // Instantiate the bean.

? ? BeanWrapper instanceWrapper = null;

? ? .....

? ?

? ? if (instanceWrapper == null) {

? ? ? ? // 1、實(shí)例化Bean，生成的對象被稱為原始對象

? ? ? ? instanceWrapper = createBeanInstance(beanName, mbd, args);

? ? }

// 這里的bean就是A或者B的原始對象，此時(shí)沒有被屬性注入，也沒有執(zhí)行初始化邏輯

? ? Object bean = instanceWrapper.getWrappedInstance();

?

? ? .....

? ? // Eagerly cache singletons to be able to resolve circular references

? ? // even when triggered by lifecycle interfaces like BeanFactoryAware.

?????? // A是單例的，mbd.isSingleton()條件滿足

// allowCircularReferences：這個(gè)變量代表是否允許循環(huán)依賴，默認(rèn)是開啟的，條件也滿足

// isSingletonCurrentlyInCreation：正在在創(chuàng)建A，也滿足

// 所以earlySingletonExposure=true

? ? boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&

? ? ? ? ? ? isSingletonCurrentlyInCreation(beanName));

? ? if (earlySingletonExposure) {

? ? ? ? if (logger.isDebugEnabled()) {

? ? ? ? ? ? logger.debug("Eagerly caching bean '" + beanName +

? ? ? ? ? ? ? ? ? ? "' to allow for resolving potential circular references");

? ? ? ? }

? ? ? ? // 將創(chuàng)建的BeanFactory添加到三級緩存中。注意此時(shí)Bean并沒有徹底創(chuàng)建完成，此時(shí)只進(jìn)行了實(shí)例化，Bean還是一個(gè)半成品

? ? ? ? addSingletonFactory(beanName, new ObjectFactory<Object>() {

?// ObjectFactory的getObejct()方法實(shí)際就會調(diào)用到getEarlyBeanReference()方法

? ? ? ? // 如果需要?jiǎng)討B(tài)代理，getEarlyBeanReference()方法會返回原始對象的代理對象

? ? ? ? // 如果不需要?jiǎng)討B(tài)代理，getEarlyBeanReference()方法會返回原始對象

? ? ? ? ? ? @Override

? ? ? ? ? ? public Object getObject() throws BeansException {

? ? ? ? ? ? ? ? return getEarlyBeanReference(beanName, mbd, bean);

? ? ? ? ? ? }

? ? ? ? });

? ? }

? ? // Initialize the bean instance.

? ? Object exposedObject = bean;

? ? try {

? ? ? ? // 2、Bean的屬性注入

? ? ? ? populateBean(beanName, mbd, instanceWrapper);

? ? ? ? if (exposedObject != null) {

? ? ? ? ? ? // 3、Bean的初始化

? ? ? ? ? ? exposedObject = initializeBean(beanName, exposedObject, mbd);

? ? ? ? }

? ? }

? ? ......

?

?// 返回創(chuàng)建完成的Bean

? ? return exposedObject;

}

注：createBeanInstance(...)該步驟會調(diào)用構(gòu)造方法，來實(shí)例化Bean

AbstractAutowireCapableBeanFactory.java

/**

?* 使用適當(dāng)?shù)膶?shí)例化策略為指定的bean創(chuàng)建一個(gè)新實(shí)例：

?* 工廠方法，構(gòu)造函數(shù)自動裝配或簡單實(shí)例化。

?* @return BeanWrapper for the new instance

?*/

protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, Object[] args) {

? ?

? ? .......

? ? // Need to determine the constructor...(確定構(gòu)造函數(shù))

? ? 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.(使用默認(rèn)無參構(gòu)造器,

? ? // 編程時(shí)候要求盡量保留無參構(gòu)造器,因?yàn)槟悴恢滥膫€(gè)框架在哪會用到)

? ? return instantiateBean(beanName, mbd);

}

至于其他的屬性注入populateBean()和初始化initializeBean()的源碼分析，在之前的IOC筆記中已經(jīng)講過了，這里就不再贅述了。

在populateBean()屬性注入這一步里，進(jìn)入到給A注入B的流程。

4.1.1.2.1.1 調(diào)用addSingletonFactory方法：這個(gè)方法就是解決循環(huán)依賴問題的關(guān)鍵

調(diào)用位置如下圖所示：

AbstractAutowireCapableBeanFactory..doCreateBean()

在完成Bean的實(shí)例化后，屬性注入之前Spring將Bean包裝成一個(gè)工廠添加進(jìn)了三級緩存中，對應(yīng)源碼如下：

DefaultSingletonBeanRegistry.java

/**

?* ?添加一個(gè)構(gòu)建指定單例對象的單例工廠

?* ?緊急注冊單例對象，用于解決解決循環(huán)依賴問題

?* To be called for eager registration of singletons, e.g. to be able to

?* resolve circular references.

?*/

// 這里傳入的參數(shù)也是一個(gè)lambda表達(dá)式，() -> getEarlyBeanReference(beanName, mbd, bean)

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {

? ? Assert.notNull(singletonFactory, "Singleton factory must not be null");

? ? synchronized (this.singletonObjects) {

? ? ? ? // 如果在一級緩存中不存在這個(gè)Bean，那么就添加到三級緩存中

? ? ? ? if (!this.singletonObjects.containsKey(beanName)) {

? ? ? ? ? ? // 添加到三級緩存中

? ? ? ? ? ? this.singletonFactories.put(beanName, singletonFactory);

? ? ? ? ? ? // 從二級緩存中移除

? ? ? ? ? ? this.earlySingletonObjects.remove(beanName);

? ? ? ? ? ? this.registeredSingletons.add(beanName);

? ? ? ? }

? ? }

}

?

通過這個(gè)代碼的注釋我們就能知道，第三級緩存就是堅(jiān)決循環(huán)依賴問題的關(guān)鍵，而這個(gè)方法也是解決循環(huán)依賴的關(guān)鍵所在，這段代碼發(fā)生在doCreateBean(...) 方法中 createBeanInstance之后，也就是說單例對象此時(shí)已經(jīng)被實(shí)例化出來了(調(diào)用了構(gòu)造器)。這個(gè)對象已經(jīng)被生產(chǎn)出來了，雖然還不完美（還沒有進(jìn)行創(chuàng)建Bean的第二步和第三步），但是已經(jīng)能被人認(rèn)出來了（根據(jù)對象引用能定位到堆中的對象），所以Spring此時(shí)將這個(gè)對象提前曝光出來讓大家認(rèn)識，讓大家使用。

這樣做有什么好處呢？讓我們來分析一下“A的某個(gè)field或者setter依賴了B的實(shí)例對象，同時(shí)B的某個(gè)field或者setter依賴了A的實(shí)例對象”這種循環(huán)依賴的情況。A首先完成了創(chuàng)建的第一步（完成實(shí)例化），并且將自己提前曝光到singletonFactories中，此時(shí)進(jìn)行創(chuàng)建的第二步（屬性注入），發(fā)現(xiàn)自己依賴對象B，此時(shí)就嘗試去get(B)，發(fā)現(xiàn)B還沒有被create，所以走create(B)的流程，B在創(chuàng)建第一步的時(shí)候發(fā)現(xiàn)自己依賴了對象A，于是嘗試get(A)，嘗試一級緩存singletonObjects(肯定沒有，因?yàn)锳還沒初始化完全)，嘗試二級緩存earlySingletonObjects（也沒有），嘗試三級緩存singletonFactories，由于A通過ObjectFactory將自己提前曝光了，所以B能夠通過ObjectFactory.getObject拿到A對象(雖然A還沒有初始化完全，但是總比沒有好呀)，B拿到A對象后順利完成了創(chuàng)建的階段1、2、3，B完成創(chuàng)建后之后將自己放入到一級緩存singletonObjects中。此時(shí)返回A的創(chuàng)建流程中，A此時(shí)能拿到B的對象順利完成自己的創(chuàng)建階段2、3，最終A也完成了創(chuàng)建，將創(chuàng)建好的A添加到一級緩存singletonObjects中，而且更加幸運(yùn)的是，由于B拿到了A的對象引用，所以B現(xiàn)在持有的A對象也完成了創(chuàng)建。（簡單來說，就是spring創(chuàng)造了一個(gè)循環(huán)依賴的結(jié)束點(diǎn)標(biāo)識）

?

?

再回到這個(gè)方法源碼本身，這個(gè)方法只是添加了一個(gè)工廠，在創(chuàng)建A的流程中執(zhí)行到這個(gè)方法時(shí)，A只是完成了實(shí)例化，還沒有完成屬性注入和初始化。上面的文字也講了B通過這個(gè)工廠（ObjectFactory）的getObject方法可以得到A對象，而這個(gè)A對象實(shí)際上就是通過getObject方法中再去調(diào)用getEarlyBeanReference這個(gè)方法創(chuàng)獲取的。既然singletonFactory.getObject()方法是在創(chuàng)建B的流程中調(diào)用的，下面我們就再進(jìn)入到創(chuàng)建B的流程中進(jìn)行講解。

4.1.2 創(chuàng)建B

當(dāng)A完成了實(shí)例化并添加進(jìn)了三級緩存后，就要通過方法populateBean()開始為A進(jìn)行屬性注入了，在注入時(shí)發(fā)現(xiàn)A依賴了B，那么這個(gè)時(shí)候Spring又會去getBean(b)，然后反射調(diào)用setter方法完成屬性注入。

流程圖如下：

4.1.2.1 調(diào)用第一個(gè)getSingleton()方法實(shí)現(xiàn)對B注入A

因?yàn)锽需要注入A，所以在創(chuàng)建B的時(shí)候，又會去調(diào)用getBean(a)，這個(gè)時(shí)候就又回到之前的流程了，但是不同的是，之前的getBean是為了創(chuàng)建Bean，而此時(shí)再調(diào)用getBean不是為了創(chuàng)建了，而是要從緩存中獲取，因?yàn)橹癆在實(shí)例化后已經(jīng)將其放入了三級緩存singletonFactories中，所以此時(shí)getBean(a)的流程就是這樣子了：

上面執(zhí)行的就是其實(shí)就是第一個(gè)getSingleton()方法，因?yàn)锳此時(shí)并不在一級和二級緩存中，而是在三級緩存中，所以最終會從三級緩存中獲取A，來將A注入給B。

@Nullable

// allowEarlyReference表示是否允許提前引用，如果為true，那么在Bean創(chuàng)建過程中，就可以通過getBean()方法獲取到該Bean，否則只能在Bean創(chuàng)建完成后才能獲取到該Bean

protected Object getSingleton(String beanName, boolean allowEarlyReference) {

? ? // Quick check for existing instance without full singleton lock

? ? // 嘗試從一級緩存singletonObjects中獲取該Bean

? ? Object singletonObject = this.singletonObjects.get(beanName);

? ? // 如果一級緩存中沒有該Bean，并且該Bean正在被創(chuàng)建（只要這個(gè)beanName在SingletonCurrentlyInCreation集合中，就表明這個(gè)Bean正在被創(chuàng)建）

? ? if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {

? ? ? ? // 如果一級緩存中沒有該Bean，并且該Bean正在被創(chuàng)建，那么嘗試從二級緩存earlySingletonObjects中獲取該Bean

? ? ? ? singletonObject = this.earlySingletonObjects.get(beanName);

? ? ? ? // 如果二級緩存中沒有該Bean，并且當(dāng)前允許Bean可以被提前引用（不用等Bean完全創(chuàng)建完成），那么嘗試從三級緩存singletonFactories中獲取該Bean

? ? ? ? if (singletonObject == null && allowEarlyReference) {

? ? ? ? ? ? synchronized (this.singletonObjects) {

? ? ? ? ? ? ? ? // Consistent creation of early reference within full singleton lock

? ? ? ? ? ? ? ? singletonObject = this.singletonObjects.get(beanName);

? ? ? ? ? ? ? ? if (singletonObject == null) {

? ? ? ? ? ? ? ? ? ? singletonObject = this.earlySingletonObjects.get(beanName);

? ? ? ? ? ? ? ? ? ? if (singletonObject == null) {

? ? ? ? ? ? ? ? ? ? ? ? // 從三級緩存singletonFactories中獲取該Bean的BeanFactory

? ? ? ? ? ? ? ? ? ? ? ? ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);

? ? ? ? ? ? ? ? ? ? ? ? if (singletonFactory != null) {

? ? ? ? ? ? ? ? ? ? ? ? ? ? // 調(diào)用工廠的getObject方法，其實(shí)本質(zhì)調(diào)用的就是從上游lambda表達(dá)式傳入的getEarlyBeanReference()方法

? ? ? ? ? ? ? ? ? ? ? ? ? ? singletonObject = singletonFactory.getObject();

????????????????????????????????????????????????? // 通過singletonFactory工廠類獲取到的bean添加到二級緩存中（如果這個(gè)Bean沒有AOP增強(qiáng)，那么加入到二級緩存的就是這個(gè)Bean原始的實(shí)例化對象；如果這個(gè)Bean有AOP增強(qiáng)，那么工廠類返回的就是這個(gè)Bean的代理對象，就會將代理對象添加到二級緩存中）

? ? ? ? ? ? ? ? ? ? ? ? ? ? this.earlySingletonObjects.put(beanName, singletonObject);

??????????????????????????????????????????????????? // 將三級緩存中這個(gè)Bean的工廠類移除

? ? ? ? ? ? ? ? ? ? ? ? ? ? this.singletonFactories.remove(beanName);

? ? ? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? ? ? }

? ? ? ? ? ? ? ? }

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? return singletonObject;

}

4.1.2.1.1 調(diào)用getEarlyBeanReference()方法：用來從singletonFactory工廠類中返回Bean

從上面的源碼我們可以看出，注入到B中的A是通過getEarlyBeanReference方法提前暴露出去的一個(gè)對象，還不是一個(gè)完整的Bean，那么getEarlyBeanReference到底干了啥了，我們看下它的源碼：

// 這個(gè)方法名字其實(shí)就告訴了我們它的作用了，得到一個(gè)比較早的Bean引用（還沒有完全創(chuàng)建好的Bean，僅僅只是完成了實(shí)例化的Bean，還沒有完成屬性注入和初始化）

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {

? ? Object exposedObject = bean;

? ? // AOP增強(qiáng)操作

? ? if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {

? ? ? ? for (BeanPostProcessor bp : getBeanPostProcessors()) {

? ? ? ? ? ? if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {

? ? ? ? ? ? ? ? SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;

? ? ? ? ? ? ? ? exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? return exposedObject;

}

?

它實(shí)際上就是調(diào)用了后置處理器的getEarlyBeanReference，而真正實(shí)現(xiàn)了這個(gè)方法的后置處理器只有一個(gè)，就是通過@EnableAspectJAutoProxy注解導(dǎo)入的AnnotationAwareAspectJAutoProxyCreator。也就是說如果在不考慮AOP的情況下，上面的代碼等價(jià)于：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {

? ? Object exposedObject = bean;

? ? // 相當(dāng)于直接返回了原始Bean，并沒有進(jìn)行AOP增強(qiáng)

? ? return exposedObject;

}

也就是說這個(gè)工廠啥都沒干，直接將之前實(shí)例化階段創(chuàng)建的對象A返回了！所以說在不考慮AOP的情況下三級緩存有用嘛？講道理，真的沒什么用，我直接將這個(gè)對象放到二級緩存中不是一點(diǎn)問題都沒有嗎？所以三級緩存并沒有提高任何效率。

那么三級緩存到底有什么作用呢？不要急，我們先把整個(gè)流程走完，在下文結(jié)合AOP分析循環(huán)依賴的時(shí)候你就能體會到三級緩存的作用！

4.1.3 創(chuàng)建A和B的流程總結(jié)

到這里不知道小伙伴們會不會有疑問，B中提前注入了一個(gè)沒有經(jīng)過初始化的A類型對象不會有問題嗎？

答：不會，因?yàn)槠鋵?shí)B中注入了A的引用，在后面A徹底完成創(chuàng)建之后，A的引用并不會變，所以B最終會得到一個(gè)完整的A。

這個(gè)時(shí)候我們將整個(gè)創(chuàng)建A這個(gè)Bean的流程總結(jié)一下，如下圖：

從上圖中我們可以看到，雖然在創(chuàng)建B時(shí)會提前給B注入了一個(gè)還未初始化的A對象，但是在創(chuàng)建A的流程中一直使用的是注入到B中的A對象的引用，之后會根據(jù)這個(gè)引用對A進(jìn)行初始化，所以這是沒有問題的。

4.2 結(jié)合了AOP的循環(huán)依賴

之前我們已經(jīng)說過了，在普通的循環(huán)依賴的情況下，三級緩存沒有任何作用。三級緩存實(shí)際上跟Spring中的AOP相關(guān)，我們再來看一看getEarlyBeanReference的代碼：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {

? ? Object exposedObject = bean;

? ? // 如果不是合成的bean，且有實(shí)例化后置處理器，就說明這個(gè)Bean有AOP代理增強(qiáng)操作，需要提前暴露出來

? ? if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {

? ? ? ? // 進(jìn)到這個(gè)if分支，說明開啟了AOP功能，且當(dāng)前Bean有實(shí)例化后置處理器

? ? ? ? // 遍歷當(dāng)前Bean的所有實(shí)例化后置處理器

? ? ? ? for (BeanPostProcessor bp : getBeanPostProcessors()) {

? ? ? ? ? ? // 如果當(dāng)前實(shí)例化后置處理器是SmartInstantiationAwareBeanPostProcessor類型的，則調(diào)用getEarlyBeanReference方法獲取代理增強(qiáng)后的Bean

? ? ? ? ? ? if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {

? ? ? ? ? ? ? ? SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;

? ? ? ? ? ? ? ? // 調(diào)用SmartInstantiationAwareBeanPostProcessor的getEarlyBeanReference方法，獲取代理增強(qiáng)后的Bean。調(diào)用的AnnotationAwareAspectJAutoProxyCreator的getEarlyBeanReference方法

? ? ? ? ? ? ? ? exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);

? ? ? ? ? ? }

? ? ? ? }

? ? }

? ? return exposedObject;

}

如果在開啟AOP的情況下，那么就是調(diào)用到AnnotationAwareAspectJAutoProxyCreator（SmartInstantiationAwareBeanPostProcessor 的實(shí)現(xiàn)類）的getEarlyBeanReference方法，對應(yīng)的源碼如下：

public Object getEarlyBeanReference(Object bean, String beanName) {

? ? Object cacheKey = getCacheKey(bean.getClass(), beanName);

? ? // earlyProxyReferences 存儲的是 (beanName, bean) 鍵值對，這里的 bean 指的是原始對象（剛實(shí)例化后的對象）

? ? this.earlyProxyReferences.put(cacheKey, bean);

? ? // wrapIfNecessary() 方法用于執(zhí)行 AOP 操作，生成一個(gè)代理對象（也就是說如果有 AOP 操作最后返回的是代理對象，否則返回的還是原始對象）。

? ? return wrapIfNecessary(bean, beanName, cacheKey);

}

回到上面的例子，我們對A進(jìn)行了AOP代理的話，那么此時(shí)getEarlyBeanReference將返回一個(gè)代理后的對象，而不是實(shí)例化階段創(chuàng)建的對象，這樣就意味著B中注入的A將是一個(gè)代理對象而不是A的實(shí)例化階段創(chuàng)建后的對象。

看到這個(gè)圖你可能會產(chǎn)生下面這些疑問：

1、在給B注入的時(shí)候?yàn)槭裁匆⑷胍粋€(gè)代理對象？

答：當(dāng)我們對A進(jìn)行了AOP代理時(shí)，說明我們希望從容器中獲取到的就是A代理后的對象而不是A本身，因此把A當(dāng)作依賴進(jìn)行注入時(shí)也要注入它的代理對象。

2、明明在創(chuàng)建A的時(shí)候，到初始化這一步完成的時(shí)候仍然還是原始的A對象，那么如果對A有AOP增強(qiáng)的話，為什么最終在Spring容器中取出的A是代理增強(qiáng)的對象呢？Spring是在什么時(shí)候?qū)⒋韺ο蠓湃氲饺萜髦械哪兀?/strong>