Spring源碼分析之循環依賴及解決方案

2020 年 11 月 16 日
筆記
spring

Spring源碼分析之循環依賴及解決方案

往期文章：

正文：

首先，我們需要明白什麼是循環依賴？簡單來說就是A對象創建過程中需要依賴B對象，而B對象創建過程中同樣也需要A對象，所以A創建時需要先去把B創建出來，但B創建時又要先把A創建出來…死循環有木有…

那麼在Spring中，有多少種循環依賴的情況呢？大部分人只知道兩個普通的Bean之間的循環依賴，而Spring中其實存在三種對象（普通Bean，工廠Bean，代理對象），他們之間都會存在循環依賴，這裡我給列舉出來，大致分別以下幾種：

普通Bean與普通Bean之間
普通Bean與代理對象之間
代理對象與代理對象之間
普通Bean與工廠Bean之間
工廠Bean與工廠Bean之間
工廠Bean與代理對象之間

那麼，在Spring中是如何解決這個問題的呢？

1. 普通Bean與普通Bean

首先，我們先設想一下，如果讓我們自己來編碼，我們會如何解決這個問題？

栗子

現在我們有兩個互相依賴的對象A和B

public class NormalBeanA {

	private NormalBeanB normalBeanB;

	public void setNormalBeanB(NormalBeanB normalBeanB) {
		this.normalBeanB = normalBeanB;
	}
}

public class NormalBeanB {

	private NormalBeanA normalBeanA;

	public void setNormalBeanA(NormalBeanA normalBeanA) {
		this.normalBeanA = normalBeanA;
	}
}

然後我們想要讓他們彼此都含有對象

public class Main {

	public static void main(String[] args) {
		// 先創建A對象
		NormalBeanA normalBeanA = new NormalBeanA();
		// 創建B對象
		NormalBeanB normalBeanB = new NormalBeanB();
		// 將A對象的引用賦給B
		normalBeanB.setNormalBeanA(normalBeanA);
		// 再將B賦給A
		normalBeanA.setNormalBeanB(normalBeanB);
	}
}

發現了嗎？我們並沒有先創建一個完整的A對象，而是先創建了一個空殼對象（Spring中稱為早期對象），將這個早期對象A先賦給了B，使得得到了一個完整的B對象，再將這個完整的B對象賦給A，從而解決了這個循環依賴問題，so easy!

那麼Spring中是不是也這樣做的呢？我們就來看看吧～

Spring中的解決方案

由於上一篇已經分析過Bean的創建過程了，其中的某些部分就不再細講了

先來到創建Bean的方法

AbstractAutowireCapableBeanFactory#doCreateBean

假設此時在創建A

protected Object doCreateBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args){
  // beanName -> A
  // 實例化A
  BeanWrapper instanceWrapper = createBeanInstance(beanName, mbd, args);
  // 是否允許暴露早期對象
  boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
                                    isSingletonCurrentlyInCreation(beanName));
  if (earlySingletonExposure) {
    // 將獲取早期對象的回調方法放到三級緩存中
    addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
  }
}

addSingletonFactory

protected void addSingletonFactory(String beanName, ObjectFactory<?> singletonFactory) {
		synchronized (this.singletonObjects) {
			// 單例緩存池中沒有該Bean
			if (!this.singletonObjects.containsKey(beanName)) {
				// 將回調函數放入三級緩存
				this.singletonFactories.put(beanName, singletonFactory);
				this.earlySingletonObjects.remove(beanName);
				this.registeredSingletons.add(beanName);
			}
		}
	}

ObjectFactory是一個函數式接口

在這裡，我們發現在創建Bean時，Spring不管三七二十一，直接將一個獲取早期對象的回調方法放進了一個三級緩存中，我們再來看一下回調方法的邏輯

getEarlyBeanReference

protected Object getEarlyBeanReference(String beanName, RootBeanDefinition mbd, Object bean) {
  Object exposedObject = bean;
  // 調用BeanPostProcessor對早期對象進行處理，在Spring的內置處理器中，並無相關的處理邏輯
  // 如果開啟了AOP，將引入一個AnnotationAwareAspectJAutoProxyCreator,此時將可能對Bean進行動態代理
  if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
    for (BeanPostProcessor bp : getBeanPostProcessors()) {
      if (bp instanceof SmartInstantiationAwareBeanPostProcessor) {
        SmartInstantiationAwareBeanPostProcessor ibp = (SmartInstantiationAwareBeanPostProcessor) bp;
        exposedObject = ibp.getEarlyBeanReference(exposedObject, beanName);
      }
    }
  }
  return exposedObject;
}

在這裡，如果沒有開啟AOP，或者該對象不需要動態代理，會直接返回原對象

此時，已經將A的早期對象緩存起來了，接下來在填充屬性時會發生什麼呢？

相信大家也應該想到了，A對象填充屬性時必然發現依賴了B對象，此時就將轉頭創建B，在創建B時同樣會經歷以上步驟，此時就該B對象填充屬性了，這時，又將要轉頭創建A，那麼，現在會有什麼不一樣的地方呢？我們看看getBean的邏輯吧

doGetBean

protected <T> T doGetBean(
			String name, @Nullable Class<T> requiredType, @Nullable Object[] args, boolean typeCheckOnly){
  // 此時beanName為A
  String beanName = transformedBeanName(name);
  // 嘗試從三級緩存中獲取bean,這裡很關鍵
  Object sharedInstance = getSingleton(beanName);
}

protected Object getSingleton(String beanName, boolean allowEarlyReference) {
  // 從單例緩存池中獲取，此時仍然是取不到的
  Object singletonObject = this.singletonObjects.get(beanName);
  // 獲取不到，判斷bean是否正在創建，沒錯，此時A確實正在創建
  if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
    // 由於現在仍然是在同一個線程，基於同步鎖的可重入性，此時不會阻塞
    synchronized (this.singletonObjects) {
      // 從早期對象緩存池中獲取，這裡是沒有的
      singletonObject = this.earlySingletonObjects.get(beanName);
      if (singletonObject == null && allowEarlyReference) {
        // 從三級緩存中獲取回調函數，此時就獲取到了我們在創建A時放入的回調函數
        ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
        if (singletonFactory != null) {
          // 調用回調方法獲取早期bean，由於我們現在討論的是普通對象，所以返回原對象
          singletonObject = singletonFactory.getObject();
          // 將早期對象放到二級緩存，移除三級緩存
          this.earlySingletonObjects.put(beanName, singletonObject);
          this.singletonFactories.remove(beanName);
        }
      }
    }
  }
  // 返回早期對象A
  return singletonObject;
}

震驚！此時我們就拿到了A的早期對象進行返回，所以B得以被填充屬性，B創建完畢後，又將返回到A填充屬性的過程，A也得以被填充屬性，A也創建完畢，這時，A和B都創建好了，循環依賴問題得以收場～

普通Bean和普通Bean之間的問題就到這裡了，不知道小夥伴們有沒有暈呢～

2. 普通Bean和代理對象

普通Bean和代理對象之間的循環依賴與兩個普通Bean的循環依賴其實大致相同，只不過是多了一次動態代理的過程，我們假設A對象是需要代理的對象，B對象仍然是一個普通對象，然後，我們開始創建A對象。

剛開始創建A的過程與上面的例子是一模一樣的，緊接着自然是需要創建B，然後B依賴了A，於是又倒回去創建A，此時，再次走到去緩存池獲取的過程。

// 從三級緩存中獲取回調函數
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
  // 調用回調方法獲取早期bean，此時返回的是一個A的代理對象
  singletonObject = singletonFactory.getObject();
  // 將早期對象放到二級緩存，移除三級緩存
  this.earlySingletonObjects.put(beanName, singletonObject);
  this.singletonFactories.remove(beanName);
}

這時就不太一樣了，在singletonFactory.getObject()時，由於此時A是需要代理的對象，在調用回調函數時，就會觸發動態代理的過程

AbstractAutoProxyCreator#getEarlyBeanReference

public Object getEarlyBeanReference(Object bean, String beanName) {
  // 生成一個緩存Key
  Object cacheKey = getCacheKey(bean.getClass(), beanName);
  // 放入緩存中，用於在初始化後調用該後置處理器時判斷是否進行動態代理過
  this.earlyProxyReferences.put(cacheKey, bean);
  // 將對象進行動態代理
  return wrapIfNecessary(bean, beanName, cacheKey);
}

此時，B在創建時填充的屬性就是A的代理對象了，B創建完畢，返回到A的創建過程，但此時的A仍然是一個普通對象，可B引用的A已經是個代理對象了，不知道小夥伴看到這裡有沒有迷惑呢？

不急，讓我們繼續往下走，填充完屬性自然是需要初始化的，在初始化後，會調用一次後置處理器，我們看看會不會有答案吧

初始化

protected Object initializeBean(String beanName, Object bean, @Nullable RootBeanDefinition mbd) {
	//...省略前面的步驟...
  // 調用初始化方法
  invokeInitMethods(beanName, wrappedBean, mbd);
  // 處理初始化後的bean
  wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
}

在處理初始化後的bean，又會調用動態代理的後置處理器了

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這個緩存可不就是我們在填充B的屬性，進而從緩存中獲取A時放進去的嗎？不信您往上翻到getEarlyBeanReference的步驟看看～

所以，此時並未進行任何處理，依舊返回了我們的原對象A，看來這裡並沒有我們要的答案，那就繼續吧～

// 是否允許暴露早期對象
if (earlySingletonExposure) {
  // 從緩存池中獲取早期對象
  Object earlySingletonReference = getSingleton(beanName, false);
  if (earlySingletonReference != null) {
    // bean為初始化前的對象，exposedObject為初始化後的對象
    // 判斷兩對象是否相等，基於上面的分析，這兩者是相等的
    if (exposedObject == bean) {
      // 將早期對象賦給exposedObject
      exposedObject = earlySingletonReference;
    }
  }
}

我們來分析一下上面的邏輯，getSingleton從緩存池中獲取早期對象返回的是什麼呢？

synchronized (this.singletonObjects) {
  // 從早期對象緩存池中獲取，此時就拿到了我們填充B屬性時放入的A的代理對象
  singletonObject = this.earlySingletonObjects.get(beanName);
  if (singletonObject == null && allowEarlyReference) {
    // 從三級緩存中獲取回調函數
    ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
    if (singletonFactory != null) {
      // 調用回調方法獲取早期bean
      singletonObject = singletonFactory.getObject();
      // 將早期對象放到二級緩存，移除三級緩存
      this.earlySingletonObjects.put(beanName, singletonObject);
      this.singletonFactories.remove(beanName);
    }
  }
}

發現了嗎？此時我們就獲取到了A的代理對象，然後我們又把這個對象賦給了exposedObject，此時創建對象的流程走完，我們得到的A不就是個代理對象了嗎～

此次栗子是先創建需要代理的對象A，假設我們先創建普通對象B會發生什麼呢？

3. 代理對象與代理對象

代理對象與代理對象的循環依賴是怎麼樣的呢？解決過程又是如何呢？這裡就留給小夥伴自己思考了，其實和普通Bean與代理對象是一模一樣的，小夥伴想想是不是呢，這裡我就不做分析了。

4. 普通Bean與工廠Bean

這裡所說的普通Bean與工廠Bean並非指bean與FactoryBean，這將毫無意義，而是指普通Bean與FactoryBean的getObject方法產生了循環依賴，因為FactoryBean最終產生的對象是由getObject方法所產出。我們先來看看栗子吧～

假設工廠對象A依賴普通對象B，普通對象B依賴普通對象A。

小夥伴看到這裡就可能問了，誒～你這不對呀，怎麼成了「普通對象B依賴普通對象A」呢？不應該是工廠對象A嗎？是這樣的，在Spring中，由於普通對象A是由工廠對象A產生，所有在普通對象B想要獲取普通對象A時，其實最終尋找調用的是工廠對象A的getObject方法，所以只要普通對象B依賴普通對象A就可以了，Spring會自動幫我們把普通對象B和工廠對象A聯繫在一起。

小夥伴，哦～

普通對象A

public class NormalBeanA {

	private NormalBeanB normalBeanB;

	public void setNormalBeanB(NormalBeanB normalBeanB) {
		this.normalBeanB = normalBeanB;
	}
}

工廠對象A

@Component
public class FactoryBeanA implements FactoryBean<NormalBeanA> {
	@Autowired
	private ApplicationContext context;

	@Override
	public NormalBeanA getObject() throws Exception {
		NormalBeanA normalBeanA = new NormalBeanA();
		NormalBeanB normalBeanB = context.getBean("normalBeanB", NormalBeanB.class);
		normalBeanA.setNormalBeanB(normalBeanB);
		return normalBeanA;
	}

	@Override
	public Class<?> getObjectType() {
		return NormalBeanA.class;
	}
}

普通對象B

@Component
public class NormalBeanB {
	@Autowired
	private NormalBeanA normalBeanA;
}

假設我們先創建對象A

由於FactoryBean和Bean的創建過程是一樣的，只是多了步getObject，所以我們直接定位到調用getObject入口

if (mbd.isSingleton()) {
  // 開始創建bean
  sharedInstance = getSingleton(beanName, () -> {
    // 創建bean
    return createBean(beanName, mbd, args);
  });
  // 處理FactoryBean
  bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
}

protected Object getObjectForBeanInstance(
			Object beanInstance, String name, String beanName, @Nullable RootBeanDefinition mbd) {
	// 先嘗試從緩存中獲取，保證多次從工廠bean獲取的bean是同一個bean
  object = getCachedObjectForFactoryBean(beanName);
  if (object == null) {
    // 從FactoryBean獲取對象
    object = getObjectFromFactoryBean(factory, beanName, !synthetic);
  }
}

protected Object getObjectFromFactoryBean(FactoryBean<?> factory, String beanName, boolean shouldPostProcess) {
	// 加鎖，防止多線程時重複創建bean
  synchronized (getSingletonMutex()) {
    // 這裡是Double Check
    Object object = this.factoryBeanObjectCache.get(beanName);
    if (object == null) {
      // 獲取bean，調用factoryBean的getObject()
      object = doGetObjectFromFactoryBean(factory, beanName);
    }
    // 又從緩存中取了一次，why? 我們慢慢分析
    Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
    if (alreadyThere != null) {
      object = alreadyThere;
    }else{
      // ...省略初始化bean的邏輯...
      // 將獲取到的bean放入緩存
      this.factoryBeanObjectCache.put(beanName, object);
    }
  }
}

private Object doGetObjectFromFactoryBean(FactoryBean<?> factory, String beanName){
  return factory.getObject();
}

現在，就走到了我們自定義的getObject方法，由於我們調用了context.getBean("normalBeanB", NormalBeanB.class)，此時，將會去創建B對象，在創建過程中，先將B的早期對象放入三級緩存，緊接着填充屬性，發現依賴了A對象，又要倒回來創建A對象，從而又回到上面的邏輯，再次調用我們自定義的getObject方法，這個時候會發生什麼呢？

又要去創建B對象…(Spring:心好累)

但是！此時我們在創建B時，是直接通過getBean在緩存中獲取到了B的早期對象，得以返回了！於是我們自定義的getObject調用成功，返回了一個完整的A對象！

但是此時FactoryBean的緩衝中還是什麼都沒有的。

// 又從緩存中取了一次
Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
if (alreadyThere != null) {
  object = alreadyThere;
}

這一次取alreadyThere必然是null，流程繼續執行，將此時將獲取到的bean放入緩存

this.factoryBeanObjectCache.put(beanName, object);

從FactoryBean獲取對象的流程結束，返回到創建B的過程中，B對象此時的屬性也得以填充，再返回到第一次創建A的過程，也就是我們第一次調用自定義的getObject方法，調用完畢，返回到這裡

// 獲取bean，調用factoryBean的getObject()
object = doGetObjectFromFactoryBean(factory, beanName);
Object alreadyThere = this.factoryBeanObjectCache.get(beanName);
if (alreadyThere != null) {
  object = alreadyThere;

那麼，此時this.factoryBeanObjectCache.get(beanName)能從緩衝中拿到對象了嗎？有沒有發現，拿到了剛剛B對象填充屬性時再次創建A對象放進去的！

所以，明白這裡為什麼要再次從緩存中獲取了吧？就是為了解決由於循環依賴時調用了兩次自定義的getObject方法，從而創建了兩個不相同的A對象，保證我們返回出去的A對象唯一！

怕小夥伴暈了，畫個圖給大家

5. 工廠Bean與工廠Bean之間

我們已經舉例4種循環依賴的栗子，Spring都有所解決，那麼有沒有Spring也無法解決的循環依賴問題呢？

有的！就是這個FactoryBean與FactoryBean的循環依賴！

假設工廠對象A依賴工廠對象B，工廠對象B依賴工廠對象A，那麼，這次的栗子會是什麼樣呢？

普通對象

public class NormalBeanA {

	private NormalBeanB normalBeanB;

	public void setNormalBeanB(NormalBeanB normalBeanB) {
		this.normalBeanB = normalBeanB;
	}
}

public class NormalBeanB {

	private NormalBeanA normalBeanA;

	public void setNormalBeanA(NormalBeanA normalBeanA) {
		this.normalBeanA = normalBeanA;
	}
}

工廠對象

@Component
public class FactoryBeanA implements FactoryBean<NormalBeanA> {
	@Autowired
	private ApplicationContext context;

	@Override
	public NormalBeanA getObject() throws Exception {
		NormalBeanA normalBeanA = new NormalBeanA();
		NormalBeanB normalBeanB = context.getBean("factoryBeanB", NormalBeanB.class);
		normalBeanA.setNormalBeanB(normalBeanB);
		return normalBeanA;
	}

	@Override
	public Class<?> getObjectType() {
		return NormalBeanA.class;
	}
}

@Component
public class FactoryBeanB implements FactoryBean<NormalBeanB> {
	@Autowired
	private ApplicationContext context;
	@Override
	public NormalBeanB getObject() throws Exception {
		NormalBeanB normalBeanB = new NormalBeanB();
		NormalBeanA normalBeanA = context.getBean("factoryBeanA", NormalBeanA.class);
		normalBeanB.setNormalBeanA(normalBeanA);
		return normalBeanB;
	}

	@Override
	public Class<?> getObjectType() {
		return NormalBeanB.class;
	}
}

首先，我們開始創建對象A，此時為調用工廠對象A的getObject方法，轉而去獲取對象B，便會走到工廠對象B的getObject方法，然後又去獲取對象A，又將調用工廠對象A的getObject，再次去獲取對象B，於是再次走到工廠對象B的getObject方法……此時，已經歷了一輪循環，卻沒有跳出循環的跡象，妥妥的死循環了。

我們畫個圖吧～

沒錯！這個圖就是這麼簡單，由於始終無法創建出一個對象，不管是早期對象或者完整對象，使得兩個工廠對象反覆的去獲取對方，導致陷入了死循環。

那麼，我們是否有辦法解決這個問題呢？

我的答案是無法解決，如果有想法的小夥伴也可以自己想一想哦～

我們發現，在發生循環依賴時，只要循環鏈中的某一個點可以先創建出一個早期對象，那麼在下一次循環時，就會使得我們能夠獲取到早期對象從而跳出循環！

而由於工廠對象與工廠對象間是無法創建出這個早期對象的，無法滿足跳出循環的條件，導致變成了死循環。

那麼此時Spring中會拋出一個什麼樣的異常呢？

當然是棧溢出異常啦！兩個工廠對象一直相互調用，不斷開闢棧幀，可不就是棧溢出有木有～

6. 工廠對象與代理對象

上面的情況是無法解決循環依賴的，那麼這個情況可以解決嗎？

答案是可以的！

我們分析了，一個循環鏈是否能夠得到終止，關鍵在於是否能夠在某個點創建出一個早期對象（臨時對象），而代理對象在doCreateBean時，是會生成一個早期對象放入三級緩存的，於是該循環鏈得以終結。

具體過程我這裡就不再細分析了，就交由小夥伴自己動手吧～

總結

以上我們一共舉例了6種情況，通過分析，總結出這樣一條定律：

在發生循環依賴時，判斷一個循環鏈是否能夠得到終止，關鍵在於是否能夠在某個點創建出一個早期對象（臨時對象），那麼在下一次循環時，我們就能通過該早期對象進而跳出（打破）循環！

通過這樣的定律，我們得出工廠Bean與工廠Bean之間是無法解決循環依賴的，那麼還有其他情況無法解決循環依賴嗎？

有的！以上的例子舉的都是單例的對象，並且都是通過set方法形成的循環依賴。

假使我們是由於構造方法形成的循環依賴呢？是否有解決辦法嗎？

沒有，因為這並不滿足我們得出的定律

無法執行完畢構造方法，自然無法創建出一個早期對象。

假使我們的對象是多例的呢？

也不能，因為多例的對象在每次創建時都是創建新的對象，即使能夠創建出早期對象，也不能為下一次循環所用！

好了，本文就到這裡結束了，希望小夥伴們有所收穫～

Spring IOC的核心部分到此篇就結束了，下一篇就讓我們進行AOP之旅吧～

下文預告：Spring源碼分析之AOP從解析到調用

Spring 源碼系列

Spring源碼分析之 IOC 容器預啟動流程(已完結)
Spring源碼分析之BeanFactory體系結構(已完結)
Spring源碼分析之BeanFactoryPostProcessor調用過程(已完結)
Spring源碼分析之Bean的創建過程(已完結)
Spring源碼分析之什麼是循環依賴及解決方案
Spring源碼分析之AOP從解析到調用
Spring源碼分析之事務管理(上)，事物管理是spring作為容器的一個特點，總結一下他的基本實現與原理吧
Spring源碼分析之事務管理(下) ，關於他的底層事物隔離與事物傳播原理，重點分析一下

Spring Mvc 源碼系列

SpringMvc體系結構
SpringMvc源碼分析之Handler解析過程
SpringMvc源碼分析之請求鏈過程

另外筆者公眾號：奇客時間，有更多精彩的文章，有興趣的同學，可以關注

Tags: spring