Spring三級緩存解決循環依賴

轉載於: https://blog.csdn.net/fedorafrog/article/details/104550165

 

1. 前言

循環依賴：就是N個類循環（嵌套）引用。

通俗的講就是N個Bean互相引用對方，最終形成閉環。用一副經典的圖示可以表示成這樣（A、B、C都代表對象，虛線代表引用關系）：

• 其實可以N=1，也就是極限情況的循環依賴：自己依賴自己
• 這里指的循環引用不是方法之間的循環調用，而是對象的相互依賴關系。（方法之間循環調用若有出口也是能夠正常work的）

2. Spring Bean的循環依賴

談到Spring Bean的循環依賴，有的小伙伴可能比較陌生，畢竟開發過程中好像對循環依賴這個概念無感知。其實不然，你有這種錯覺，權是因為你工作在Spring的襁褓中，從而讓你“高枕無憂”~

我十分堅信，小伙伴們在平時業務開發中一定一定寫過如下結構的代碼：

1.  
   @Service
2.  
   public class AServiceImpl implements AService {
3.  
   @Autowired
4.  
   private BService bService;
5.  
   ...
6.  
   }
7.  
   @Service
8.  
   public class BServiceImpl implements BService {
9.  
   @Autowired
10.  
    private AService aService;
11.  
    ...
12.  
    }

這其實就是Spring環境下典型的循環依賴場景。但是很顯然，這種循環依賴場景，Spring已經完美的幫我們解決和規避了問題。所以即使平時我們這樣循環引用，也能夠整成進行我們的coding之旅~

3. Spring中三大循環依賴場景演示

在Spring環境中，因為我們的Bean的實例化、初始化都是交給了容器，因此它的循環依賴主要表現為下面三種場景。為了方便演示，我准備了如下兩個類：

3.1 構造器注入循環依賴

1.  
   @Service
2.  
   public class A {
3.  
   public A(B b) {
4.  
   }
5.  
   }
6.  
   @Service
7.  
   public class B {
8.  
   public B(A a) {
9.  
   }
10.  
    }

結果：項目啟動失敗拋出異常BeanCurrentlyInCreationException

1.  
   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?
2.  
   at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.beforeSingletonCreation(DefaultSingletonBeanRegistry.java: 339)
3.  
   at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java: 215)
4.  
   at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java: 318)
5.  
   at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java: 199)

構造器注入構成的循環依賴，此種循環依賴方式是無法解決的，只能拋出BeanCurrentlyInCreationException異常表示循環依賴。這也是構造器注入的最大劣勢（它有很多獨特的優勢，請小伙伴自行發掘）

根本原因：Spring解決循環依賴依靠的是Bean的“中間態”這個概念，而這個中間態指的是已經實例化，但還沒初始化的狀態。而構造器是完成實例化的東東，所以構造器的循環依賴無法解決~~~

3.2 singleton模式field屬性注入循環依賴

這種方式是我們最最最最為常用的依賴注入方式（所以猜都能猜到它肯定不會有問題啦）：

1.  
   @Service
2.  
   public class A {
3.  
   @Autowired
4.  
   private B b;
5.  
   }
6.  
    
7.  
   @Service
8.  
   public class B {
9.  
   @Autowired
10.  
    private A a;
11.  
    }

結果：項目啟動成功，能夠正常work

備注：setter方法注入方式因為原理和字段注入方式類似，此處不多加演示

3.3 prototype模式field屬性注入循環依賴

prototype在平時使用情況較少，但是也並不是不會使用到，因此此種方式也需要引起重視。

1.  
   @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
2.  
   @Service
3.  
   public class A {
4.  
   @Autowired
5.  
   private B b;
6.  
   }
7.  
    
8.  
   @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE)
9.  
   @Service
10.  
    public class B {
11.  
    @Autowired
12.  
    private A a;
13.  
    }

結果：需要注意的是本例中啟動時是不會報錯的（因為非單例Bean默認不會初始化，而是使用時才會初始化），所以很簡單咱們只需要手動getBean()或者在一個單例Bean內@Autowired一下它即可

1.  
   // 在單例Bean內注入
2.  
   @Autowired
3.  
   private A a;

這樣子啟動就報錯：

1.  
   org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mytest.TestSpringBean': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'a': Unsatisfied dependency expressed through field 'b'; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'b': Unsatisfied dependency expressed through field 'a'; nested exception is org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'a': Requested bean is currently in creation: Is there an unresolvable circular reference?
2.  
    
3.  
   at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java: 596)
4.  
   at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java: 90)
5.  
   at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessProperties(AutowiredAnnotationBeanPostProcessor.java: 374)

如何解決？？？
可能有的小伙伴看到網上有說使用@Lazy注解解決：

1.  
   @Lazy
2.  
   @Autowired
3.  
   private A a;

此處負責任的告訴你這樣是解決不了問題的(可能會掩蓋問題)，@Lazy只是延遲初始化而已，當你真正使用到它（初始化）的時候，依舊會報如上異常。

對於Spring循環依賴的情況總結如下：

不能解決的情況：

• 構造器注入循環依賴
• prototype模式field屬性注入循環依賴

能解決的情況：

• singleton模式field屬性注入（setter方法注入）循環依賴

4. Spring解決循環依賴的原理分析

在這之前需要明白java中所謂的引用傳遞和值傳遞的區別。

說明：看到這句話可能有小伙伴就想噴我了。java中明明都是傳遞啊，這是我初學java時背了100遍的面試題，怎么可能有錯？？？
這就是我做這個申明的必要性：伙計，你的說法是正確的，java中只有值傳遞。但是本文借用引用傳遞來輔助講解，希望小伙伴明白我想表達的意思~

Spring的循環依賴的理論依據基於Java的引用傳遞，當獲得對象的引用時，對象的屬性是可以延后設置的。（但是構造器必須是在獲取引用之前，畢竟你的引用是靠構造器給你生成的，兒子能先於爹出生？哈哈）

4.1 Spring創建Bean的流程

首先需要了解是Spring它創建Bean的流程，我把它的大致調用棧繪圖如下：

對Bean的創建最為核心三個方法解釋如下：

• createBeanInstance：例化，其實也就是調用對象的構造方法實例化對象
• populateBean：填充屬性，這一步主要是對bean的依賴屬性進行注入(@Autowired)
• initializeBean：回到一些形如initMethod、InitializingBean等方法

從對單例Bean的初始化可以看出，循環依賴主要發生在第二步（populateBean），也就是field屬性注入的處理。

4.2 Spring容器的“三級緩存”

在Spring容器的整個聲明周期中，單例Bean有且僅有一個對象。這很容易讓人想到可以用緩存來加速訪問。
從源碼中也可以看出Spring大量運用了Cache的手段，在循環依賴問題的解決過程中甚至不惜使用了“三級緩存”，這也便是它設計的精妙之處~

三級緩存其實它更像是Spring容器工廠的內的術語，采用三級緩存模式來解決循環依賴問題，這三級緩存分別指：

1.  
   public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
2.  
   ...
3.  
   // 從上至下 分表代表這“三級緩存”
4.  
   private final Map<String, Object> singletonObjects = new ConcurrentHashMap<>(256); //一級緩存
5.  
   private final Map<String, Object> earlySingletonObjects = new HashMap<>(16); // 二級緩存
6.  
   private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<>(16); // 三級緩存
7.  
   ...
8.  
    
9.  
   /** Names of beans that are currently in creation. */
10.  
    // 這個緩存也十分重要：它表示bean創建過程中都會在里面呆着~
11.  
    // 它在Bean開始創建時放值，創建完成時會將其移出~
12.  
    private final Set<String> singletonsCurrentlyInCreation = Collections.newSetFromMap(new ConcurrentHashMap<>(16));
13.  
     
14.  
    /** Names of beans that have already been created at least once. */
15.  
    // 當這個Bean被創建完成后，會標記為這個 注意：這里是set集合 不會重復
16.  
    // 至少被創建了一次的 都會放進這里~~~~
17.  
    private final Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256));
18.  
    }

注：AbstractBeanFactory繼承自DefaultSingletonBeanRegistry

• singletonObjects：用於存放完全初始化好的 bean，從該緩存中取出的 bean 可以直接使用
• earlySingletonObjects：提前曝光的單例對象的cache，存放原始的 bean 對象（尚未填充屬性），用於解決循環依賴
• singletonFactories：單例對象工廠的cache，存放 bean 工廠對象，用於解決循環依賴

獲取單例Bean的源碼如下：

1.  
   public class DefaultSingletonBeanRegistry extends SimpleAliasRegistry implements SingletonBeanRegistry {
2.  
   ...
3.  
   @Override
4.  
   @Nullable
5.  
   public Object getSingleton(String beanName) {
6.  
   return getSingleton(beanName, true);
7.  
   }
8.  
   @Nullable
9.  
   protected Object getSingleton(String beanName, boolean allowEarlyReference) {
10.  
    Object singletonObject = this.singletonObjects.get(beanName);
11.  
    if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
12.  
    synchronized (this.singletonObjects) {
13.  
    singletonObject = this.earlySingletonObjects.get(beanName);
14.  
    if (singletonObject == null && allowEarlyReference) {
15.  
    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
16.  
    if (singletonFactory != null) {
17.  
    singletonObject = singletonFactory.getObject();
18.  
    this.earlySingletonObjects.put(beanName, singletonObject);
19.  
    this.singletonFactories.remove(beanName);
20.  
    }
21.  
    }
22.  
    }
23.  
    }
24.  
    return singletonObject;
25.  
    }
26.  
    ...
27.  
    public boolean isSingletonCurrentlyInCreation(String beanName) {
28.  
    return this.singletonsCurrentlyInCreation.contains(beanName);
29.  
    }
30.  
    protected boolean isActuallyInCreation(String beanName) {
31.  
    return isSingletonCurrentlyInCreation(beanName);
32.  
    }
33.  
    ...
34.  
    }

1. 先從一級緩存singletonObjects中去獲取。（如果獲取到就直接return）
2. 如果獲取不到或者對象正在創建中（isSingletonCurrentlyInCreation()），那就再從二級緩存earlySingletonObjects中獲取。（如果獲取到就直接return）
3. 如果還是獲取不到，且允許singletonFactories（allowEarlyReference=true）通過getObject()獲取。就從三級緩存singletonFactory.getObject()獲取。（如果獲取到了就從singletonFactories中移除，並且放進earlySingletonObjects。其實也就是從三級緩存移動（是剪切、不是復制哦~）到了二級緩存）

加入singletonFactories三級緩存的前提是執行了構造器，所以構造器的循環依賴沒法解決

getSingleton()從緩存里獲取單例對象步驟分析可知，Spring解決循環依賴的訣竅：就在於singletonFactories這個三級緩存。這個Cache里面都是ObjectFactory，它是解決問題的關鍵。

1.  
   // 它可以將創建對象的步驟封裝到ObjectFactory中 交給自定義的Scope來選擇是否需要創建對象來靈活的實現scope。 具體參見Scope接口
2.  
   @FunctionalInterface
3.  
   public interface ObjectFactory<T> {
4.  
   T getObject() throws BeansException;
5.  
   }

經過ObjectFactory.getObject()后，此時放進了二級緩存earlySingletonObjects內。這個時候對象已經實例化了，雖然還不完美，但是對象的引用已經可以被其它引用了。

此處說一下二級緩存earlySingletonObjects它里面的數據什么時候添加什么移除？？?

添加：向里面添加數據只有一個地方，就是上面說的getSingleton()里從三級緩存里挪過來
移除：addSingleton、addSingletonFactory、removeSingleton從語義中可以看出添加單例、添加單例工廠ObjectFactory的時候都會刪除二級緩存里面對應的緩存值，是互斥的。

4.3 源碼解析

Spring容器會將每一個正在創建的Bean 標識符放在一個“當前創建Bean池”中，Bean標識符在創建過程中將一直保持在這個池中，而對於創建完畢的Bean將從當前創建Bean池中清除掉。

這個“當前創建Bean池”指的是上面提到的singletonsCurrentlyInCreation那個集合。

1.  
   public abstract class AbstractBeanFactory extends FactoryBeanRegistrySupport implements ConfigurableBeanFactory {
2.  
   ...
3.  
   protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType, @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
4.  
   ...
5.  
   // Eagerly check singleton cache for manually registered singletons.
6.  
   // 先去獲取一次，如果不為null，此處就會走緩存了~~
7.  
   Object sharedInstance = getSingleton(beanName);
8.  
   ...
9.  
   // 如果不是只檢查類型，那就標記這個Bean被創建了~~添加到緩存里 也就是所謂的 當前創建Bean池
10.  
    if (!typeCheckOnly) {
11.  
    markBeanAsCreated(beanName);
12.  
    }
13.  
    ...
14.  
    // Create bean instance.
15.  
    if (mbd.isSingleton()) {
16.  
     
17.  
    // 這個getSingleton方法不是SingletonBeanRegistry的接口方法 屬於實現類DefaultSingletonBeanRegistry的一個public重載方法~~~
18.  
    // 它的特點是在執行singletonFactory.getObject();前后會執行beforeSingletonCreation(beanName);和afterSingletonCreation(beanName);
19.  
    // 也就是保證這個Bean在創建過程中，放入正在創建的緩存池里 可以看到它實際創建bean調用的是我們的createBean方法~~~~
20.  
    sharedInstance = getSingleton(beanName, () -> {
21.  
    try {
22.  
    return createBean(beanName, mbd, args);
23.  
    } catch (BeansException ex) {
24.  
    destroySingleton(beanName);
25.  
    throw ex;
26.  
    }
27.  
    });
28.  
    bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
29.  
    }
30.  
    }
31.  
    ...
32.  
    }
33.  
     
34.  
    // 抽象方法createBean所在地 這個接口方法是屬於抽象父類AbstractBeanFactory的 實現在這個抽象類里
35.  
    public abstract class AbstractAutowireCapableBeanFactory extends AbstractBeanFactory implements AutowireCapableBeanFactory {
36.  
    ...
37.  
    protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args) throws BeanCreationException {
38.  
    ...
39.  
    // 創建Bean對象，並且將對象包裹在BeanWrapper 中
40.  
    instanceWrapper = createBeanInstance(beanName, mbd, args);
41.  
    // 再從Wrapper中把Bean原始對象（非代理~~~） 這個時候這個Bean就有地址值了，就能被引用了~~~
42.  
    // 注意：此處是原始對象，這點非常的重要
43.  
    final Object bean = instanceWrapper.getWrappedInstance();
44.  
    ...
45.  
    // earlySingletonExposure 用於表示是否”提前暴露“原始對象的引用，用於解決循環依賴。
46.  
    // 對於單例Bean，該變量一般為 true 但你也可以通過屬性allowCircularReferences = false來關閉循環引用
47.  
    // isSingletonCurrentlyInCreation(beanName) 表示當前bean必須在創建中才行
48.  
    boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
49.  
    if (earlySingletonExposure) {
50.  
    if (logger.isTraceEnabled()) {
51.  
    logger.trace( "Eagerly caching bean '" + beanName + "' to allow for resolving potential circular references");
52.  
    }
53.  
    // 上面講過調用此方法放進一個ObjectFactory，二級緩存會對應刪除的
54.  
    // getEarlyBeanReference的作用：調用SmartInstantiationAwareBeanPostProcessor.getEarlyBeanReference()這個方法 否則啥都不做
55.  
    // 也就是給調用者個機會，自己去實現暴露這個bean的應用的邏輯~~~
56.  
    // 比如在getEarlyBeanReference()里可以實現AOP的邏輯~~~ 參考自動代理創建器AbstractAutoProxyCreator 實現了這個方法來創建代理對象
57.  
    // 若不需要執行AOP的邏輯，直接返回Bean
58.  
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
59.  
    }
60.  
    Object exposedObject = bean; //exposedObject 是最終返回的對象
61.  
    ...
62.  
    // 填充屬於，解決@Autowired依賴~
63.  
    populateBean(beanName, mbd, instanceWrapper);
64.  
    // 執行初始化回調方法們~~~
65.  
    exposedObject = initializeBean(beanName, exposedObject, mbd);
66.  
     
67.  
    // earlySingletonExposure：如果你的bean允許被早期暴露出去 也就是說可以被循環引用 那這里就會進行檢查
68.  
    // 此段代碼非常重要~~~~~但大多數人都忽略了它
69.  
    if (earlySingletonExposure) {
70.  
    // 此時一級緩存肯定還沒數據，但是呢此時候二級緩存earlySingletonObjects也沒數據
71.  
    //注意，注意：第二參數為false 表示不會再去三級緩存里查了~~~
72.  
     
73.  
    // 此處非常巧妙的一點：：：因為上面各式各樣的實例化、初始化的后置處理器都執行了，如果你在上面執行了這一句
74.  
    // ((ConfigurableListableBeanFactory)this.beanFactory).registerSingleton(beanName, bean);
75.  
    // 那么此處得到的earlySingletonReference 的引用最終會是你手動放進去的Bean最終返回，完美的實現了"偷天換日" 特別適合中間件的設計
76.  
    // 我們知道，執行完此doCreateBean后執行addSingleton() 其實就是把自己再添加一次 **再一次強調，完美實現偷天換日**
77.  
    Object earlySingletonReference = getSingleton(beanName, false);
78.  
    if (earlySingletonReference != null) {
79.  
     
80.  
    // 這個意思是如果經過了initializeBean()后，exposedObject還是木有變，那就可以大膽放心的返回了
81.  
    // initializeBean會調用后置處理器，這個時候可以生成一個代理對象，那這個時候它哥倆就不會相等了 走else去判斷吧
82.  
    if (exposedObject == bean) {
83.  
    exposedObject = earlySingletonReference;
84.  
    }
85.  
     
86.  
    // allowRawInjectionDespiteWrapping這個值默認是false
87.  
    // hasDependentBean：若它有依賴的bean 那就需要繼續校驗了~~~(若沒有依賴的 就放過它~)
88.  
    else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
89.  
    // 拿到它所依賴的Bean們~~~~ 下面會遍歷一個一個的去看~~
90.  
    String[] dependentBeans = getDependentBeans(beanName);
91.  
    Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
92.  
     
93.  
    // 一個個檢查它所以Bean
94.  
    // removeSingletonIfCreatedForTypeCheckOnly這個放見下面 在AbstractBeanFactory里面
95.  
    // 簡單的說，它如果判斷到該dependentBean並沒有在創建中的了的情況下,那就把它從所有緩存中移除~~~ 並且返回true
96.  
    // 否則（比如確實在創建中） 那就返回false 進入我們的if里面~ 表示所謂的真正依賴
97.  
    //（解釋：就是真的需要依賴它先實例化，才能實例化自己的依賴）
98.  
    for (String dependentBean : dependentBeans) {
99.  
    if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
100.  
     actualDependentBeans.add(dependentBean);
101.  
     }
102.  
     }
103.  
      
104.  
     // 若存在真正依賴，那就報錯（不要等到內存移除你才報錯，那是非常不友好的）
105.  
     // 這個異常是BeanCurrentlyInCreationException，報錯日志也稍微留意一下，方便定位錯誤~~~~
106.  
     if (!actualDependentBeans.isEmpty()) {
107.  
     throw new BeanCurrentlyInCreationException(beanName,
108.  
     "Bean with name '" + beanName + "' has been injected into other beans [" +
109.  
     StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
110.  
     "] in its raw version as part of a circular reference, but has eventually been " +
111.  
     "wrapped. This means that said other beans do not use the final version of the " +
112.  
     "bean. This is often the result of over-eager type matching - consider using " +
113.  
     "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
114.  
     }
115.  
     }
116.  
     }
117.  
     }
118.  
      
119.  
     return exposedObject;
120.  
     }
121.  
      
122.  
     // 雖然是remove方法 但是它的返回值也非常重要
123.  
     // 該方法唯一調用的地方就是循環依賴的最后檢查處~~~~~
124.  
     protected boolean removeSingletonIfCreatedForTypeCheckOnly(String beanName) {
125.  
     // 如果這個bean不在創建中 比如是ForTypeCheckOnly的 那就移除掉
126.  
     if (!this.alreadyCreated.contains(beanName)) {
127.  
     removeSingleton(beanName);
128.  
     return true;
129.  
     }
130.  
     else {
131.  
     return false;
132.  
     }
133.  
     }
134.  
      
135.  
     }

這里舉例：例如是field屬性依賴注入，在populateBean時它就會先去完成它所依賴注入的那個bean的實例化、初始化過程，最終返回到本流程繼續處理，因此Spring這樣處理是不存在任何問題的。

這里有個小細節：

1.  
   if (exposedObject == bean) {
2.  
   exposedObject = earlySingletonReference;
3.  
   }

這一句如果exposedObject == bean表示最終返回的對象就是原始對象，說明在populateBean和initializeBean沒對他代理過，那就啥話都不說了exposedObject = earlySingletonReference，最終把二級緩存里的引用返回即可~

4.4 流程總結

此處以如上的A、B類的互相依賴注入為例，在這里表達出關鍵代碼的走勢：

1. 入口處即是實例化、初始化A這個單例Bean。AbstractBeanFactory.doGetBean("a")

1.  
   protected <T> T doGetBean(...){
2.  
   ...
3.  
   // 標記beanName a是已經創建過至少一次的~~~ 它會一直存留在緩存里不會被移除（除非拋出了異常）
4.  
   // 參見緩存Set<String> alreadyCreated = Collections.newSetFromMap(new ConcurrentHashMap<>(256))
5.  
   if (!typeCheckOnly) {
6.  
   markBeanAsCreated(beanName);
7.  
   }
8.  
    
9.  
   // 此時a不存在任何一級緩存中，且不是在創建中 所以此處返回null
10.  
    // 此處若不為null，然后從緩存里拿就可以了(主要處理FactoryBean和BeanFactory情況吧)
11.  
    Object beanInstance = getSingleton(beanName, false);
12.  
    ...
13.  
    // 這個getSingleton方法非常關鍵。
14.  
    //1、標注a正在創建中~
15.  
    //2、調用singletonObject = singletonFactory.getObject();（實際上調用的是createBean()方法） 因此這一步最為關鍵
16.  
    //3、此時實例已經創建完成 會把a移除整整創建的緩存中
17.  
    //4、執行addSingleton()添加進去。（備注：注冊bean的接口方法為registerSingleton，它依賴於addSingleton方法）
18.  
    sharedInstance = getSingleton(beanName, () -> { ... return createBean(beanName, mbd, args); });
19.  
    }

2. 下面進入到最為復雜的AbstractAutowireCapableBeanFactory.createBean/doCreateBean()環節，創建A的實例

1.  
   protected Object doCreateBean(){
2.  
   ...
3.  
   // 使用構造器/工廠方法 instanceWrapper是一個BeanWrapper
4.  
   instanceWrapper = createBeanInstance(beanName, mbd, args);
5.  
   // 此處bean為"原始Bean" 也就是這里的A實例對象：A@1234
6.  
   final Object bean = instanceWrapper.getWrappedInstance();
7.  
   ...
8.  
   // 是否要提前暴露（允許循環依賴） 現在此處A是被允許的
9.  
   boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences && isSingletonCurrentlyInCreation(beanName));
10.  
     
11.  
    // 允許暴露，就把A綁定在ObjectFactory上，注冊到三級緩存`singletonFactories`里面去保存着
12.  
    // Tips:這里后置處理器的getEarlyBeanReference方法會被促發，自動代理創建器在此處創建代理對象（注意執行時機 為執行三級緩存的時候）
13.  
    if (earlySingletonExposure) {
14.  
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
15.  
    }
16.  
    ...
17.  
    // exposedObject 為最終返回的對象，此處為原始對象bean也就是A@1234,下面會有用處
18.  
    Object exposedObject = bean;
19.  
    // 給A@1234屬性完成賦值，@Autowired在此處起作用~
20.  
    // 因此此處會調用getBean("b")，so 會重復上面步驟創建B類的實例
21.  
    // 此處我們假設B已經創建好了 為B@5678
22.  
     
23.  
    // 需要注意的是在populateBean("b")的時候依賴有beanA，所以此時候調用getBean("a")最終會調用getSingleton("a")，
24.  
    //此時候上面說到的getEarlyBeanReference方法就會被執行。這也解釋為何我們@Autowired是個代理對象，而不是普通對象的根本原因
25.  
     
26.  
    populateBean(beanName, mbd, instanceWrapper);
27.  
    // 實例化。這里會執行后置處理器BeanPostProcessor的兩個方法
28.  
    // 此處注意：postProcessAfterInitialization()是有可能返回一個代理對象的，這樣exposedObject 就不再是原始對象了 特備注意哦~~~
29.  
    // 比如處理@Aysnc的AsyncAnnotationBeanPostProcessor它就是在這個時間里生成代理對象的（有坑，請小心使用@Aysnc）
30.  
    exposedObject = initializeBean(beanName, exposedObject, mbd);
31.  
     
32.  
    ... // 至此，相當於A@1234已經實例化完成、初始化完成（屬性也全部賦值了~）
33.  
    // 這一步我把它理解為校驗：校驗：校驗是否有循環引用問題~~~~~
34.  
     
35.  
    if (earlySingletonExposure) {
36.  
    // 注意此處第二個參數傳的false，表示不去三級緩存里singletonFactories再去調用一次getObject()方法了~~~
37.  
    // 上面建講到了由於B在初始化的時候，會觸發A的ObjectFactory.getObject() 所以a此處已經在二級緩存earlySingletonObjects里了
38.  
    // 因此此處返回A的實例：A@1234
39.  
    Object earlySingletonReference = getSingleton(beanName, false);
40.  
    if (earlySingletonReference != null) {
41.  
     
42.  
    // 這個等式表示，exposedObject若沒有再被代理過，這里就是相等的
43.  
    // 顯然此處我們的a對象的exposedObject它是沒有被代理過的 所以if會進去~
44.  
    // 這種情況至此，就全部結束了~~~
45.  
    if (exposedObject == bean) {
46.  
    exposedObject = earlySingletonReference;
47.  
    }
48.  
     
49.  
    // 繼續以A為例，比如方法標注了@Aysnc注解，exposedObject此時候就是一個代理對象，因此就會進到這里來
50.  
    //hasDependentBean(beanName)是肯定為true，因為getDependentBeans(beanName)得到的是["b"]這個依賴
51.  
    else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
52.  
    String[] dependentBeans = getDependentBeans(beanName);
53.  
    Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
54.  
     
55.  
    // A@1234依賴的是["b"]，所以此處去檢查b
56.  
    // 如果最終存在實際依賴的bean：actualDependentBeans不為空 那就拋出異常 證明循環引用了~
57.  
    for (String dependentBean : dependentBeans) {
58.  
    // 這個判斷原則是：如果此時候b並還沒有創建好，this.alreadyCreated.contains(beanName)=true表示此bean已經被創建過，就返回false
59.  
    // 若該bean沒有在alreadyCreated緩存里，就是說沒被創建過(其實只有CreatedForTypeCheckOnly才會是此倉庫)
60.  
    if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
61.  
    actualDependentBeans.add(dependentBean);
62.  
    }
63.  
    }
64.  
    if (!actualDependentBeans.isEmpty()) {
65.  
    throw new BeanCurrentlyInCreationException(beanName,
66.  
    "Bean with name '" + beanName + "' has been injected into other beans [" +
67.  
    StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
68.  
    "] in its raw version as part of a circular reference, but has eventually been " +
69.  
    "wrapped. This means that said other beans do not use the final version of the " +
70.  
    "bean. This is often the result of over-eager type matching - consider using " +
71.  
    "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
72.  
    }
73.  
    }
74.  
    }
75.  
    }
76.  
    }

由於關鍵代碼部分的步驟不太好拆分，為了更具象表達，那么使用下面一副圖示幫助小伙伴們理解：

5. 總結

依舊以上面A、B類使用屬性field注入循環依賴的例子為例，對整個流程做文字步驟總結如下：

1. 使用context.getBean(A.class)，旨在獲取容器內的單例A(若A不存在，就會走A這個Bean的創建流程)，顯然初次獲取A是不存在的，因此走A的創建之路~
2. 實例化A（注意此處僅僅是實例化），並將它放進緩存（此時A已經實例化完成，已經可以被引用了）
3. 初始化A：@Autowired依賴注入B（此時需要去容器內獲取B）
4. 為了完成依賴注入B，會通過getBean(B)去容器內找B。但此時B在容器內不存在，就走向B的創建之路~
5. 實例化B，並將其放入緩存。（此時B也能夠被引用了）
6. 初始化B，@Autowired依賴注入A（此時需要去容器內獲取A）
7. 此處重要：初始化B時會調用getBean(A)去容器內找到A，上面我們已經說過了此時候因為A已經實例化完成了並且放進了緩存里，所以這個時候去看緩存里是已經存在A的引用了的，所以getBean(A)能夠正常返回
8. B初始化成功（此時已經注入A成功了，已成功持有A的引用了），return（注意此處return相當於是返回最上面的getBean(B)這句代碼，回到了初始化A的流程中~）。
9. 因為B實例已經成功返回了，因此最終A也初始化成功
10. 到此，B持有的已經是初始化完成的A，A持有的也是初始化完成的B，完美~

站的角度高一點，宏觀上看Spring處理循環依賴的整個流程就是如此。希望這個宏觀層面的總結能更加有助於小伙伴們對Spring解決循環依賴的原理的了解，同時也順便能解釋為何構造器循環依賴就不好使的原因。