Spring 记录一次项目启动失败的问题

主题

最近学习了spring相关知识.公司项目也用到了spring..偶然一次版本中发现,本地启动项目没问题,服务器上启动报bean创建异常.

于是研究了一下,对spring有了更深的理解..也记录一下问题原因...

异常

大致错误如下(我本地模拟了一下.原理一样)

17:19:02.056 [main] WARN org.springframework.context.support.ClassPathXmlApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCurrentlyInCreationException: Error creating bean with name 'beanA': Bean with name 'beanA' has been injected into other beans [beanB] 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 'beanA': Bean with name 'beanA' has been injected into other beans [beanB] 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:624)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:517)
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:323)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:321)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
        at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:879)
        at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:878)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:550)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:144)
        at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:85)
        at com.labofjet.sh1.sp.a.BeanA.main(BeanA.java:42)

大致的意思是 创建beanA失败, A的raw(原始)版本被注入了beanB中,a,b 2个bean循环依赖. 但是A最终 been wrapped,就是被代理了.所以BeanB中注入的A(raw)与最终的A(wrapped)是不一致的.所以报了异常.

排查

首先,这次发布,我们没有新增新的service bean..就是加了几个方法..所以如果是循环依赖.那之前的版本就会报错...

排除了循环依赖导致(其实这个也是其中的一个原因)..以后..我找了找这次有没有什么特殊的操作..

发现了这次版本使用了注解@Async.这个注解标记的方法会异步执行.

但是这个注解之前我们项目里其他地方也用到过..之前没遇到过问题...注释掉以后项目确实可以启动...

反复尝试以后确定原因为:

1.bean循环依赖

2.@Async注解

原理

记录一下为什么这2个操作组合在一起会有问题.(还需要特定的Bean的加载顺序)

AsyncAnnotationBeanPostProcessor

@Async这个注解功能是依赖这个Async的BPP来实现的.

原理在于他实现了BeanPostProcessor接口,在bean属性设置以后会有机代理你的bean.返回proxy.

AOP原理就不仔细讲了.可以参考我之前的文章.

大致就是:

1.代理bean,封装advisor

2.调用连接点的方法的前后会调用advisor的advise(interceptor的方法).这里就是AsyncExecutionInterceptor

3.AsyncExecutionInterceptor里找到你@Async注解里定义的executor,提交任务达到异步调用的目的.

加载顺序问题

明白了async的原理以后.我们来研究下为什么会出现问题.

当ABA问题出现的时候,如果加载bean的顺序为先加载A.那spring里操作顺序为:

1.加载A,new A. 这个时候A刚刚被new.属性也没设置,更别说被代理了.

2.注入A的属性..发现需要注入B这个属性.

3.加载B, new B. 类似步骤1.

4.注入B的属性...发现需要A..为了解决循环依赖无限循环下去...所以这里注入了原始的A也就是步骤1的A.

5.B注入属性完成

6.B加载完成,被丢到spring的容器内.可以被使用.

6.A属性注入完成

7.因为A的方法上有@Async注解.A会被AsyncAnnotationBeanPostProcessord代理..返回了proxyA,即wrapped的A

8.A被替换成了proxyA..proxyA被丢到spring容器里,(还没可以被使用,加载方法还没完成,其实容器里的还是原始的A..之后才会被替换.这里只是为了表述逻辑...).

9.检测到A被注入到B中过..B中的A != 容器里的proxyA..于是报错..(A的加载抛出错误)

所以就有了开头的问题..但是这个bean的加载顺序是会影响结果的..如果先加载B就不会有这个问题,因为B方法上没有@Async..不会被proxy.

试验结果是.不同机器上加载bean顺序不一样.但是同一台机器上每次加载的顺序是一样的.目前还没研究顺序是什么因素决定的.

一点思考

明白BPP代理bean在循环依赖过程中可能会造成创建异常...我就有了一个疑问...

为什么@Transaction和我们自己写的@Aspect就没问题???这也是依赖AOP(动态代理)来实现的呀??

SmartInstantiationAwareBeanPostProcessor

原因在于这2个的实现BPP类都实现了这个接口 

这个接口的用处在于..当你在ABA中的B获取A的时候给你一次回调机会..让你可以返回proxy的A.而不是原始的rawA.....所以A和B.A就都是proxyA了.就不会抛出异常咯...

另外想说一下..看类的结构都能看出来aspect和transaction的实现方式是非常类似的...共用了很大一部分代码...(只是为每个bean包装advisor的方式不同)

但是很可惜..AsyncAnnotationBeanPostProcessor没有实现这个接口..原因不明

@Lazy 

循环依赖的出现导致一个Bean的raw和wrapped会被注入到不同的Bean出现错误...

 SmartInstantiationAwareBeanPostProcessor的解决策略是提前返回wrapped Bean.

而@Lazy的解决策略是斩断循环依赖...

@Lazy也会注入在你的Bean(A)里注入属性Bean(B).只是这个属性Bean(B)并不是你@Component的那个Bean(B)...而是代理生产的子类Bean(B')..

现在因为有2个不同的Bean...1个你的@Component的Bean(B)... 1个你的@Component的Bean的子类的Bean(B')...所以不再有循环依赖...

当调用属性Bean的方法的时候转发给你真正@Component的那个Bean来调对应的方法.

小结

spring本身可以解决循环依赖的问题..

但是当特殊的情况下还是会出现Bean创建的问题...(循环依赖+没实现SmartInstantiationAwareBeanPostProcessor的BPP+特定的Bean加载顺序)

解决办法:

1.BPP的实现类实现SmartInstantiationAwareBeanPostProcessor接口..参考@Transaction和@Aspect

2.注入的Bean用@Lazy修饰