第Spring源碼解析之循環依賴的實現流程目錄前言循環依賴實現流程

前言

上篇文章中我們分析完了Spring中Bean的實例化過程，但是沒有對循環依賴的問題進行分析，這篇文章中我們來看一下spring是如何解決循環依賴的實現。

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

privatefinalMapString,ObjectsingletonObjects=newConcurrentHashMapString,Object(256);

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

/**Cacheofsingletonobjects:beanname--beaninstance*/

privatefinalMapString,ObjectsingletonObjects=newConcurrentHashMapString,Object(256);

/**Cacheofearlysingletonobjects:beanname--beaninstance*/

privatefinalMapString,ObjectearlySingletonObjects=newHashMapString,Object(16);

/**Cacheofsingletonfactories:beanname--ObjectFactory*/

privatefinalMapString,ObjectFactorysingletonFactories=newHashMapString,ObjectFactory(16);

從上到下分別為一到三級緩存，這里先對三級緩存有一個初步的認識，后面使用到的時候我們再詳細分析。

循環依賴實現流程

下面開始分析spring循環依賴的注入實現過程。先寫兩個bean，在它們中分別注入了對方：

@Component

publicclassServiceA{

@Autowired

ServiceBserviceB;

publicServiceBgetServiceB(){

System.out.println("getServiceB");

returnserviceB;

}

@Component

publicclassServiceB{

@Autowired

ServiceAserviceA;

publicServiceAgetServiceA(){

returnserviceA;

}

進行測試，分別調用它們的get方法，能夠正常獲得bean，說明循環依賴是可以實現的：

com.hydra.service.ServiceB@58fdd99

com.hydra.service.ServiceA@6b1274d2

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

在AbstractAutowireCapableBeanFactory的doCreateBean方法中，調用createBeanInstance方法創建一個原生對象，之后調用populateBean方法執行屬性的填充，最后調用各種回調方法和后置處理器。

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

上面的代碼先進行判斷：如果當前創建的是單例bean，并且允許循環依賴，并且處于創建過程中，那么執行下面的addSingletonFactory方法。

主要工作為將lambda表達式代表的ObjectFactory，放入三級緩存的Map中。注意這里只是一個存放的操作，并沒有實際執行lambda表達式中的內容，具體調用過程是在后面調用ObjectFactory的getObject方法時調用。這個方法執行完成后，三級緩存中存放了一條serviceA的數據，二級緩存仍然為空。

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

在這一過程中，serviceA會找到它依賴的serviceB這一屬性，當發現依賴后，會調用DefaultListableBeanFactory的doResolveDependency方法，之后執行resolveCandidate方法，在該方法中，嘗試使用beanFactory獲取到serviceB的bean實例。

publicObjectresolveCandidate(StringbeanName,ClassrequiredType,BeanFactorybeanFactory)

throwsBeansException{

returnbeanFactory.getBean(beanName);

這時和之前沒有循環依賴時的情況就會有些不一樣了，因為現在serviceB還沒有被創建出來，所以通過beanFactory是無法直接獲取的。因此當在doGetBean方法中調用getSingleton方法會返回一個null值：

因此，繼續使用與之前相同的創建bean的流程，實例化serviceB的bean對象。當serviceB的原生對象被實例化完成后，同樣可以看到它依賴的serviceA還沒有被賦值：

創建完serviceB的原生對象后，同樣執行addSingletonFactory方法，將serviceB放入三級緩存中，執行完成后，三級緩存中就已經存在了兩個bean的緩存：

向下執行，serviceB會調用populateBean方法進行屬性填充。和之前serviceA依賴serviceB相同的調用鏈，執行到resolveCandidate方法，嘗試使用beanFactory的getBean去獲取serviceA。

向下執行，調用getSingleton方法嘗試直接獲取serviceA，此時三級緩存singletonFactories中我們之前已經存進去了一個key為serviceA的beanName，value為lambda表達式，這時可以直接獲取到。

在執行singletonFactory的getObject方法時才去真正執行lambda表達式中的方法，實際執行的是getEarlyBeanReference方法：

在遍歷后置處理器后，獲取到serviceA的執行過后置處理器后的對象，執行：

this.earlySingletonObjects.put(beanName,singletonObject);

this.singletonFactories.remove(beanName);

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

當我們從緩存中獲取了serviceA的bean后，就不會再調用createBean去重復創建新的bean了。之后，順調用鏈返回serviceB調用的doResolveDependency方法：

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

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

現在我們梳理一下運行到這里的流程：

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

2、serviceB不存在，執行了一遍serviceB的創建流程，填充屬性時發現serviceA已經存在于三級緩存，直接注入給serviceB

可以看到，在創建serviceA的過程中發現依賴的serviceB不存在，轉而去創建了serviceB，而創建serviceA的流程并沒有執行完，因此在創建完serviceB后再順調用鏈返回，直到doResolveDependency方法：

可以看到，需要依賴的serviceB已經被創建并返回成功，返回到in