前言

上篇文章中我們分析完了Spring中Bean的實(shí)例化過程，但是沒有對(duì)循環(huán)依賴的問題進(jìn)行分析，這篇文章中我們來看一下spring是如何解決循環(huán)依賴的實(shí)現(xiàn)。

之前在講spring的過程中，我們提到了一個(gè)spring的單例池singletonObjects，用于存放創(chuàng)建好的bean，也提到過這個(gè)Map也可以說是狹義上的spring容器。

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

其實(shí)spring在緩存bean的過程中并不是只有這一個(gè)Map，我們看一下DefaultSingletonBeanRegistry這個(gè)類，在其中其實(shí)存在3個(gè)Map，這也就是經(jīng)常提到的spring三級(jí)緩存。

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);
/** Cache of early singleton objects: bean name --> bean instance */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);
/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);

從上到下分別為一到三級(jí)緩存，這里先對(duì)三級(jí)緩存有一個(gè)初步的認(rèn)識(shí)，后面使用到的時(shí)候我們?cè)僭敿?xì)分析。

循環(huán)依賴實(shí)現(xiàn)流程

下面開始分析spring循環(huán)依賴的注入實(shí)現(xiàn)過程。先寫兩個(gè)bean，在它們中分別注入了對(duì)方：

@Component
public class ServiceA {
  @Autowired
  ServiceB serviceB;  
  
  public ServiceB getServiceB() {
    System.out.println("get ServiceB");
    return serviceB;
  }
}

@Component
public class ServiceB {
  @Autowired
  ServiceA serviceA;  
  
  public ServiceA getServiceA() {
    return serviceA;
  }
}

進(jìn)行測(cè)試，分別調(diào)用它們的get方法，能夠正常獲得bean，說明循環(huán)依賴是可以實(shí)現(xiàn)的：

com.hydra.service.ServiceB@58fdd99
com.hydra.service.ServiceA@6b1274d2

首先，回顧一下上篇文章中講過的bean實(shí)例化的流程。下面的內(nèi)容較多依賴于spring的bean實(shí)例化源碼，如果不熟悉建議花點(diǎn)時(shí)間閱讀一下上篇文章。

在AbstractAutowireCapableBeanFactory的doCreateBean方法中，調(diào)用createBeanInstance方法創(chuàng)建一個(gè)原生對(duì)象，之后調(diào)用populateBean方法執(zhí)行屬性的填充，最后調(diào)用各種回調(diào)方法和后置處理器。

但是在執(zhí)行populateBean方法前，上篇文章中省略了一些涉及到循環(huán)依賴的內(nèi)容，看一下下面這段代碼：

上面的代碼先進(jìn)行判斷：如果當(dāng)前創(chuàng)建的是單例bean，并且允許循環(huán)依賴，并且處于創(chuàng)建過程中，那么執(zhí)行下面的addSingletonFactory方法。

主要工作為將lambda表達(dá)式代表的ObjectFactory，放入三級(jí)緩存的Map中。注意這里只是一個(gè)存放的操作，并沒有實(shí)際執(zhí)行l(wèi)ambda表達(dá)式中的內(nèi)容，具體調(diào)用過程是在后面調(diào)用ObjectFactory的getObject方法時(shí)調(diào)用。這個(gè)方法執(zhí)行完成后，三級(jí)緩存中存放了一條serviceA的數(shù)據(jù)，二級(jí)緩存仍然為空。

回到正常調(diào)用流程，生成原生對(duì)象后，調(diào)用populateBean方法進(jìn)行屬性的賦值也就是依賴注入，具體是通過執(zhí)行AutowiredAnnotationBeanPostProcessor這一后置處理器的postProcessPropertyValues方法。

在這一過程中，serviceA會(huì)找到它依賴的serviceB這一屬性，當(dāng)發(fā)現(xiàn)依賴后，會(huì)調(diào)用DefaultListableBeanFactory的doResolveDependency方法，之后執(zhí)行resolveCandidate方法，在該方法中，嘗試使用beanFactory獲取到serviceB的bean實(shí)例。

public Object resolveCandidate(String beanName, Class<?> requiredType, BeanFactory beanFactory)
      throws BeansException {
    return beanFactory.getBean(beanName);
  }

這時(shí)和之前沒有循環(huán)依賴時(shí)的情況就會(huì)有些不一樣了，因?yàn)楝F(xiàn)在serviceB還沒有被創(chuàng)建出來，所以通過beanFactory是無法直接獲取的。因此當(dāng)在doGetBean方法中調(diào)用getSingleton方法會(huì)返回一個(gè)null值：

因此，繼續(xù)使用與之前相同的創(chuàng)建bean的流程，實(shí)例化serviceB的bean對(duì)象。當(dāng)serviceB的原生對(duì)象被實(shí)例化完成后，同樣可以看到它依賴的serviceA還沒有被賦值：

創(chuàng)建完serviceB的原生對(duì)象后，同樣執(zhí)行addSingletonFactory方法，將serviceB放入三級(jí)緩存中，執(zhí)行完成后，三級(jí)緩存中就已經(jīng)存在了兩個(gè)bean的緩存：

向下執(zhí)行，serviceB會(huì)調(diào)用populateBean方法進(jìn)行屬性填充。和之前serviceA依賴serviceB相同的調(diào)用鏈，執(zhí)行到resolveCandidate方法，嘗試使用beanFactory的getBean去獲取serviceA。

向下執(zhí)行，調(diào)用getSingleton方法嘗試直接獲取serviceA，此時(shí)三級(jí)緩存singletonFactories中我們之前已經(jīng)存進(jìn)去了一個(gè)key為serviceA的beanName，value為lambda表達(dá)式，這時(shí)可以直接獲取到。

在執(zhí)行singletonFactory的getObject方法時(shí)才去真正執(zhí)行l(wèi)ambda表達(dá)式中的方法，實(shí)際執(zhí)行的是getEarlyBeanReference方法：

在遍歷后置處理器后，獲取到serviceA的執(zhí)行過后置處理器后的對(duì)象，執(zhí)行：

this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);

這里將serviceA放入二級(jí)緩存earlySingletonObjects，并從三級(jí)緩存singletonFactories中移除。在這一步執(zhí)行完后，三級(jí)緩存中的serviceA就沒有了。

當(dāng)我們從緩存中獲取了serviceA的bean后，就不會(huì)再調(diào)用createBean去重復(fù)創(chuàng)建新的bean了。之后，順調(diào)用鏈返回serviceB調(diào)用的doResolveDependency方法：

serviceB就成功獲取到了它的依賴的serviceA屬性的bean對(duì)象，回到inject方法，使用反射給serviceA賦值成功。

回到doCreateBean的方法，可以看到serviceB的serviceA屬性已經(jīng)被注入了，但是serviceA中的serviceB屬性還是null。說明serviceB的依賴注入已經(jīng)完成，而serviceA的依賴注入還沒做完。

現(xiàn)在我們梳理一下運(yùn)行到這里的流程：

1、在serviceA填充屬性過程中發(fā)現(xiàn)依賴了serviceB，通過beanFactory的getBean方法，嘗試獲取serviceB

2、serviceB不存在，執(zhí)行了一遍serviceB的創(chuàng)建流程，填充屬性時(shí)發(fā)現(xiàn)serviceA已經(jīng)存在于三級(jí)緩存，直接注入給serviceB

可以看到，在創(chuàng)建serviceA的過程中發(fā)現(xiàn)依賴的serviceB不存在，轉(zhuǎn)而去創(chuàng)建了serviceB，而創(chuàng)建serviceA的流程并沒有執(zhí)行完，因此在創(chuàng)建完serviceB后再順調(diào)用鏈返回，直到doResolveDependency方法：

可以看到，需要依賴的serviceB已經(jīng)被創(chuàng)建并返回成功，返回到inject方法，同樣通過反射給serviceB賦值：

返回doCreateBean方法，可以看到serviceA和serviceB之間的循環(huán)依賴已經(jīng)完成了：

這樣，一個(gè)最簡(jiǎn)單的循環(huán)依賴流程就結(jié)束了。有的小伙伴可能會(huì)提出疑問，這樣的話，我只需要添加一個(gè)緩存存放原生對(duì)象就夠了啊，為什么還需要二級(jí)緩存和三級(jí)緩存兩層結(jié)構(gòu)呢？這個(gè)問題，我們放在下一篇具體討論，看看循環(huán)依賴的具體實(shí)現(xiàn)時(shí)怎樣的。

到此這篇關(guān)于Spring源碼解析之循環(huán)依賴的實(shí)現(xiàn)流程的文章就介紹到這了,更多相關(guān)Spring循環(huán)依賴內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論