Java @Async注解导致spring启动失败解决方案 Java @Async注解导致spring启动失败解决方案详解

软件发布|下载排行|最新软件

当前位置:首页IT学院IT技术

Java @Async注解导致spring启动失败解决方案 Java @Async注解导致spring启动失败解决方案详解

liangsheng_g   2021-08-31 我要评论
想了解Java @Async注解导致spring启动失败解决方案详解的相关内容吗,liangsheng_g在本文为您仔细讲解Java @Async注解导致spring启动失败解决方案的相关知识和一些Code实例,欢迎阅读和指正,我们先划重点:Java,@Async注解导致启动失败,Java,@Async注解导致spring启动失败,下面大家一起来学习吧。

前言

在这篇文章里,最后总结处,我说了会讲讲循环依赖中,其中一个类添加@Async有可能会导致注入失败而抛异常的情况,今天就分析一下。

一、异常表现,抛出内容

1.1循环依赖的两个class

1.CycleService1

@Service
public class CycleService1 {

	@Autowired
	private CycleService2 cycleService2;

	@WangAnno
	@Async
	public void doThings() {
		System.out.println("it's a async move");
	}

}

2.CycleService2

@Service
public class CycleService2 {

	private CycleService1 cycleService1;

	public void init() {

	}

	@WangAnno
	public void alsoDo() {
		System.out.println("create cycleService2");
	}

}

1.2 启动报错

Bean with name ‘cycleService1' has been injected into other beans [cycleService2] 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.

警告: Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'cycleService1': Bean with name 'cycleService1' has been injected into other beans [cycleService2] 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.

Exception in thread "main" org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'cycleService1': Bean with name 'cycleService1' has been injected into other beans [cycleService2] 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:654)

at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:523)

at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)

at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:226)

at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:320)

at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:199)

at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:851)

at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:884)

at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:552)

at com.wang.Test.main(Test.java:109)

二、原因分析

2.1 主要原因

想想我在这篇博客里的图解步骤:

  1. 当Spring在进行bean的实例化的时候,由于CycleService1和CycleService2是循环依赖的,
  2. 同时,由于CycleService1创建早于CycleService2。
  3. 所以,在CycleService1对CycleService2的initializeBean方法执行之后得到了exposedObject,要从二级缓存里获取CycleService1的earlySingletonReference不为null,就需要比较exposedObject和raw CycleService是否还是同一个对象,如果不再是同一个对象,那么就会报错。
  4. 为什么有这个逻辑呢?
  5. 其实是因为如果能从二级缓存里拿出的earlySingletonReference不为null,说明了在该对象再创建过程中被其他对象循环依赖了,且调用了三级工厂中该对象的ObjectFactory方法,基于raw bean生成了对象放入到了二级缓存。但是当raw bean执行完initializeBean之后生成了新的对象,那就出问题了。如下图:

在这里插入图片描述

也就是说基于raw bean,得到了两个基于该raw bean生成的proxy对象,Spring容器不知道最终该在容器里保存哪一个了。

2.2 循环依赖放入二级缓存处逻辑

1.每个bean在进行属性注入之前,默认都会往Spring容器中放入一个ObjectFactory进入三级工厂,以便自己在属性注入的时候被循环依赖时调用生成对象

	if (earlySingletonExposure) {
		// 返回一个进行了aop处理的ObjectFactory,提前暴露
		// 但是只有当该实例在创建过程中还被其他实例引用(循环依赖),才会被调用getEarlyBeanReference
		// 此处是第四次调用beanPostProcessor,不一定会调用,只有当该类真的在创建过程中被其他类当做属性所依赖
		addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
	}

所以在创建CycleService1过程中,CycleService2去注入CycleService2之前在三级工厂里放入了自己的ObjectFactory对象,然后在CycleService2创建过程中,要注入CycleService1的时候,就会调用Spring容器中的getEarlyBeanReference(beanName, mbd, bean)获取CycleService1,下面我们来看看该方法调用的具体逻辑

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

在这里插入图片描述

然后咱们debug发现,只有AbstractAutoProxyCreator#getEarlyBeanReference方法,有具体实现逻辑

public Object getEarlyBeanReference(Object bean, String beanName) {
		Object cacheKey = getCacheKey(bean.getClass(), beanName);
		this.earlyProxyReferences.put(cacheKey, bean);
		return wrapIfNecessary(bean, beanName, cacheKey);
	}

具体的细节,我们就不进入的,主要就是通过调用wrapIfNecessary生成了raw bean的aop proxy bean,后面放入了二级缓存。

2.3 initializeBean生成的对象

在initializeBean方法里会调用applyBeanPostProcessorsAfterInitialization方法

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

在循环里面会调用postProcessAfterInitialization方法
重点关注AbstractAutoProxyCreator的该方法实现:

@Override
	public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
		if (bean != null) {
			Object cacheKey = getCacheKey(bean.getClass(), beanName);
			if (this.earlyProxyReferences.remove(cacheKey) != bean) {
				// 对bean进行proxy操作
				return wrapIfNecessary(bean, beanName, cacheKey);
			}
		}
		return bean;
	}

会发现AbstractAutoProxyCreator#postProcessAfterInitialization里面的具体逻辑就是判断这个类有没有调用过wrapIfNecessary,如果调用过就不再调用,就是保证同一个raw bean不会被多次proxy,同时提前暴露注入到其他对象里的就是proxy bean。
但是由于该bean(CycleService1)上加了@Async注解,此次也会触发AsyncAnnotationBeanPostProcessor#postProcessAfterInitialization,而这个方法,我们在这篇文章里讲过了,正是@Async注解能生效的关键逻辑。所以此处生成了一个具有Async功能的新的async proxy bean

2.4 再次分析原因

基于2.3和2.4,我们基于raw bean得到了二级缓存里的aop proxy bean和async proxy bean。
让我们再回忆一下判断逻辑:

//此处是从二级缓存里面根据beanName拿出对象,因为二级缓存里放入的是因为循环依赖给其他bean注入的代理对象
	Object earlySingletonReference = getSingleton(beanName, false);
	if (earlySingletonReference != null) {
		if (exposedObject == bean) {
			exposedObject = earlySingletonReference;
		}
		// 我们之前早期暴露出去的Bean跟现在最后要放到容器中的Bean不是同一个
		// allowRawInjectionDespiteWrapping为false
		// 并且当前Bean被当成依赖注入到了别的Bean中
		else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
			// 获取到当前Bean依赖的Bean
			String[] dependentBeans = getDependentBeans(beanName);
			// 要得到真实的依赖的Bean
			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.");
			}
		}
	}

简而言之,也就是此时从二级缓存里拿到了aop proxy bean,同时了执行完initializeBean之后,raw bean变为了async proxybean,Spring容器基于raw bean得到了两个proxy bean,无法处理了。所以在使用@Async注解时,尽量不要在被循环依赖的Class上添加

解决方案

打破循环依赖

目前我能想到的方法就是打破循环依赖,因为循环依赖发生在bean生命周期的–属性注入阶段,所以我们需要做的就是打破这种循环依赖

1.延迟注入(使用@Lazy注解)

@Service
public class CycleService1 {

	@Lazy
	@Autowired
	private CycleService2 cycleService2;

	@WangAnno
	@Async
	public void doThings() {
		cycleService2.alsoDo();
		System.out.println("it's a async move");
	}

}

看过这篇文章的都知道原理了,此处不再累赘

2. 手动延迟注入(使用applicationContext.getBean)

@Service
public class CycleService1 {

	@Autowired
	private ApplicationContext applicationContext;

	private CycleService2 cycleService2;

	@WangAnno
	@Async
	public void doThings() {
		if (Objects.isNull(cycleService2)) {
			cycleService2 = applicationContext.getBean(CycleService2.class);
		}
		cycleService2.alsoDo();
		System.out.println("it's a async move");
	}

}

其实效果是上面加了@Lazy效果是一样的,不过是我们自己在方法执行的过程中手动进行延迟注入而已。

总结

在这里插入图片描述

从二级缓存里拿到earlySingletonReference(aop proxy bean),同时了执行完initializeBean之后,raw bean变为了exposedObject(async proxy bean),Spring容器基于raw bean得到了两个proxy bean,无法处理了。
所以在使用@Async注解时,尽量不要在被循环依赖的Class上添加
实在非要添加,可以看看我给出的解决方法。

猜您喜欢

Copyright 2022 版权所有 软件发布 访问手机版

声明:所有软件和文章来自软件开发商或者作者 如有异议 请与本站联系 联系我们