欢迎访问我的GitHub
这里分类和汇总了欣宸的全部原创(含配套源码):
https://github.com/zq2599/blog_demos
java.lang.NoClassDefFoundError: Could not initialize class org.springframework.beans.factory.BeanCreationException
重现问题
- 继续打开上一章的工程,源码在Git上,地址:git@github.com:zq2599/blog_demos.git,下载后可以发现里面有很多工程,本次实战用的工程是springmybatisexceptiondemo,如下图红框所示:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjEyMDAyMjEzMDE2?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 打开工程,首先确保日志已经改为debug级别了,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE3MjAyMTI4MzYx?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 再打开spring-mybatis.xml文件,确保org.mybatis.spring.mapper.MapperScannerConfigurer的配置中,没有配置sqlSessionFactoryBeanName,如下图,sqlSessionFactoryBeanName配置是注释掉的:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE3MjE0MzM4ODA4?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
java.lang.NoClassDefFoundError: Could not initialize class org.springframework.beans.factory.BeanCreationException
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:547)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:475)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:228)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:700)
at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:760)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:403)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:306)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:106)
...
- tomcat的堆栈信息太占篇幅我就不贴出来了,只留了spring的;
第一个前提条件:spring配置会出发启动失败
- 在根据堆栈信息去打断点调试之前,我们先把MapperScannerConfigurer这个bean的配置信息搞清楚,sqlSessionFactoryBeanName这个属性对MapperScannerConfigurer的实例有什么影响呢?
- 打开MapperScannerConfigurer.java,在postProcessBeanDefinitionRegistry方法中看到sqlSessionFactoryBeanName属性被设置给ClassPathMapperScanner对象了,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE3MjIzNDAxNTU5?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 看ClassPathMapperScanner的doScan方法,这个方法是对basePackages路径下所有接口的动态代理对象设置属性,如果ClassPathMapperScanner对象中sqlSessionFactoryBeanName为空,就设置这些动态代理对象的autowire属性为AUTOWIRE_BY_TYPE,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE3MjI1MDE2Mzc4?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 也就是说,这次工程启动异常的原因,就是mybatis的mapper接口的动态代理对象需要sqlSessionFactory对象,此对象的获取有两种情况:
- 这个对象如果可以从MapperScannerConfigurer的sqlSessionFactoryBeanName属性直接指定,这项目就能启动成功;
- 如果没有在xml中为MapperScannerConfigurer指定sqlSessionFactoryBeanName属性,就会走另一个逻辑,在生成动态代理对象时,由spring环境寻找合适类型的bean去注入,此时项目会启动失败;
第二个前提条件:动态代理类数量增加会导致启动失败
- 大家看一下demo源码com.ssm.dao包下面,有很多个Mapper接口,这里的每一个接口,在spring启动的时候mybatis环境都会生成一个动态代理对象,当接口只有少量的时候,即便没有配置MapperScannerConfigurer属性,工程也能启动成功,数量逐渐增加到一定程度(具体数量和接口的复杂程度以及栈大小有关),就会启动失败,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE3MjMwNDAxMjU2?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
断点追踪
- 准备工作都ok了,咱们来通过打断点单步执行的方法来定位问题的位置吧,我用的是Intellij idea,此工具远程debug连接tomcat的的具体步骤请参照文章《Intellij idea远程debug连接tomcat,实现单步调试》
- 根据前面的堆栈日志,我们在ContextLoaderListener.java的106行打下断点,启动tomcat之后线程就会在此暂停,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjE4MjM0OTMyMTYw?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 然后就是进入方法内部单步执行了,在关键位置打了个断点,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MTE0MDQ5ODkx?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 信息很丰富,从左下角绿框中的堆栈可以看出一个bean的初始化调用层次:
- 在实例化userController的时候要处理它的userService属性,所以走到了CommonAnnotationBeanPostProcessor.autowireResource方法内,通过factory.getBean来获取userService对象,并且传入了name和type。
- 由于userService还没有创建,因此此处立即开始创建userService实例,很快,又执行到了CommonAnnotationBeanPostProcessor.autowireResource方法内,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MTIwOTIwNTcz?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 创建userService的时候,需要注入userDao属性,于是又会触发userDao实例的创建,但是,这次不是通过factory.getBean来创建了,而是DefaultListableBeanFactory.resolveDependency。
- 为什么userService对象是通过factory.getBean创建,而userDao却是通过DefaultListableBeanFactory.resolveDependency来创建的呢?
- 我们去看下工程中UserService.java,如下图红框所示,UserService已经通过注解声明为service组件了,所以在CommonAnnotationBeanPostProcessor.autowireResource方法中,factory.containsBean("userService")会返回true,而userDao呢?整个工程中没有一个类通过@Service标签声明为userDao组件,所以只能通过DefaultListableBeanFactory.resolveDependency去找了,传入了一堆信息給resolveDependency方法,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MTIzMzA5NzM4?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- resolveDependency方法会调用doResolveDependency方法,对于要注入的属性,例如userService对象的userDao属性,由于要根据属性类型来注入,所以要先找出一些候选人,在这些候选人中筛选出匹配的bean来完成注入,此逻辑对应的代码如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MTgyMTUyNzI1?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 在findAutowireCandidates中有几步比较重要:
- 要根据所需的对象类型查找beanName,在doGetBeanNamesForType方法中,通过getBeanDefinitionNames拿到了所有的bean的名称;
- 拿到这些名称后,对每个名称都调用isTypeMatch方法,传入名称和属性的类型;
- isTypeMatch方法的目的是根据bean名称找到bean实例,再看这个实例的类型和传入的类型是否一致;
- isTypeMatch方法中需要根据bean名称找到bean实例,因此,对于没有实例化过的bean名称,就会触发bean的实例化,最终走到了AbstractBeanFactory.doGetBean方法,这里面自定义了一个ObjFactory,里面执行了createBean方法,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MTk0ODE4NDE3?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 现在,我们在上图中的createBean方法处打断点,然后将代码执行下去,可以发现以下循环的逻辑:
- createBean的时候,由于要处理这个bean的依赖属性(例如user002Mapper的SqlSessionFactory属性),于是会调用DefaultListableBeanFactory.doResolveDependency方法;
- doResolveDependency方法中,要执行findAutowireCandidates方法获取所有的候选人,然后找出符合要求的bean赋給依赖属性(例如user002Mapper的SqlSessionFactory属性);
- findAutowireCandidates中的步骤我们刚才已经分析过了,对于没有实例化过的bean名称,就会触发bean的实例化,最终又走到了AbstractBeanFactory.doGetBean方法;
- 又回到了步骤一,只不过这次createBean创建的是另一个bean了;
- 在createBean处的断点不停的继续执行,最终在创建userXXXMapper的时候发生了StackOverflowError,我的本地电脑是user019Mapper;
- createBean打算创建userService;
- userService有个属性需要注入,这个属性的类型是UserMapper;
- 寻找属性为UserMapper的bean时候,执行findAutowireCandidates方法去查找合适的属性;
- 查找过程是按照所有单例的bean的名称,根据bean的名称挨个查的,找到了user001Mapper这个beanname;
- user001Mapper的实例并不存在,于是执行createBean创建user001Mapper;
- user001Mapper有个属性需要注入,这个属性的类型是SqlSessionFactory;
- 寻找属性为SqlSessionFactory的bean时候,执行findAutowireCandidates方法去查找合适的属性;
- 查找过程是根据beanname挨个查的,找到了user002Mapper这个beanname;
- user002Mapper的实例并不存在,于是执行createBean创建user002Mapper;
- user002Mapper有个属性需要注入,这个属性的类型是SqlSessionFactory;
- ......
- 执行createBean创建user003Mapper......
- ......
- 执行createBean创建user004Mapper......
- ......
- 每一次createBean都是在上一次createBean执行的过程中被调用的,堆栈层次会越来越深;
- com.ssm.dao包下面的接口越多,对应的动态代理实例就越多,此处的堆栈就越深;
- 深到一定层次的时候,例如创建user019Mapper时,就会抛出StackOverflowError异常了;
- 在AbstractAutowireCapableBeanFactory.doCreateBean方法中,对创建bean时抛出的异常做了try...catch处理,捕获到StackOverflowError之后,抛出的是beanName参数为user019Mapper的BeanCreationException,如下图:
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI1MjM0MjE4OTgz?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 按照方法堆栈层次的关系,创建user019Mapper时抛出BeanCreationException异常后,回到了创建user018Mapper的doCreateBean方法中,此时捕获的异常又被包装成beanName参数为user018Mapper的BeanCreationException;
- 按照上述的捕获抛出逻辑一层一层返回堆栈,最终抛出的异常是beanName参数为userController的BeanCreationException;
- 至此真相大白,在spring依赖注入的时候,AUTOWIRE_BY_TYPE类型的注入,总是要挨个获取所有bean的类型,从中选出类型合适的bean来注入,获取这些bean的过程中,如果还没有实例化就立即做实例化,做的时候又要对这些bean自身的属性进行注入,于是就出现了AbstractAutowireCapableBeanFactory.createBean方法的一层一层嵌套式调用,bean越多嵌套越深,导致栈内存被耗光
重要推断
- 根据以上的分析和追踪,我们可以推断出一种临时避免启动失败的方法,就是把栈的大小在java启动参数中配置得大一些,但这种方法是不可靠的,因为随着动态代理类数量的增加,栈的消耗越来越大,很有可能会再次耗尽栈内存,所以配置MapperScannerConfigurer的sqlSessionFactoryBeanName属性,以此来避免AUTOWIRE_BY_TYPE带来的栈层次加深才是可靠办法。
- 以上就是定位和分析异常的过程,看懂了整个过程,再回头来看看spring启动时抛出的异常,如下图,很多关键信息都被没有输出,如果不打断点,仅凭输出信息来定位问题是很难定位到问题所在的,下一篇,三部曲之三,我们去修改和编译spring的源码,让spring环境在抛出异常时带上更详细的错误信息。
![这里写图片描述 这里写图片描述](https://imgconvert.csdnimg.cn/aHR0cDovL2ltZy5ibG9nLmNzZG4ubmV0LzIwMTcwNjI2MDAxOTAzMDg5?x-oss-process=image/format,png&x-oss-process=image/resize,w_1400/format,webp)
- 对修改spring源码有兴趣的读者,可以先看下这篇文章《修改和编译spring源码,构建jar(spring-context-4.0.2.RELEASE)》,然后,咱们在下一章《spring+mybatis启动NoClassDefFoundError异常分析三部曲之三:改spring源码,取详细错误》一起动手实践;
欢迎关注阿里云开发者社区博客:程序员欣宸
学习路上,你不孤单,欣宸原创一路相伴...