Spring源碼分析（二）如何解決循環依賴

在上一篇Spring源碼分析中，咱們跳過了一部分關於Spring解決循環依賴部分的代碼，爲了填上這個坑，我這裏另開一文來好好討論下這個問題。

首先解釋下什麼是循環依賴，其實很簡單，就是有兩個類它們互相都依賴了對方，以下所示:

@Component
public class AService {

    @Autowired
    private BService bService;
}

@Component
public class BService {
    
    @Autowired
    private AService aService;
}

AService和BService顯然二者都在內部依賴了對方，單拎出來看彷彿看到了多線程中常見的死鎖代碼，但很顯然Spring解決了這個問題，否則咱們也不可能正常的使用它了。

所謂建立Bean實際上就是調用getBean() 方法，這個方法能夠在AbstractBeanFactory這個類裏面找到，這個方法一開始會調用getSingleton()方法。

// Eagerly check singleton cache for manually registered singletons.
Object sharedInstance = getSingleton(beanName);

這個方法的實現長得頗有意思，有着一堆if語句。

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
    Object singletonObject = this.singletonObjects.get(beanName);
    if (singletonObject == null && this.isSingletonCurrentlyInCreation(beanName)) {
        singletonObject = this.earlySingletonObjects.get(beanName);
        if (singletonObject == null && allowEarlyReference) {
            synchronized(this.singletonObjects) {
                singletonObject = this.singletonObjects.get(beanName);
                if (singletonObject == null) {
                    singletonObject = this.earlySingletonObjects.get(beanName);
                    if (singletonObject == null) {
                        ObjectFactory<?> singletonFactory = (ObjectFactory)this.singletonFactories.get(beanName);
                        if (singletonFactory != null) {
                            singletonObject = singletonFactory.getObject();
                               // 從三級緩存裏取出放到二級緩存中
                            this.earlySingletonObjects.put(beanName, singletonObject);
                            this.singletonFactories.remove(beanName);
                        }
                    }
                }
            }
        }
    }

    return singletonObject;
}

但這一坨if很好理解，就是一層層的去獲取這個bean，首先從singletonObjects中獲取，這裏面存放的是已經徹底建立好的單例Bean；若是取不到，那麼就往下走，去earlySingletonObjects裏面取，這個是早期曝光的對象；若是仍是沒有，那麼再去第三級緩存singletonFactories裏面獲取,它是提早暴露的對象工廠，這裏會從三級緩存裏取出後放到二級緩存中。那麼總的來講，Spring去獲取一個bean的時候，其實並非直接就從容器裏面取，而是先從緩存裏找，並且緩存一共有三級。那麼從這個方法返回的並不必定是咱們須要的bean，後面會調用getObjectForBeanInstance()方法去獲得實例化後的bean，這裏就很少說了。

但若是緩存裏面的確是取不到bean呢？那麼說明這個bean的確還未建立，須要去建立一個bean，這樣咱們就會去到前一篇生命週期中的建立bean的方法了。回顧下流程：實例化--屬性注入--初始化--銷燬。那麼咱們回到文章開頭的例子，有ServiceA和ServiceB兩個類。通常來講，Spring是按照天然順序去建立bean，那麼第一個要建立的是ServiceA。顯然一開始緩存裏是沒有的，咱們會來到建立bean的方法。首先進行實例化階段，咱們會來到第一個跟解決循環依賴有關的代碼，在實例化階段的代碼中就能夠找到。

// 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.isTraceEnabled()) {
      logger.trace("Eagerly caching bean '" + beanName +
            "' to allow for resolving potential circular references");
   }
   addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
}

首先看看第一行，earlySingletonExposure這個變量它會是什麼值？

它是有一個條件表達式返回的，一個個來看，首先，mbd.isSingleton()。咱們知道Spring默認的Bean的做用域都是單例的，所以這裏正常來講都是返回true沒問題。第二個，this.allowCircularReference，這個變量是標記是否容許循環引用，默認也是true。第三個，調用了一個方法,isSingletonCurrentlyInCreation(beanName)，進入該代碼能夠看出它是返回當前的bean是否是正常建立，顯然也是true。所以這個earlySingletonExposure返回的就是true。

接下來就進入了if語句的實現裏面了，也就是addSingletonFactory()這個方法。看到裏面的代碼中出現singletonFactories這個變量是否是很熟悉？翻到上面的getSingleton()就知道了，其實就是三級緩存，因此這個方法的做用是經過三級緩存提早暴露一個工廠對象。

/**
 * Add the given singleton factory for building the specified singleton
 * if necessary.
 * <p>To be called for eager registration of singletons, e.g. to be able to
 * resolve circular references.
 * @param beanName the name of the bean
 * @param singletonFactory the factory for the singleton object
 */
protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
   Assert.notNull(singletonFactory, "Singleton factory must not be null");
   synchronized (this.singletonObjects) {
      if (!this.singletonObjects.containsKey(beanName)) {
         this.singletonFactories.put(beanName, singletonFactory);
         this.earlySingletonObjects.remove(beanName);
         this.registeredSingletons.add(beanName);
      }
   }
}

接下來，回憶下上一章節說的實例化以後的步驟，就是屬性注入了。這就意味着ServiceA須要將ServiceB注入進去，那麼顯然又要調用getBean()方法去獲取ServiceB。ServiceB尚未建立，則也會進入這個createBean()方法，一樣也會來到這一步依賴注入。ServiceB中依賴了ServiceA，則會調用getBean()去獲取ServiceA。此時的獲取ServiceA可就不是再建立Bean了，而是從緩存中獲取。這個緩存就是上面getSingleton()這個方法裏面咱們看到的singletonFactory。那麼這個singletonFactory哪裏來的，就是這個addSingletonFactory()方法的第二個參數，即getEarlyBeanReference()方法。

/**
 * Obtain a reference for early access to the specified bean,
 * typically for the purpose of resolving a circular reference.
 * @param beanName the name of the bean (for error handling purposes)
 * @param mbd the merged bean definition for the bean
 * @param bean the raw bean instance
 * @return the object to expose as bean reference
 */
protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
   Object exposedObject = bean;
   if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
      for (SmartInstantiationAwareBeanPostProcessor bp : getBeanPostProcessorCache().smartInstantiationAware) {
         exposedObject = bp.getEarlyBeanReference(exposedObject, beanName);
      }
   }
   return exposedObject;
}

查看bp.getEarlyBeanReference(exposedObject, beanName)的實現，發現有兩個，一個是spring-beans下的SmartInstantiationAwareBeanPostProcessor，一個是spring-aop下的AbstractAutoProxyCreator。咱們在未使用AOP的狀況下，取的仍是第一種實現。

default Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
   return bean;
}

那麼使人驚訝的是，這方法直接返回了bean，也就是說若是不考慮AOP的話，這個方法啥都沒幹，就是把實例化建立的對象直接返回了。若是考慮AOP的話調用的是另外一個實現:

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

能夠看出，若是使用了AOP的話，這個方法返回的其實是bean的代理，並非它自己。那麼經過這部分咱們能夠認爲，在沒有使用AOP的狀況下，三級緩存是沒有什麼用的，所謂三級緩存實際上只是跟Spring的AOP有關的。

好了咱們如今是處於建立B的過程，但因爲B依賴A，因此調用了獲取A的方法，則A從三級緩存進入了二級緩存，獲得了A的代理對象。固然咱們不須要擔憂注入B的是A的代理對象會帶來什麼問題，由於生成代理類的內部都是持有一個目標類的引用，當調用代理對象的方法的時候，其實是會調用目標對象的方法的，因此因此代理對象是沒影響的。固然這裏也反應了咱們實際上從容器中要獲取的對象其實是代理對象而不是其自己。

那麼咱們再回到建立A的邏輯往下走，能看到後面實際上又調用了一次getSingleton()方法。傳入的allowEarlyReference爲false。

if (earlySingletonExposure) {
   Object earlySingletonReference = getSingleton(beanName, false);
   if (earlySingletonReference != null) {
      if (exposedObject == bean) {
         exposedObject = earlySingletonReference;
      }
      ...
   }
}

翻看上面的getSingleton()代碼能夠看出，allowEarlyReference爲false就至關於禁用三級緩存，代碼只會執行到經過二級緩存get。

singletonObject = this.earlySingletonObjects.get(beanName);

由於在前面咱們在建立往B中注入A的時候已經從三級緩存取出來放到二級緩存中了，因此這裏A能夠經過二級緩存去取。再往下就是生命週期後面的代碼了，就再也不繼續了。

那麼如今就會有個疑問，咱們爲何非要三級緩存，直接用二級緩存彷佛就足夠了？

看看上面getEarlyBeanReference()這個方法所在的類，它是SpringAOP自動代理的關鍵類，它實現了SmartInstantiationAwareBeanPostProcessor，也就是說它也是個後置處理器BeanPostProcessor，它有着自定義的初始化後的方法。

/**
 * Create a proxy with the configured interceptors if the bean is
 * identified as one to proxy by the subclass.
 * @see #getAdvicesAndAdvisorsForBean
 */
@Override
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
   if (bean != null) {
      Object cacheKey = getCacheKey(bean.getClass(), beanName);
      if (this.earlyProxyReferences.remove(cacheKey) != bean) {
         return wrapIfNecessary(bean, beanName, cacheKey);
      }
   }
   return bean;
}

很明顯它這裏是earlyProxyReferences緩存中找不到當前的bean的話就會去建立代理。也就是說SpringAOP但願在Bean初始化後進行建立代理。若是咱們只使用二級緩存，也就是在這個地方

addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));

直接調用getEarlyBeanReference()並將獲得的早期引用放入二級緩存。這就意味着不管bean之間是否存在互相依賴，只要建立bean走到這一步都得去建立代理對象了。然而Spring並不想這麼作，不信本身能夠動手debug一下，若是ServiceA和ServiceB之間沒有依賴關係的話，getEarlyBeanReference()這個方法壓根就不會執行。總的來講就是，若是不使用三級緩存直接使用二級緩存的話，會致使全部的Bean在實例化後就要完成AOP代理，這是沒有必要的。

最後咱們從新梳理下流程，記得Spring建立Bean的時候是按照天然順序的，因此A在前B在後：

咱們首先進行A的建立，但因爲依賴了B，因此開始建立B，一樣的，對B進行屬性注入的時候會要用到A，那麼就會經過getBean()去獲取A，A在實例化階段會提早將對象放入三級緩存中，若是沒有使用AOP，那麼本質上就是這個bean自己，不然是AOP代理後的代理對象。三級緩存singletonFactories會將其存放進去。那麼經過getBean()方法獲取A的時候，核心其實在於getSingleton()方法， 它會將其從三級緩存中取出，而後放到二級緩存中去。而最終B建立結束回到A初始化的時候，會再次調用一次getSingleton()方法，此時入參的allowEarlyReference爲false，所以是去二級緩存中取，獲得真正須要的bean或代理對象，最後A建立結束，流程結束。

因此Spring解決循環依賴的原理大體就講完了，但根據上述的結論，咱們能夠思考一個問題，什麼狀況的循環依賴是沒法解決的？

根據上面的流程圖，咱們知道，要解決循環依賴首先一個大前提是bean必須是單例的，基於這個前提咱們才值得繼續討論這個問題。而後根據上述總結，能夠知道，每一個bean都是要進行實例化的，也就是要執行構造器。因此能不能解決循環依賴問題其實跟依賴注入的方式有關。

依賴注入的方式有setter注入，構造器注入和Field方式。

Filed方式就是咱們平時用的最多的，屬性上加個@Autowired或者@Resource之類的註解，這個對解決循環依賴無影響；

若是A和B都是經過setter注入，顯然對於執行構造器沒有影響，因此不影響解決循環依賴；

若是A和B互相經過構造器注入，那麼執行構造器的時候也就是實例化的時候，A在本身還沒放入緩存的時候就去建立B了，那麼B也是拿不到A的，所以會出錯；

若是A中注入B的方式爲setter，B中注入A爲構造器，因爲A先實例化，執行構造器，並建立緩存，都沒有問題，繼續屬性注入，依賴了B而後走建立B的流程，獲取A也能夠從緩存裏面能取到，流程一路通暢。

若是A中注入B的方式爲構造器，B中注入A爲setter，那麼這個時候A先進入實例化方法，發現須要B，那麼就會去建立B，而A還沒放入三級緩存裏，B再建立的時候去獲取A就會獲取失敗。

好了，以上就是關於Spring解決循環依賴問題的全部內容，這個問題的答案我是好久以前就知道了，但真的只是知道答案，此次是本身看源碼加debug一點點看才知道爲啥是這個答案，雖然還作不到完全學的通透，但的確能對這個問題的理解的更爲深入一點，再接再礪吧。