深度解析SpringBoot中@Async引起的循環依賴

啊,昨晚發版又出現瞭讓有頭大的循環依賴問題,按理說Spring會為我們解決循環依賴,但是為什麼還會出現這個問題呢?為什麼在本地、UAT以及PRE環境都沒有出現這個問題,但是到瞭PROD環境就出現瞭這個問題呢?本文將從事故時間線、及時止損、復盤分析等幾個方面為大傢帶來詳細的分析,幹貨滿滿!

事故時間線

本著"先止損、後復盤分析"的原則,我們來看一下這次發版事故的時間線。

2021年11月16日晚23點00分00秒開始發版,此時集團的devops有點慢

2021年11月16日晚23點03分01秒,收到發版失敗的消息,登錄服務器發現發生瞭循環依賴,具體錯誤如下圖,從日志中可以看到是dataCollectionSendMessageService這個bean出現瞭循環依賴

在這裡插入圖片描述

問題發現瞭就需要先解決,然後再去分析為什麼。看到這個報錯日志我心裡也大概知道是為什麼瞭,所以很快就解決瞭,解決方案如下:給DataCollectionSendMessageService加上@Lazy註解

在這裡插入圖片描述

2021年11月16日晚23點07分16秒,使用重新集成的代碼開始發版,大概10分鐘後線上節點全部發版完成。從時間線來看從發現問題到解決問題,前後一共用瞭接近15分鐘(這期間代碼集成和發佈用瞭過多的時間),也算是做到瞭及時止損,沒有讓問題繼續擴大。

猜想

我大膽的猜想是因為打瞭@Aysnc註解的bean生成瞭對象的代理,導致Spring bean最終加載的不是一個原始對象導致瞭此次問題的發生,那麼對不對呢,接下來我們通過源碼詳細分析一下。

什麼是循環依賴

所謂循環依賴就是Spring IOC容器在加載bean時會按照順序加載,先去實例化 beanA。然後發現 beanA 依賴於 beanB,接在又去實例化 beanB。實例化 beanB 時,發現 beanB 又依賴於 beanA。如果容器不處理循環依賴的話,容器會無限執行上面的流程,直到內存溢出,程序崩潰,所以這個時候就會拋出BeanCurrentlyInCreationException異常,也就是我們常說的循環依賴,下面是兩種常見循環依賴的場景。

幾個Bean之間的循環依賴

@Component
public class A {

    @Autowired
    private B b;
}

@Component
public class B {

    @Autowired
    private C c;
}

@Component
public class C {

    @Autowired
    private A a;
}

效果圖如下:

在這裡插入圖片描述

自己依賴自己

@Component
public class A {

    @Autowired
    private A a;
}

效果圖如下:

在這裡插入圖片描述

Spring是如何解決循環依賴的

在這裡插入圖片描述

首先Spring維護瞭三個Map,也就是我們通常說的三級緩存

  • singletonObjects:俗稱單例池,緩存創建完成的單例Bean
  • singletonFactories:映射創建Bean的原始工廠
  • earlySingletonObjects:映射Bean的早期引用,也就是說這個Map裡的Bean不是完整的,隻是完成瞭實例化,但還沒有初始化

Spring通過三級緩存解決瞭循環依賴,其中一級緩存為單例池(singletonObjects),二級緩存為早期曝光對象earlySingletonObjects,三級緩存為早期曝光對象工廠(singletonFactories)。

當A、B兩個類發生循環引用時,在A完成實例化後,就使用實例化後的對象去創建一個對象工廠,並添加到三級緩存中,如果A被AOP代理,那麼通過這個工廠獲取到的就是A代理後的對象,如果A沒有被AOP代理,那麼這個工廠獲取到的就是A實例化的對象

當A進行屬性註入時,會去創建B,同時B又依賴瞭A,所以創建B的同時又會去調用getBean(a)來獲取需要的依賴,此時的getBean(a)會從緩存中獲取,第一步,先獲取到三級緩存中的工廠;第二步,調用對象工工廠的getObject方法來獲取到對應的對象,得到這個對象後將其註入到B中。

緊接著B會走完它的生命周期流程,包括初始化、後置處理器等。當B創建完後,會將B再註入到A中,此時A再完成它的整個生命周期。至此,循環依賴結束!

簡單一句話說:先去緩存裡找Bean,沒有則實例化當前的Bean放到Map,如果有需要依賴當前Bean的,就能從Map取到。

什麼是@Async

@Async註解是Spring為我們提供的異步調用的註解,@Async可以作用到類或者方法上,標記瞭@Async註解的方法將會在獨立的線程中被執行,調用者無需等待它的完成,即可繼續其他的操作。從源碼中可以看到標記瞭@Async註解的方法會被提交到org.springframework.core.task.TaskExecutor中異步執行。

在這裡插入圖片描述

或者我們可以通過value來指定使用哪個自定義線程池,比如這樣子:

@Async("asyncTaskExecutor")

被@Async標記的bean註入時機

我們從源碼的角度來看一下被@Async標記的bean是如何註入到Spring容器裡的。在我們開啟@EnableAsync註解之後代表可以向Spring容器中註入AsyncAnnotationBeanPostProcessor,它是一個後置處理器,我們看一下他的類圖。

在這裡插入圖片描述

真正創建代理對象的代碼在AbstractAdvisingBeanPostProcessor中的postProcessAfterInitialization方法中,以下代碼有所刪減,隻保留核心邏輯代碼

	// 這個map用來緩存所有被postProcessAfterInitialization這個方法處理的bean
	private final Map<Class<?>, Boolean> eligibleBeans = new ConcurrentHashMap<>(256);

	// 這個方法主要是為打瞭@Async註解的bean生成代理對象
	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) {
		// 這裡是重點,這裡返回true
		if (isEligible(bean, beanName)) {
			// 工廠模式生成一個proxyFactory
			ProxyFactory proxyFactory = prepareProxyFactory(bean, beanName);
			if (!proxyFactory.isProxyTargetClass()) {
				evaluateProxyInterfaces(bean.getClass(), proxyFactory);
			}
			// 切入切面並創建一個代理對象
			proxyFactory.addAdvisor(this.advisor);
			customizeProxyFactory(proxyFactory);
			return proxyFactory.getProxy(getProxyClassLoader());
		}
		// No proxy needed.
		return bean;
	}
	protected boolean isEligible(Class<?> targetClass) {
		// 首次從eligibleBeans這個map中一定是拿不到的
		Boolean eligible = this.eligibleBeans.get(targetClass);
		if (eligible != null) {
			return eligible;
		}
		// 如果沒有advisor,也就是切面,直接返回false
		if (this.advisor == null) {
			return false;
		}
		// 這裡判斷AsyncAnnotationAdvisor能否切入,因為我們的bean是打瞭@Aysnc註解,這裡是一定能切入的,最終會返回true
		eligible = AopUtils.canApply(this.advisor, targetClass);
		this.eligibleBeans.put(targetClass, eligible);
		return eligible;
	}

至此打瞭@Aysnc註解的bean就創建完成瞭,結果是生成瞭一個代理對象

循環依賴到底是怎麼生成的

經過上面的源碼分析,我們可以知道有@Aysnc註解的bean最後生成瞭一個代理對象,我們結合Spring bean創建的流程來分析這次問題。

  • beanA開始初始化,beanA實例化完成後給beanA的依賴屬性beanB進行賦值
  • beanB開始初始化,beanB實例化完成後給beanB的依賴屬性beanA進行賦值
  • 因為beanA是支持循環依賴的,所以可以在earlySingletonObjects中可以拿到beanA的早期引用的,但是因為beanB打瞭@Aysnc註解並不能在earlySingletonObjects中可以拿到早期引用
  • 接下來執行執行initializeBean(Object existingBean, String beanName)方法,這裡beanA可以正常實例化完成,但是因為beanB打瞭@Aysnc註解,所以向Spring IOC容器中增加瞭一個代理對象,也就是說beanAbeanB並不是一個原始對象,而是一個代理對象
  • 接下來進行執行doCreateBean方法時對進行檢測,以下代碼有所刪減,隻保留核心邏輯代碼
protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
			throws BeanCreationException {

		if (earlySingletonExposure) {
			Object earlySingletonReference = getSingleton(beanName, false);
			if (earlySingletonReference != null) {
				if (exposedObject == bean) {
					exposedObject = earlySingletonReference;
				}
				else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
					String[] dependentBeans = getDependentBeans(beanName);
					Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
					// 重點在這裡,這裡會遍歷所有依賴的bean,如果beanA依賴beanB和緩存中的beanB不相等
					// 也就是說beanA本來依賴的是一個原始對象beanB,但是這個時候發現beanB是一個代理對象,就會增加到actualDependentBeans
					for (String dependentBean : dependentBeans) {
						if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
							actualDependentBeans.add(dependentBean);
						}
					}
					// 發現actualDependentBeans不為空,就發生瞭我們最開始截圖的錯誤
					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.");
					}
				}
			}
		}

		// Register bean as disposable.
		try {
			registerDisposableBeanIfNecessary(beanName, bean, mbd);
		}
		catch (BeanDefinitionValidationException ex) {
			throw new BeanCreationException(
					mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
		}

		return exposedObject;
	}

解決循環依賴的正確姿勢

  • @Lazy註解
  • 代碼優化,不要讓@Async的Bean參與循環依賴

至此我們就知道為什麼發生瞭此次問題。

到此這篇關於深度解析SpringBoot中@Async引起的循環依賴的文章就介紹到這瞭,更多相關SpringBoot中@Async循環依賴內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: