征服阿里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的生成步驟如下：

1. Spring掃描class得到BeanDefinition
2. 根據得到的BeanDefinition去生成bean
3. 首先根據class推斷構造方法
4. 根據推斷出來的構造方法，反射，得到一個物件（暫時叫做原始物件）
5. 填充原始物件中的屬性（依賴注入）
6. 如果原始物件中的某個方法被AOP了，那么則需要根據原始物件生成一個代理物件
7. 把最終生成的代理物件放入單例池（原始碼中叫做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，從而產生了回圈

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

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方法呢？回到回圈依賴的場景中

左邊文字：

這個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中，

整個回圈依賴解決完畢，

總結

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

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

哪里不對的，或者有不同的理解的，歡迎評論里面指出來，覺得有幫助的，可以點個贊支持一下