征服阿里P7的Spring迴圈依賴原理解析，高薪offer唾手可得

不多說，直接進入主題

在這裡插入圖片描述

什麼是迴圈依賴？

很簡單，就是A物件依賴了B物件，B物件依賴了A物件。

比如：

// A依賴了B
class A{
    public B b;
}
// B依賴了A
class B{
    public A a;
}

那麼迴圈依賴是個問題嗎？

如果不考慮Spring，迴圈依賴並不是問題，因為物件之間相互依賴是很正常的事情。

比如

A a = new A();
B b = new B();
a.b = b;b.a = a;

這樣，A,B就依賴上了。

但是，在Spring中迴圈依賴就是一個問題了，為什麼？

因為，在Spring中，一個物件並不是簡單new出來了，而是會經過一系列的Bean的生命週期，就是因為Bean的生命週期所以才會出現迴圈依賴問題。當然，在Spring中，出現迴圈依賴的場景很多，有的場景Spring自動幫我們解決了，而有的場景則需要程式設計師來解決，下文詳細來說。

要明白Spring中的迴圈依賴，得先明白Spring中Bean的生命週期。

Bean的生命週期

這裡不會對Bean的生命週期進行詳細的描述，只描述一下大概的過程。

Bean的生命週期指的就是：在Spring中，Bean是如何生成的？

被Spring管理的物件叫做Bean。Bean的生成步驟如下：

Spring掃描class得到BeanDefinition
根據得到的BeanDefinition去生成bean
首先根據class推斷構造方法
根據推斷出來的構造方法，反射，得到一個物件（暫時叫做原始物件）
填充原始物件中的屬性（依賴注入）
如果原始物件中的某個方法被AOP了，那麼則需要根據原始物件生成一個代理物件
把最終生成的代理物件放入單例池（原始碼中叫做singletonObjects）中，下次getBean時就直接從單例池拿即可

可以看到，對於Spring中的Bean的生成過程，步驟還是很多的，並且不僅僅只有上面的7步，還有很多很多，比如Aware回撥、初始化等等，這裡不詳細討論。

可以發現，在Spring中，構造一個Bean，包括了new這個步驟（第4步構造方法反射）。

得到一個原始物件後，Spring需要給物件中的屬性進行依賴注入，那麼這個注入過程是怎樣的？

比如上文說的A類，A類中存在一個B類的b屬性，所以，當A類生成了一個原始物件之後，就會去給b屬性去賦值，此時就會根據b屬性的型別和屬性名去BeanFactory中去獲取B類所對應的單例bean。如果此時BeanFactory中存在B對應的Bean，那麼直接拿來賦值給b屬性；如果此時BeanFactory中不存在B對應的Bean，則需要生成一個B對應的Bean，然後賦值給b屬性。

問題就出現在第二種情況，如果此時B類在BeanFactory中還沒有生成對應的Bean，那麼就需要去生成，就會經過B的Bean的生命週期。

那麼在建立B類的Bean的過程中，如果B類中存在一個A類的a屬性，那麼在建立B的Bean的過程中就需要A類對應的Bean，但是，觸發B類Bean的建立的條件是A類Bean在建立過程中的依賴注入，所以這裡就出現了迴圈依賴：

ABean建立–>依賴了B屬性–>觸發BBean建立—>B依賴了A屬性—>需要ABean（但ABean還在建立過程中）

從而導致ABean建立不出來，BBean也建立不出來。

這是迴圈依賴的場景，但是上文說了，在Spring中，通過某些機制幫開發者解決了部分迴圈依賴的問題，這個機制就是三級快取。

三級快取

三級快取是通用的叫法。

一級快取為：singletonObjects

二級快取為：earlySingletonObjects

三級快取為：singletonFactories

先稍微解釋一下這三個快取的作用，後面詳細分析：

singletonObjects中快取的是已經經歷了完整生命週期的bean物件。
earlySingletonObjects比singletonObjects多了一個early，表示快取的是早期的bean物件。早期是什麼意思？表示Bean的生命週期還沒走完就把這個Bean放入了earlySingletonObjects。
singletonFactories中快取的是ObjectFactory，表示物件工廠，用來建立某個物件的。

解決迴圈依賴思路分析
先來分析為什麼快取能解決迴圈依賴。

上文分析得到，之所以產生迴圈依賴的問題，主要是：

A建立時—>需要B---->B去建立—>需要A，從而產生了迴圈

征服阿里P7的Spring迴圈依賴原理解析，高薪offer唾手可得

那麼如何打破這個迴圈，加個中間人（快取）

征服阿里P7的Spring迴圈依賴原理解析，高薪offer唾手可得

A的Bean在建立過程中，在進行依賴注入之前，先把A的原始Bean放入快取（提早暴露，只要放到快取了，其他Bean需要時就可以從快取中拿了），放入快取後，再進行依賴注入，此時A的Bean依賴了B的Bean，如果B的Bean不存在，則需要建立B的Bean，而建立B的Bean的過程和A一樣，也是先建立一個B的原始物件，然後把B的原始物件提早暴露出來放入快取中，然後在對B的原始物件進行依賴注入A，此時能從快取中拿到A的原始物件（雖然是A的原始物件，還不是最終的Bean），B的原始物件依賴注入完了之後，B的生命週期結束，那麼A的生命週期也能結束。

因為整個過程中，都只有一個A原始物件，所以對於B而言，就算在屬性注入時，注入的是A原始物件，也沒有關係，因為A原始物件在後續的生命週期中在堆中沒有發生變化。

從上面這個分析過程中可以得出，只需要一個快取就能解決迴圈依賴了，那麼為什麼Spring中還需要singletonFactories呢？

這是難點，基於上面的場景想一個問題：如果A的原始物件注入給B的屬性之後，A的原始物件進行了AOP產生了一個代理物件，此時就會出現，對於A而言，它的Bean物件其實應該是AOP之後的代理物件，而B的a屬性對應的並不是AOP之後的代理物件，這就產生了衝突。

B依賴的A和最終的A不是同一個物件。

那麼如何解決這個問題？這個問題可以說沒有辦法解決。

因為在一個Bean的生命週期最後，Spring提供了BeanPostProcessor可以去對Bean進行加工，這個加工不僅僅只是能修改Bean的屬性值，也可以替換掉當前Bean。

舉個例子：

@Component
public class User {
}

@Component
public class LubanBeanPostProcessor implements BeanPostProcessor {
    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        // 注意這裡，生成了一個新的User物件
        if (beanName.equals("user")) {
            System.out.println(bean);
            User user = new User();
            return user;
        }
        return bean;
    }
}

public class Test {
    public static void main(String[] args) {
        AnnotationConfigApplicationContext context =                new AnnotationConfigApplicationContext(AppConfig.class);
                User user = context.getBean("user", User.class);
        System.out.println(user);    }}

執行main方法，得到的列印如下：

com.luban.service.User@5e025e70
com.luban.service.User@1b0375b3

所以在BeanPostProcessor中可以完全替換掉某個beanName對應的bean物件。

而BeanPostProcessor的執行在Bean的生命週期中是處於屬性注入之後的，迴圈依賴是發生在屬性注入過程中的，所以很有可能導致，注入給B物件的A物件和經歷過完整生命週期之後的A物件，不是一個物件。這就是有問題的。

所以在這種情況下的迴圈依賴，Spring是解決不了的，因為在屬性注入時，Spring也不知道A物件後續會經過哪些BeanPostProcessor以及會對A物件做什麼處理。

Spring到底解決了哪種情況下的迴圈依賴

雖然上面的情況可能發生，但是肯定發生得很少，我們通常在開發過程中，不會這樣去做，但是，某個beanName對應的最終物件和原始物件不是一個物件卻會經常出現，這就是AOP。

AOP就是通過一個BeanPostProcessor來實現的，這個BeanPostProcessor就是AnnotationAwareAspectJAutoProxyCreator，它的父類別是AbstractAutoProxyCreator，而在Spring中AOP利用的要麼是JDK動態代理，要麼CGLib的動態代理，所以如果給一個類中的某個方法設定了切面，那麼這個類最終就需要生成一個代理物件。

一般過程就是：A類—>生成一個普通物件–>屬性注入–>基於切面生成一個代理物件–>把代理物件放入singletonObjects單例池中。

而AOP可以說是Spring中除開IOC的另外一大功能，而回圈依賴又是屬於IOC範疇的，所以這兩大功能想要並存，Spring需要特殊處理。

如何處理的，就是利用了第三級快取singletonFactories。

首先，singletonFactories中存的是某個beanName對應的ObjectFactory，在bean的生命週期中，生成完原始物件之後，就會構造一個ObjectFactory存入singletonFactories中。這個ObjectFactory是一個函數式介面，所以支援Lambda表示式：() -> getEarlyBeanReference(beanName, mbd, bean)

上面的Lambda表示式就是一個ObjectFactory，執行該Lambda表示式就會去執行getEarlyBeanReference方法，而該方法如下：

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
    Object exposedObject = bean;
    if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
        for (BeanPostProcessor bp : getBeanPostProcessors()) {
            if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
                SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
                exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
            }        }    }    return exposedObject;
}

該方法會去執行SmartInstantiationAwareBeanPostProcessor中的getEarlyBeanReference方法，而這個介面下的實現類中只有兩個類實現了這個方法，一個是AbstractAutoProxyCreator，一個是InstantiationAwareBeanPostProcessorAdapter，它的實現如下：

// InstantiationAwareBeanPostProcessorAdapter
@Overridepublic Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {    return bean;
}

// AbstractAutoProxyCreator
@Overridepublic Object getEarlyBeanReference(Object bean, String beanName) {    Object cacheKey = getCacheKey(bean.getClass(), beanName);    this.earlyProxyReferences.put(cacheKey, bean);
    return wrapIfNecessary(bean, beanName, cacheKey);
}

所以很明顯，在整個Spring中，預設就只有AbstractAutoProxyCreator真正意義上實現了getEarlyBeanReference方法，而該類就是用來進行AOP的。上文提到的AnnotationAwareAspectJAutoProxyCreator的父類別就是AbstractAutoProxyCreator。

那麼getEarlyBeanReference方法到底在幹什麼？

首先得到一個cachekey，cachekey就是beanName。

然後把beanName和bean（這是原始物件）存入earlyProxyReferences中

呼叫wrapIfNecessary進行AOP，得到一個代理物件。

那麼，什麼時候會呼叫getEarlyBeanReference方法呢？回到迴圈依賴的場景中

征服阿里P7的Spring迴圈依賴原理解析，高薪offer唾手可得

左邊文字：

這個ObjectFactory就是上文說的labmda表示式，中間有getEarlyBeanReference方法，注意存入singletonFactories時並不會執行lambda表示式，也就是不會執行getEarlyBeanReference方法

右邊文字：

從singletonFactories根據beanName得到一個ObjectFactory，然後執行ObjectFactory，也就是執行getEarlyBeanReference方法，此時會得到一個A原始物件經過AOP之後的代理物件，然後把該代理物件放入earlySingletonObjects中，注意此時並沒有把代理物件放入singletonObjects中，那什麼時候放入到singletonObjects中呢？

我們這個時候得來理解一下earlySingletonObjects的作用，此時，我們只得到了A原始物件的代理物件，這個物件還不完整，因為A原始物件還沒有進行屬性填充，所以此時不能直接把A的代理物件放入singletonObjects中，所以只能把代理物件放入earlySingletonObjects，假設現在有其他物件依賴了A，那麼則可以從earlySingletonObjects中得到A原始物件的代理物件了，並且是A的同一個代理物件。

當B建立完了之後，A繼續進行生命週期，而A在完成屬性注入後，會按照它本身的邏輯去進行AOP，而此時我們知道A原始物件已經經歷過了AOP，所以對於A本身而言，不會再去進行AOP了，那麼怎麼判斷一個物件是否經歷過了AOP呢？會利用上文提到的earlyProxyReferences，在AbstractAutoProxyCreator的postProcessAfterInitialization方法中，會去判斷當前beanName是否在earlyProxyReferences，如果在則表示已經提前進行過AOP了，無需再次進行AOP。

對於A而言，進行了AOP的判斷後，以及BeanPostProcessor的執行之後，就需要把A對應的物件放入singletonObjects中了，但是我們知道，應該是要A的代理物件放入singletonObjects中，所以此時需要從earlySingletonObjects中得到代理物件，然後入singletonObjects中。

整個迴圈依賴解決完畢。

總結

至此，總結一下三級快取：

singletonObjects：快取某個beanName對應的經過了完整生命週期的bean
earlySingletonObjects：快取提前拿原始物件進行了AOP之後得到的代理物件，原始物件還沒有進行屬性注入和後續的BeanPostProcessor等生命週期
singletonFactories：快取的是一個ObjectFactory，主要用來去生成原始物件進行了AOP之後得到的代理物件，在每個Bean的生成過程中，都會提前暴露一個工廠，這個工廠可能用到，也可能用不到，如果沒有出現迴圈依賴依賴本bean，那麼這個工廠無用，本bean按照自己的生命週期執行，執行完後直接把本bean放入singletonObjects中即可，如果出現了迴圈依賴依賴了本bean，則另外那個bean執行 ObjectFactory提交得到一個AOP之後的代理物件(如果有AOP的話，如果無需AOP，則直接得到一個原始物件)。
其實還要一個快取，就是earlyProxyReferences，它用來記錄某個原始物件是否進行過AOP了。

哪裡不對的，或者有不同的理解的，歡迎評論裡面指出來，覺得有幫助的，可以點個贊支援一下
在這裡插入圖片描述