Spring為什麼使用三級緩存而不是兩級解決循環依賴問題？

首先明确一點，Spring如果使用二級緩存也是完全能夠解決代理bean的循環依賴問題的。那Spring為什麼要使用三級緩存的設計呢？在回答這個問題前我們先明确一些概念。

Spring Bean相關的知識

Spring Bean 的建立過程

1. 掃描xml或者注解擷取BeanDefinition；
2. 執行個體化bean：通過createBeanInstance方法建立bean的原始對象BeanWrapper；
3. 注入bean的依賴：利用populateBean方法（本質是反射）注入bean的依賴屬性；
4. 初始化bean：調用initializeBean方法最終形成完整的bean對象；

Spring Bean 的三級緩存定義

三級緩存的查找政策是，先從一級緩存擷取，若擷取不到就從二級緩存，仍然擷取不到則從三級緩存擷取，若還是擷取不到則通過bean對應的BeanDefinition資訊執行個體化。

Tips：二、三級緩存會在DI的過程中被删除，最終所有的Bean都會變成完整的bean并存入一級緩存中。

• 三級緩存singletonFactories：在注入bean的依賴前存入，所有bean都會存入，循環依賴時會使用，代碼如下：

/** Cache of singleton factories: bean name --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);           

• 二級緩存earlySingletonObjects：存放執行個體化的對象（可能是原始對象也可能是代理對象），代碼如下：

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

• 一級緩存singletonObjects：用于存放完整的bean，代碼如下：

/** Cache of singleton objects: bean name --> bean instance */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);           

什麼是循環依賴？

循環依賴是指：Spring在初始化A的時候需要注入B，而初始化B的時候需要注入A，在Spring啟動完成後這倆個對象都必須是完整的bean。

循環依賴的場景有三種：

• 構造器循環依賴：Spring無法解決，因為bean建立的第一步就是通過構造器執行個體化，也就是說解決循環依賴的前提就是對象可以執行個體化并緩存，與Java死鎖很像；
• prototype範圍的依賴：該循環依賴Spring不可解決，prototype作用域的bean Spring不緩存，是以在依賴注入時無法擷取到依賴的bean；
• setter循環依賴：該循環依賴是Spring推薦的方式，我們接下來就重點講解這種方式；

一個簡單setter循環依賴的代碼示例如下：

@Service
public class A {
    // @Autowired也行
    @Resource
 	private B b;
}

@Service
public class B {
    // @Autowired也行
    @Resource
 	private A a;
}           

Spring 是如何利用多級緩存解決循環依賴的

我們先抛開Spring的實作來做一次解決循環依賴的設計推演。

在沒有緩存的情況下循環依賴的場景

如圖可以直接觀察到，當沒有緩存時，當發生循環依賴時直接死循環了，最終的結局就是StackOverflow或者OOM。

增加一層緩存

為了解決上面循環依賴的問題，我們加入一層緩存，緩存可以使用Map結構，key為beanName，value為對象執行個體。如下如：

從上圖可以直覺的看出，循環依賴的問題已經得到了完美解決，但是又有了一個新問題，這個緩存中的bean可能有已經建立完成的、正在建立中還沒有注入依賴的，它們都摻雜在一起，我們如何保證Map裡面的所有對象是完整的呢？一層緩存很顯然不符合設計規範，也缺乏安全性與擴充性。

二級緩存設計

我們希望的是，明确已經建構完成的的Bean被放入到一個緩存中，建立中的bean在另外一個緩存中，于是就有了下面的結構：

與一級緩存架構設計的差別在于：

• 新增了二級緩存，用于存放剛執行個體化的bean；
• 當bean初始化完成後會放入一級緩存，同時将bean從二級緩存中的删除（不需要一式兩份，保留一份最終完整的Bean即可）

從目前看這個設計完美解決了bean的完整性問題，但是在實際生産中問題總是疊着問題，沒有完美的架構設計。我們都知道Java中有代理，而且代理的應用非常廣泛，包括在Spring中就有非常多的代理，那問題就來了，我們如何區分代理對象與普通對象？如果循環依賴中存在代理對象的循環依賴會發生什麼呢？

代理對象的循環依賴

在現實開發過程中，我們往往會産生很多的代理對象，當存在代理對象加入到循環依賴流程會是什麼樣的場景，我們來推演一下，我們仍然使用二級緩存的設計來做推演。

如果我們在bean初始化完成之後再建立代理對象，整個流程是這樣的：

從上圖可以非常直覺的看出，最終在一級緩存中的對象A是一個proxy_A，但是對象B依賴的對象A卻是一個普通A！很明顯現有的設計不能夠滿足代理對象的循環依賴問題。

如何解決這個問題呢？我們還是在上一個設計上做修改：

• 方案一：在擷取到A時立即建立代理，如下圖（紅色部分）所示：

這個方案看起來解決了B對象依賴不到A的proxy對象問題，但是又引起了一個緻命的問題，在A初始化完成之後還會建立一次代理對象，那麼就建立了兩次代理對象，他們是完全不一樣的，這個代理對象不是單例的了！

• 方案二：在方案一的基礎上，我們是不是可以将建立完的proxy_A對象加入到二級緩存中，直接覆寫掉普通A（代理對象會持有普通對象A的引用，是以可以覆寫）：這個方案看上去沒有問題，但是從設計角度講，這不符合設計規範，而且覆寫後的A是個代理對象，在後續的操作中，如果再從二級緩存中擷取A，這時候就不知道到底擷取到的是普通A還是proxy_A了，這無形增加了判斷識别的複雜度。

• 方案三：在首次執行個體化A的時候就直接建立A的代理對象，并放入二級緩存中：這個方案與方案二有相同的問題，這裡不在贅述。

解決代理對象的循環依賴之終極方案

解決代理對象的循環依賴之終極方案-三級緩存！

與二級緩存設計最大的不同點在于：

• 在擷取到A時建立proxy_A，同時将其加入到二級緩存中，并傳回給B，這樣B就依賴了proxy_A；
• 在A初始化過程中會建立代理對象，這時候會做一個檢查，也就是會去查詢二級緩存，看有沒有proxy_A的存在，如果有說明proxy_A已經建立，我們會選擇二級緩存中的proxy_A存入一級緩存并傳回（因為二級緩存中的proxy_A已經被B依賴）；

其它流程不在贅述，該設計中最重要的幾個地方在Spring中的實作是更加細緻的，我在流程途中隻是簡單概括，下面特殊說明一下幾個點。

Spring Bean初始化會産生代理對象的場景

在上述流程中，标記位黃色的部分就是兩個代理對象的建立的地方，在Spring中就是這兩個後置處理器調用的地方，它們分别是：

• 在調用getEarlyBeanReference時如果實作了BeanPostProcessor則會建立代理對象；
• 另一個地方是在執行Bean初始化initializeBean時執行BeanPostProcessor會建立代理對象；

在Spring中的第三級緩存有更加靈活設計

在Spring中，第三級緩存不僅僅是存入了執行個體化的對象，而是存入了一個匿名類ObjectFactory，getEarlyBeanReference函數的實作中會調用BeanPostProcessor執行使用者自定義的邏輯。具體代碼如下：

// Eagerly cache singletons to be able to resolve circular references
// even when triggered by lifecycle interfaces like BeanFactoryAware.
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");
    }
    // addSingletonFactory方法是将bean加入三級緩存中
    // 三級緩存會被ObjectFactory包裝
    // getEarlyBeanReference方法會執行Bean的後置處理器
    addSingletonFactory(beanName, new ObjectFactory<Object>() {
        @Override
        public Object getObject() throws BeansException {
            return getEarlyBeanReference(beanName, mbd, bean);
        }
    });
}           

若初始化階段的後置處理器對對象做了代理，Spring是如何處理的？

在Spring中若在initializeBean階段的後置處理器對對象做了代理，那麼Spring會對做依賴檢查，具體代碼如下：

if (earlySingletonExposure) {
    // 這裡我們還拿A、B兩個對象舉例
    // 嘗試從二級緩存中擷取A，第二個參數是false表示不再從三級緩存擷取（也就是執行ObjectFactory.getObject()）
    Object earlySingletonReference = getSingleton(beanName, false);
    if (earlySingletonReference != null) {
        // exposedObject是執行initializeBean方法傳回的A，可能是個proxy_A
        // bean是首次執行個體化的A，若這兩個對象不相等，說明initializeBean方法傳回了代理對象，需要進行依賴檢查
        if (exposedObject == bean) {
            exposedObject = earlySingletonReference;
        }
        // 依賴檢查邏輯
        // 這一大段就是在檢查，檢查依賴了A對象的Bean集合
        // 這裡很好了解：例如B依賴了A，那麼如果B沒有建立好，那麼我們把B從緩存删掉，在之後的建構中讓其重新依賴A_proxy
        // 若B已經建立好了，那麼很不幸，隻能報錯了，因為B這時候依賴的是一個普通A，而不是proxy_A
        else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
            String[] dependentBeans = getDependentBeans(beanName);
            Set<String> actualDependentBeans = new LinkedHashSet<String>(dependentBeans.length);
            for (String dependentBean : dependentBeans) {
                if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
                    actualDependentBeans.add(dependentBean);
                }
            }
            if (!actualDependentBeans.isEmpty()) {
                throw new BeanCurrentlyInCreationException(beanName,
                        "Bean with name '" + beanName + "' has been injected into other beans [" +
                        StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
                        "] in its raw version as part of a circular reference, but has eventually been " +
                        "wrapped. This means that said other beans do not use the final version of the " +
                        "bean. This is often the result of over-eager type matching - consider using " +
                        "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
            }
        }
    }
}           

為什麼Spring采用三級緩存設計？

我們再回到最初的問題上，其實上述整個設計推演過程就已經很好的回答了這個問題，這裡再做一下補充。從上述Spring源碼可知，其在第三級緩存中放入的是匿名類ObjectFactory，每次需要擷取對象執行個體就會調用其getObject方法。我們舉個例子：

假如現在沒有earlySingletonObjects這一層緩存（也就是第二級緩存），也就是兩級緩存結構，現在有三個對象，其依賴關系如下A->B、B->A和C、C->A，從這個依賴關系可以得出，A所在的ObjectFactory會被調用兩次getObject()，如果兩次都傳回不同的proxy_A（畢竟後置處理器的代碼是使用者自己寫的，可能代碼是new Proxy(A)），那麼就可能導緻，B、C對象依賴的proxy_A不是一個對象，那麼這種設計是緻命的。

這個案例也從側面反映了三層緩存的設計必要性、必然性，也是為了讓架構更加的靈活健壯，以上就是我對Spring bean 三層緩存設計的了解，如有疑問歡迎在評論區讨論留言。

我是搬長，如果文章給你帶來了收獲，請關注+點贊，你的支援是我最大的動力！