所謂循環依賴就是多個Bean之間依賴關系形成一個閉環，例如A->B->C->...->A 這種情況，當然，最簡單的循環依賴就是2個Bean之間互相依賴：A->B（A依賴B), B->A(B依賴A) 。在Spring中，如果A->B,那么在創建A的過程中會去創建B,在創建B（或B的依賴)的過程中又發現B->A，這個時候就出現了循環依賴的現象。
循環依賴的解決
spring中的循環依賴只有當
1.Bean是單例，
2.通過屬性注入的情況
這兩個條件滿足的情況下是沒問題的。但是如果是通過構造器依賴，或者不是單例模式的情況下循環依賴就會拋出異常BeanCurrentlyInCreationException。下面從代碼層面上解析一下為什么。
Prototype的循環依賴問題
為什么最先介紹Prototype的循環依賴呢，因為可以順便介紹在Spring中創建Bean的流程核心流程：在AbstractFoctory的doGetBean的方法。這個方法很長，這里只寫出核心邏輯，并在注解上注明了個人理解：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
|
protected <T> T doGetBean( final String name, final Class<T> requiredType, final Object[] args, boolean typeCheckOnly) throws BeansException { final String beanName = transformedBeanName(name); Object bean; //嘗試獲取單例對象，因為spring大部分的bean都是單例的，所以這里先嘗試能否獲取。 registered singletons. Object sharedInstance = getSingleton(beanName); //單例存在的情況下，那么beanName返回的肯定是單例類，但是這里還需要判斷是不是FactoryBean if (sharedInstance != null && args == null) { ... //FactoryBean應該返回getObject()對象 bean = getObjectForBeanInstance(sharedInstance, name, beanName, null); } else { //走到這里，有可能beanName是單例模式，但之前并沒有實例化，或者是Prototype類型。 //首先判斷不是循環依賴，這里的循環依賴指的是Prototype類型 if (isPrototypeCurrentlyInCreation(beanName)) { throw new BeanCurrentlyInCreationException(beanName); } try { final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName); // 如果是單例，則創建單例模式 if (mbd.isSingleton()) { // !!!這里是解決單例循環依賴的關鍵，后面再分析 sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() { @Override public Object getObject() throws BeansException { try { return createBean(beanName, mbd, args); } catch (BeansException ex) { throw ex; } } }); bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd); } else if (mbd.isPrototype()) { // 原型模式，則創建一個新對象. Object prototypeInstance = null; try { /*這里是Prototype循環依賴的問題，會記錄在map中beanName， 如果在解決當前Bean的依賴過程中還依賴當前Bean， 則說明了出現了循環依賴 */ beforePrototypeCreation(beanName); prototypeInstance = createBean(beanName, mbd, args); } finally { //對應beforePrototypeCreation()，從map中移除 afterPrototypeCreation(beanName); } bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd); } ... } } ... return (T) bean;} |
可以看出，該流程中就考慮了Prototype的循環依賴的問題，只要在創建Prototype的Bean中出現循環依賴那么就拋出異常。但是在singleton的情況下，則通過另外的方式來解決。
Singleton的循環依賴之構造注入
在上面介紹中，出現了一個很關鍵的地方：
|
1
2
3
4
5
6
7
8
9
10
11
|
sharedInstance = getSingleton(beanName, new ObjectFactory<Object>() { @Override public Object getObject() throws BeansException { try { return createBean(beanName, mbd, args); } catch (BeansException ex) { throw ex; } }}); |
這個getSingleton涉及到了ObjectFactory這個接口類，這個接口的功能和FactoryBean類似，但是主要是用來解決循環依賴的。在初始化過程同決定返回的Singleton對象是。關于單例的對象的創建，又要介紹一下DefaultSingletonBeanRegistry這個類，這個類主要用來幫助創建單例模式，其中主要的屬性：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
/** 緩存創建的單例對象: bean名字 --> bean對象 */private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);/** 緩存單例的factory,就是ObjectFactory這個東西，: bean name --> ObjectFactory */private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);/** 也是緩存創建的單例對象，功能和singletonObjects不一樣，在bean構造成功之后，屬性初始化之前會把對象放入到這里，主要是用于解決屬性注入的循環引用: bean name --> bean instance */private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);/** 記錄在創建單例對象中循環依賴的問題，還記得Prototype中又記錄創建過程中依賴的map嗎？在Prototype中只要出現了循環依賴就拋出異常，而在單例中會嘗試解決 */private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<String, Boolean>(16)); |
現在回過來看getSingleton(beanName, new ObjectFactory<Object>()這個方法的實現。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) { synchronized (this.singletonObjects) { //嘗試在singletonObjects中獲取 Object singletonObject = this.singletonObjects.get(beanName); if (singletonObject == null) { //不存在則創建 //把當前beanName加入到singletonsCurrentlyInCreation中 beforeSingletonCreation(beanName); try { singletonObject = singletonFactory.getObject(); } ... finally { ... //從singletonsCurrentlyInCreation中刪除beanName afterSingletonCreation(beanName); } } return (singletonObject != NULL_OBJECT ? singletonObject : null); }} |
這段邏輯是不是和Prototype中解決循環類似,這里其實就是調用了ObjectFactory的getObject()獲取對象，回過頭去看前面代碼，ObjectFactory的getObject()方法實際調用的是createBean(beanName, mbd, args)。說到createBean(beanName, mbd, args)又不得不說AbstractAutowireCapableBeanFactory這個類，主要功能就是完成依賴注入的Bean的創建，這個類的createBean方法代碼如下,注意注解說明：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
@Overrideprotected Object createBean(String beanName, RootBeanDefinition mbd, Object[] args) throws BeanCreationException { ... Object beanInstance = doCreateBean(beanName, mbdToUse, args); ...}protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final Object[] args) throws BeanCreationException { // 實例化bean BeanWrapper instanceWrapper = null; if (mbd.isSingleton()) { instanceWrapper = this.factoryBeanInstanceCache.remove(beanName); } if (instanceWrapper == null) { //如果沒實例化則創建新的BeanWrapper //如果是通過構造器注入，這里是一個關鍵點 /* 因為在A初始化的時候發現構造函數依賴B，就會去實例化B， 然后B也會運行到這段邏輯，構造函數中發現依賴A， 這個時候就會拋出循環依賴的異常 */ instanceWrapper = createBeanInstance(beanName, mbd, args); } //如果當前是單例，并且allowCircularReferences為true(默認就是true，除非我們不希望Spring幫我們解決) boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName)); if (earlySingletonExposure) { /* ！！！這里很重要，把構造成功，但屬性還沒注入的 的bean加到singletonFactory中，這樣再解決A的依賴 過程中如果依賴A，就把這個半成品返回回去。 */ addSingletonFactory(beanName, new ObjectFactory<Object>() { @Override public Object getObject() throws BeansException { return getEarlyBeanReference(beanName, mbd, bean); } }); } Object exposedObject = bean; try { //自動注入屬性 populateBean(beanName, mbd, instanceWrapper); if (exposedObject != null) { exposedObject = initializeBean(beanName, exposedObject, mbd); } } ... return exposedObject;} |
注解已經注明了我的理解。就不再贅述
總結
上面代碼是我一邊debug一個寫下的，現在寫完了，根據自己的理解總結一下。
相關類說明
AbstractBeanFactory,這個類中包含了Bean創建的主要流程，在doGetBean這個方法中包含了對Prototype循環依賴處理。邏輯很簡單，出現了循環依賴則直接拋出異常
DefaultSingletonBeanRegister 用于管理Singleton的對象的創建，以及解決循環依賴的問題,其中解決循環依賴的關鍵屬性就是了earlySingletonObjects，他會在構造Singleton對象過程中暫時緩存構造成功，但屬性還未注入的對象，這樣就可以解決循環依賴的問題。
AbstractAutowireCapableBeanFactory,自動注入的相關邏輯，包自動注入的對象的創建、初始化和注入。但如果在調用構造函數中發現了循環依賴，則拋出異常
ObjectFactory,這個接口功能和FactoryBean類似，但是為了解決循環依賴，他決定了在獲取的getSingleton()是一個完成品還是一個半成品。
思考
如果A--構造依賴->B，B--屬性依賴-->A，例如：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
@Componentpublic class BeanA { private BeanB beanB; @Autowired public BeanA(BeanB beanB) { this.beanB = beanB; }}@Componentpublic class BeanB { @Autowired private BeanA beanA;} |
這種情況會異常嗎？提示：都有可能
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：http://www.cnblogs.com/lizo/p/7401287.html
