大家好,我是三友。

背景

前段时间,一个同事小姐姐跟我说她的项目起不来了,让我帮忙看一下,本着助人为乐的精神,这个忙肯定要去帮。

于是,我在她的控制台发现了如下的异常信息:

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

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

如果觉得这篇文章对你有所帮助,还请帮忙点赞、在看、转发给更多的人,非常感谢!

往期热门文章推荐

扫码或者搜索关注公众号 三友的java日记 ,及时干货不错过,公众号致力于通过画图加上通俗易懂的语言讲解技术,让技术更加容易学习,回复 面试 即可获得一套面试真题。

@Async注解的坑,小心的更多相关文章

  1. springboot:使用异步注解@Async的那些坑

    springboot:使用异步注解@Async的那些坑 一.引言 在java后端开发中经常会碰到处理多个任务的情况,比如一个方法中要调用多个请求,然后把多个请求的结果合并后统一返回,一般情况下调用其他 ...

  2. spring-boot @Async注解 解决异步多线程入库的问题

    前言在开发过程中,我们会遇到很多使用线程池的业务场景,例如定时任务使用的就是ScheduledThreadPoolExecutor.而有些时候使用线程池的场景就是会将一些可以进行异步操作的业务放在线程 ...

  3. Spring中@Async注解实现“方法”的异步调用

    原文:http://www.cnblogs.com/zhengbin/p/6104502.html 简单介绍: Spring为任务调度与异步方法执行提供了注解支持.通过在方法上设置@Async注解,可 ...

  4. 异步任务spring @Async注解源码解析

    1.引子 开启异步任务使用方法: 1).方法上加@Async注解 2).启动类或者配置类上@EnableAsync 2.源码解析 虽然spring5已经出来了,但是我们还是使用的spring4,本文就 ...

  5. Spring里的Async注解实现异步操作

    异步执行一般用来发送一些消息数据,数据一致性不要求太高的场景,对于spring来说,它把这个异步进行了封装,使用一个注解就可以实现. 用法 程序启动时开启@EnableAsync注解 建立新的类型,建 ...

  6. SpringBoot @Async注解失效分析

    有时候在使用的过程中@Async注解会失效(原因和@Transactional注解有时候会失效的原因一样). 下面定义一个Service: 两个异步执行的方法test03()和test02()用来模拟 ...

  7. springboot中@EnableAsync与@Async注解使用

    springboot中@EnableAsync与@Async注解使用 @Async为异步注解,放到方法上,表示调用该方法的线程与此方法异步执行,需要配合@EnableAsync注解使用. 1.首先演示 ...

  8. Spring异步-@Async注解

    Spring异步:@Async注解 使用@Async前需要开启异步支持:@EnableAsync 注解和XML方式 @Async返回值的调用:需要使用Future包装 1.如果没有使用Future包装 ...

  9. Spring使用@Async注解

    本文讲述@Async注解,在Spring体系中的应用.本文仅说明@Async注解的应用规则,对于原理,调用逻辑,源码分析,暂不介绍.对于异步方法调用,从Spring3开始提供了@Async注解,该注解 ...

随机推荐

  1. Java 8的18个常用日期处理

    Java 8的18个常用日期处理 一.简介 伴随 lambda表达式.streams 以及一系列小优化,Java 8 推出了全新的日期时间API. Java处理日期.日历和时间的不足之处:将 java ...

  2. 一文带你速懂虚拟化KVM和XEN

    来源 :蛋蛋团 前言 "云计算"这个技术经过十余年的普及到如今已经可以称得上是家喻户晓了,基于云计算平台,在多个领域内创造了一个又一个的记录:电子商务里亿万人同时在线抢购的的&qu ...

  3. 小数据池,is和==的区别,id()

    小数据池 概念  存放数据缓存的地方 目的   节省内存,提高效率 什么数据会被缓存(什么数据会放在小数据池中)    数字  字符串    布尔 优点: 可以帮我们快速的创建对象.节省内存. 缺点: ...

  4. 电机噪声之谐波分析(内附simulink中FFT分析的相关参数配置与解析)

    电机噪声之谐波分析(内附simulink中FFT分析的相关参数配置与解析) 目录 电机噪声之谐波分析(内附simulink中FFT分析的相关参数配置与解析) 写在前面 正文 电机噪声 谐波的产生 什么 ...

  5. 我用13行摆烂了你的oj4

    13行代码AC oj4是怎么回事呢?13行代码AC oj4相信大家都很熟悉,但是13行代码AC oj4是怎么回事呢,下面就让小编带大家一起了解吧.13行代码AC oj4,其实就是13行代码AC oj4 ...

  6. 其实 Gradle Transform 就是个纸老虎 —— Gradle 系列(4)

    前言 目前,使用 AGP Transform API 进行字节码插桩已经非常普遍了,例如 Booster.神策等框架中都有 Transform 的影子.Transform 听起来很高大上,其本质就是一 ...

  7. 【多线程】创建线程方式一:继承Thread类

    创建线程方式一:继承Thread类 代码示例: /** * @Description 继承Thread类,重写run方法,调用start开启线程 * @Author hzx * @Date 2022- ...

  8. leetcode 3. Longest Substring Without Repeating Characters 无重复字符的最长子串

    一.题目大意 https://leetcode.cn/problems/longest-substring-without-repeating-characters/ 给定一个字符串 s ,请你找出其 ...

  9. 116_Power Pivot 先进先出原则库龄库存计算相关

    博客:www.jiaopengzi.com 焦棚子的文章目录 请点击下载附件 一背景 前面写过了一个关于进销存的案例,留一个话题就是先进先出的库存计算. 刚好有朋友提了相关这样的需求.先来看看效果. ...

  10. 论文解读(SCGC))《Simple Contrastive Graph Clustering》

    论文信息 论文标题:Simple Contrastive Graph Clustering论文作者:Yue Liu, Xihong Yang, Sihang Zhou, Xinwang Liu论文来源 ...