스프링 부트 프로젝트에서 @Async 주석 사용의 함정을 해결하는 방법

Background

얼마 전 한 동료가 자신의 프로젝트를 시작할 수 없다고 말하며 다른 사람을 돕는다는 마음으로 이 일을 해야 한다고 말했습니다.

그래서 그녀의 콘솔에서 다음과 같은 예외 정보를 발견했습니다.

스레드 "main" org.springframework.beans.factory.BeanCurrentlyInCreationException의 예외: 이름이 'AService'인 Bean을 만드는 중 오류 발생: 이름이 'AService'인 Bean이 되었습니다. 순환 참조의 일부로 원시 버전의 다른 Bean [BService]에 주입되었지만 결국에는 다른 Bean이 Bean의 최종 버전을 사용하지 않음을 의미합니다. 이는 종종 지나치게 열망하는 유형의 결과입니다. 일치 - 예를 들어 org.springframework.beans.factory.support.AbstractBeanFactory.lambda에서 beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:495)
을 끈 상태에서 'getBeanNamesOfType'을 사용하는 것을 고려해보세요. $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 주석은 @Async 주석을 처리하는 AsyncAnnotationBeanPostProcessor 클래스에 의해 구현됩니다. AsyncAnnotationBeanPostProcessor 클래스의 객체는 @EnableAsync 주석에 의해 Spring 컨테이너에 주입됩니다. 이것이 @Async 주석을 활성화하기 위해 @EnableAsync 주석을 사용해야 하는 근본적인 이유입니다.

AsyncAnnotationBeanPostProcessor

클래스 시스템

이 클래스는 BeanPostProcessor 인터페이스를 구현하고 상위 클래스 AbstractAdvisingBeanPostProcessor에 구현된 postProcessAfterInitialization 메소드를 구현합니다. 이는 AsyncAnnotationBeanPostProcessor가 Bean의 초기화 단계가 완료된 후에 호출된다는 것을 의미합니다. 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 for the 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 메소드가 Annotation된 클래스의 객체로 호출된다는 것입니다. @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 &#39;" + beanName + "&#39; 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 " +
                           "&#39;getBeanNamesOfType&#39; with the &#39;allowEagerInit&#39; 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);
    }
}

虽然这样设置能解决报错的问题，但是并不推荐，因为这样设置就允许早期注入的对象和最终创建出来的对象是不一样，并且可能会导致最终生成的对象没有被动态代理。

위 내용은 스프링 부트 프로젝트에서 @Async 주석 사용의 함정을 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!