spring?boot項目使用@Async注解的坑怎么解決

今天小編給大家分享一下spring boot項目使用@Async注解的坑怎么解決的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

背景

前段時間，一個同事小姐姐跟我說她的項目起不來了，讓我幫忙看一下，本著助人為樂的精神，這個忙肯定要去幫。

于是，我在她的控制臺發現了如下的異常信息：

Exception in thread "main" org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'AService': Bean with name 'AService' has been injected into other beans [BService] 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.
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:602)
 at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
 at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:317)
 at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)

看到BeanCurrentlyInCreationException這個異常，我的第一反應是出現了循環依賴的問題。但是仔細一想，Spring不是已經解決了循環依賴的問題么，怎么還報這個錯。于是，我就詢問小姐姐改了什么東西，她說在方法上加了@Async注解。

這里我模擬一下當時的代碼，AService 和 BService 相互引用，AService的 save() 方法加了 @Async 注解。

@Component
public class AService {
    @Resource
    private BService bService;
    @Async
    public void save() {
    }
}
@Component
public class BService {
    @Resource
    private AService aService;
}

也就是這段代碼會報BeanCurrentlyInCreationException異常，難道是@Async注解遇上循環依賴的時候，Spring無法解決？為了驗證這個猜想，我將@Async注解去掉之后，再次啟動項目，項目成功起來了。于是基本可以得出結論，那就是@Async注解遇上循環依賴的時候，Spring的確無法解決。

雖然問題的原因已經找到了，但是又引出以下幾個問題：

• @Async注解是如何起作用的？

• 為什么@Async注解遇上循環依賴，Spring無法解決？

• 出現循環依賴異常之后如何解決？

@Async注解是如何起作用的？

@Async注解起作用是靠AsyncAnnotationBeanPostProcessor這個類實現的，這個類會處理@Async注解。AsyncAnnotationBeanPostProcessor這個類的對象是由@EnableAsync注解放入到Spring容器的，這也是為什么需要使用@EnableAsync注解來激活讓@Async注解起作用的根本原因。

AsyncAnnotationBeanPostProcessor

類體系

這個類實現了 BeanPostProcessor 接口，實現了 postProcessAfterInitialization 方法，是在其父類AbstractAdvisingBeanPostProcessor 中實現的，也就是說當Bean的初始化階段完成之后會回調 AsyncAnnotationBeanPostProcessor 的 postProcessAfterInitialization 方法。之所以會回調，是因為在Bean的生命周期中，當Bean初始化完成之后，會回調所有的 BeanPostProcessor 的 postProcessAfterInitialization 方法，代碼如下：

@Override
public Object applyBeanPostProcessorsAfterInitialization(Object existingBean, String beanName)throws BeansException {
    Object result = existingBean;
    for (BeanPostProcessor processor : getBeanPostProcessors()) {
         Object current = processor.postProcessAfterInitialization(result, beanName);
         if (current == null) {
            return result;
         }
         result = current;
     }
    return result;
}

AsyncAnnotationBeanPostProcessor 對于 postProcessAfterInitialization 方法實現：

@Override
public Object postProcessAfterInitialization(Object bean, String beanName) {
    if (this.advisor == null || bean instanceof AopInfrastructureBean) {
   // Ignore AOP infrastructure such as scoped proxies.
        return bean;
    }
    if (bean instanceof Advised) {
       Advised advised = (Advised) bean;
       if (!advised.isFrozen() && isEligible(AopUtils.getTargetClass(bean))) {
           // Add our local Advisor to the existing proxy's Advisor chain...
           if (this.beforeExistingAdvisors) {
              advised.addAdvisor(0, this.advisor);
           }
           else {
              advised.addAdvisor(this.advisor);
           }
           return bean;
        }
     }
     if (isEligible(bean, beanName)) {
        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;
}

該方法的主要作用是用來對方法入參的對象進行動態代理的，當入參的對象的類加了@Async注解，那么這個方法就會對這個對象進行動態代理，最后會返回入參對象的代理對象出去。至于如何判斷方法有沒有加@Async注解，是靠 isEligible(bean, beanName) 來判斷的。由于這段代碼牽扯到動態代理底層的知識，這里就不詳細展開了。

AsyncAnnotationBeanPostProcessor作用

綜上所述，可以得出一個結論，那就是當Bean創建過程中初始化階段完成之后，會調用 AsyncAnnotationBeanPostProcessor 的 postProcessAfterInitialization 的方法，對加了@Async注解的類的對象進行動態代理，然后返回一個代理對象回去。

雖然這里我們得出@Async注解的作用是依靠動態代理實現的，但是這里其實又引發了另一個問題，那就是事務注解@Transactional又或者是自定義的AOP切面，他們也都是通過動態代理實現的，為什么使用這些的時候，沒見拋出循環依賴的異常？難道他們的實現跟@Async注解的實現不一樣？不錯，還真的不太一樣，請繼續往下看。

AOP是如何實現的？

我們都知道AOP是依靠動態代理實現的，而且是在Bean的生命周期中起作用，具體是靠 AnnotationAwareAspectJAutoProxyCreator 這個類實現的，這個類會在Bean的生命周期中去處理切面，事務注解，然后生成動態代理。這個類的對象在容器啟動的時候，就會被自動注入到Spring容器中。

AnnotationAwareAspectJAutoProxyCreator 也實現了BeanPostProcessor，也實現了 postProcessAfterInitialization 方法。

@Override
public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) throws BeansException {
    if (bean != null) {
       Object cacheKey = getCacheKey(bean.getClass(), beanName);
       if (!this.earlyProxyReferences.contains(cacheKey)) {
           //生成動態代理，如果需要被代理的話
           return wrapIfNecessary(bean, beanName, cacheKey);
       }
     }
    return bean;
}

通過 wrapIfNecessary 方法就會對Bean進行動態代理，如果你的Bean需要被動態代理的話。

AnnotationAwareAspectJAutoProxyCreator作用

也就說，AOP和@Async注解雖然底層都是動態代理，但是具體實現的類是不一樣的。一般的AOP或者事務的動態代理是依靠 AnnotationAwareAspectJAutoProxyCreator 實現的，而@Async是依靠 AsyncAnnotationBeanPostProcessor 實現的，并且都是在初始化完成之后起作用，這也就是@Async注解和AOP之間的主要區別，也就是處理的類不一樣。

Spring是如何解決循環依賴的

Spring在解決循環依賴的時候，是依靠三級緩存來實現的。我曾經寫過一篇關于三級緩存的文章，如果有不清楚的小伙伴可以 關注微信公眾號 三友的java日記，回復 循環依賴 即可獲取原文鏈接，本文也算是這篇三級緩存文章的續作。

簡單來說，通過緩存正在創建的對象對應的ObjectFactory對象，可以獲取到正在創建的對象的早期引用的對象，當出現循環依賴的時候，由于對象沒創建完，就可以通過獲取早期引用的對象注入就行了。

而緩存ObjectFactory代碼如下：

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

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);
       }
    }
}

所以緩存的ObjectFactory對象其實是一個lamda表達式，真正獲取早期暴露的引用對象其實就是通過 getEarlyBeanReference 方法來實現的。

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;
}

getEarlyBeanReference 實現是調用所有的 SmartInstantiationAwareBeanPostProcessor 的 getEarlyBeanReference 方法。

而前面提到的 AnnotationAwareAspectJAutoProxyCreator 這個類就實現了 SmartInstantiationAwareBeanPostProcessor 接口，是在父類中實現的：

@Override
public Object getEarlyBeanReference(Object bean, String beanName) throws BeansException {
    Object cacheKey = getCacheKey(bean.getClass(), beanName);
    if (!this.earlyProxyReferences.contains(cacheKey)) {
        this.earlyProxyReferences.add(cacheKey);
    }
    return wrapIfNecessary(bean, beanName, cacheKey);
}

這個方法最后會調用 wrapIfNecessary 方法，前面也說過，這個方法是獲取動態代理的方法，如果需要的話就會代理，比如事務注解又或者是自定義的AOP切面，在早期暴露的時候，就會完成動態代理。

這下終于弄清楚了，早期暴露出去的原來可能是個代理對象，而且最終是通過AnnotationAwareAspectJAutoProxyCreator這個類的getEarlyBeanReference方法獲取的。

但是AsyncAnnotationBeanPostProcessor并沒有實現SmartInstantiationAwareBeanPostProcessor，也就是在獲取早期對象這一階段，并不會調AsyncAnnotationBeanPostProcessor處理@Async注解。

為什么@Async注解遇上循環依賴，Spring無法解決？

這里我們就拿前面的例子來說，AService加了@Async注解，AService先創建，發現引用了BService，那么BService就會去創建，當Service創建的過程中發現引用了AService，那么就會通過AnnotationAwareAspectJAutoProxyCreator 這個類實現的 getEarlyBeanReference 方法獲取AService的早期引用對象，此時這個早期引用對象可能會被代理，取決于AService是否需要被代理，但是一定不是處理@Async注解的代理，原因前面也說過。

于是BService創建好之后，注入給了AService，那么AService會繼續往下處理，前面說過，當初始化階段完成之后，會調用所有的BeanPostProcessor的實現的 postProcessAfterInitialization 方法。于是就會回調依次回調 AnnotationAwareAspectJAutoProxyCreator 和 AsyncAnnotationBeanPostProcessor 的 postProcessAfterInitialization 方法實現。

這段回調有兩個細節：

• AnnotationAwareAspectJAutoProxyCreator 先執行，AsyncAnnotationBeanPostProcessor 后執行，因為 AnnotationAwareAspectJAutoProxyCreator 在前面。

• AnnotationAwareAspectJAutoProxyCreator處理的結果會當入參傳遞給 AsyncAnnotationBeanPostProcessor，applyBeanPostProcessorsAfterInitialization方法就是這么實現的

AnnotationAwareAspectJAutoProxyCreator回調：會發現AService對象已經被早期引用了，什么都不處理，直接把對象AService給返回

AsyncAnnotationBeanPostProcessor回調：發現AService類中加了@Async注解，那么就會對AnnotationAwareAspectJAutoProxyCreator返回的對象進行動態代理，然后返回了動態代理對象。

這段回調完，是不是已經發現了問題。早期暴露出去的對象，可能是AService本身或者是AService的代理對象，而且是通過AnnotationAwareAspectJAutoProxyCreator對象實現的，但是通過AsyncAnnotationBeanPostProcessor的回調，會對AService對象進行動態代理，這就導致AService早期暴露出去的對象跟最后完全創造出來的對象不是同一個，那么肯定就不對了。

同一個Bean在一個Spring中怎么能存在兩個不同的對象呢，于是就會拋出BeanCurrentlyInCreationException異常，這段判斷邏輯的代碼如下：

if (earlySingletonExposure) {
  // 獲取到早期暴露出去的對象
  Object earlySingletonReference = getSingleton(beanName, false);
  if (earlySingletonReference != null) {
      // 早期暴露的對象不為null，說明出現了循環依賴
      if (exposedObject == bean) {
          // 這個判斷的意思就是指 postProcessAfterInitialization 回調沒有進行動態代理，如果沒有那么就將早期暴露出去的對象賦值給最終暴露（生成）出去的對象，
          // 這樣就實現了早期暴露出去的對象和最終生成的對象是同一個了
          // 但是一旦 postProcessAfterInitialization 回調生成了動態代理 ，那么就不會走這，也就是加了@Aysnc注解，是不會走這的
          exposedObject = earlySingletonReference;
      }
      else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
               // allowRawInjectionDespiteWrapping 默認是false
               String[] dependentBeans = getDependentBeans(beanName);
               Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
               for (String dependentBean : dependentBeans) {
                   if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
                       actualDependentBeans.add(dependentBean);
                  }
               }
               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.");
               }
      }
   }
}

所以，之所以@Async注解遇上循環依賴，Spring無法解決，是因為@Aysnc注解會使得最終創建出來的Bean，跟早期暴露出去的Bean不是同一個對象，所以就會報錯。

出現循環依賴異常之后如何解決？

解決這個問題的方法很多

1、調整對象間的依賴關系，從根本上杜絕循環依賴，沒有循環依賴，就沒有早期暴露這么一說，那么就不會出現問題

2、不使用@Async注解，可以自己通過線程池實現異步，這樣沒有@Async注解，就不會在最后生成代理對象，導致早期暴露的出去的對象不一樣

3、可以在循環依賴注入的字段上加@Lazy注解

@Component
public class AService {
    @Resource
    @Lazy
    private BService bService;
    @Async
    public void save() {
    }
}

4、從上面的那段判斷拋異常的源碼注釋可以看出，當allowRawInjectionDespiteWrapping為true的時候，就不會走那個else if，也就不會拋出異常，所以可以通過將allowRawInjectionDespiteWrapping設置成true來解決報錯的問題，代碼如下:

@Component
public class MyBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        ((DefaultListableBeanFactory) beanFactory).setAllowRawInjectionDespiteWrapping(true);
    }
}

雖然這樣設置能解決報錯的問題，但是并不推薦，因為這樣設置就允許早期注入的對象和最終創建出來的對象是不一樣，并且可能會導致最終生成的對象沒有被動態代理。

以上就是“spring boot項目使用@Async注解的坑怎么解決”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。