spring+mybatis启动NoClassDefFoundError异常分析三部曲之二：定位错误

spring+mybatis项目启动失败，报错：

java.lang.NoClassDefFoundError: Could not initialize class org.springframework.beans.factory.BeanCreationException

在上一章《spring+mybatis启动NoClassDefFoundError异常分析三部曲之一：稳定重现问题》一文中，我们已经可以在本机tomcat上稳定重现这个问题，今天一起来把异常的详细位置找到吧。

重现问题

继续打开上一章的工程，源码在Git上，地址：git@github.com:zq2599/blog_demos.git，下载后可以发现里面有很多工程，本次实战用的工程是springmybatisexceptiondemo，如下图红框所示：

这里写图片描述

打开工程，首先确保日志已经改为debug级别了，如下图：

这里写图片描述

再打开spring-mybatis.xml文件，确保org.mybatis.spring.mapper.MapperScannerConfigurer的配置中，没有配置sqlSessionFactoryBeanName，如下图，sqlSessionFactoryBeanName配置是注释掉的：

这里写图片描述

ok，打包，部署吧，可以看到如下错误信息：

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对象了，如下图：

这里写图片描述

看ClassPathMapperScanner的doScan方法，这个方法是对basePackages路径下所有接口的动态代理对象设置属性，如果ClassPathMapperScanner对象中sqlSessionFactoryBeanName为空，就设置这些动态代理对象的autowire属性为AUTOWIRE_BY_TYPE，如下图：

这里写图片描述

也就是说，这次工程启动异常的原因，就是mybatis的mapper接口的动态代理对象需要sqlSessionFactory对象，此对象的获取有两种情况： 1. 这个对象如果可以从MapperScannerConfigurer的sqlSessionFactoryBeanName属性直接指定，这项目就能启动成功; 2. 如果没有在xml中为MapperScannerConfigurer指定sqlSessionFactoryBeanName属性，就会走另一个逻辑，在生成动态代理对象时，由spring环境寻找合适类型的bean去注入，此时项目会启动失败；

第二个前提条件：动态代理类数量增加会导致启动失败

大家看一下demo源码com.ssm.dao包下面，有很多个Mapper接口，这里的每一个接口，在spring启动的时候mybatis环境都会生成一个动态代理对象，当接口只有少量的时候，即便没有配置MapperScannerConfigurer属性，工程也能启动成功，数量逐渐增加到一定程度(具体数量和接口的复杂程度以及栈大小有关)，就会启动失败，如下图：

这里写图片描述

断点追踪

准备工作都ok了，咱们来通过打断点单步执行的方法来定位问题的位置吧,我用的是Intellij idea，此工具远程debug连接tomcat的的具体步骤请参照文章《Intellij idea远程debug连接tomcat，实现单步调试》； 根据前面的堆栈日志，我们在ContextLoaderListener.java的106行打下断点，启动tomcat之后线程就会在此暂停，如下图：

这里写图片描述

然后就是进入方法内部单步执行了，在关键位置打了个断点，如下图：

这里写图片描述

信息很丰富，从左下角绿框中的堆栈可以看出一个bean的初始化调用层次： 在实例化userController的时候要处理它的userService属性，所以走到了CommonAnnotationBeanPostProcessor.autowireResource方法内，通过factory.getBean来获取userService对象，并且传入了name和type。

由于userService还没有创建，因此此处立即开始创建userService实例，很快，又执行到了CommonAnnotationBeanPostProcessor.autowireResource方法内，如下图：

这里写图片描述

创建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方法，如下图：

这里写图片描述

resolveDependency方法会调用doResolveDependency方法，对于要注入的属性，例如userService对象的userDao属性，由于要根据属性类型来注入，所以要先找出一些候选人，在这些候选人中筛选出匹配的bean来完成注入，此逻辑对应的代码如下图：

这里写图片描述

在findAutowireCandidates中有几步比较重要： 1. 要根据所需的对象类型查找beanName，在doGetBeanNamesForType方法中，通过getBeanDefinitionNames拿到了所有的bean的名称; 2. 拿到这些名称后，对每个名称都调用isTypeMatch方法，传入名称和属性的类型； 3. isTypeMatch方法的目的是根据bean名称找到bean实例，再看这个实例的类型和传入的类型是否一致； 4. isTypeMatch方法中需要根据bean名称找到bean实例，因此，对于没有实例化过的bean名称，就会触发bean的实例化，最终走到了AbstractBeanFactory.doGetBean方法，这里面自定义了一个ObjFactory，里面执行了createBean方法，如下图：

这里写图片描述

现在，我们在上图中的createBean方法处打断点，然后将代码执行下去，可以发现以下循环的逻辑： 1. createBean的时候，由于要处理这个bean的依赖属性（例如user002Mapper的SqlSessionFactory属性），于是会调用DefaultListableBeanFactory.doResolveDependency方法; 2. doResolveDependency方法中，要执行findAutowireCandidates方法获取所有的候选人，然后找出符合要求的bean赋給依赖属性（例如user002Mapper的SqlSessionFactory属性）； 3. findAutowireCandidates中的步骤我们刚才已经分析过了，对于没有实例化过的bean名称，就会触发bean的实例化，最终又走到了AbstractBeanFactory.doGetBean方法； 4. 又回到了步骤一，只不过这次createBean创建的是另一个bean了； 5. 在createBean处的断点不停的继续执行，最终在创建userXXXMapper的时候发生了StackOverflowError，我的本地电脑是user019Mapper；

结合我们的工程可以这么解释了： 1. createBean打算创建userService； 2. userService有个属性需要注入，这个属性的类型是UserMapper； 3. 寻找属性为UserMapper的bean时候，执行findAutowireCandidates方法去查找合适的属性； 4. 查找过程是按照所有单例的bean的名称，根据bean的名称挨个查的，找到了user001Mapper这个beanname； 5. user001Mapper的实例并不存在，于是执行createBean创建user001Mapper； 6. user001Mapper有个属性需要注入，这个属性的类型是SqlSessionFactory； 7. 寻找属性为SqlSessionFactory的bean时候，执行findAutowireCandidates方法去查找合适的属性； 8. 查找过程是根据beanname挨个查的，找到了user002Mapper这个beanname； 9. user002Mapper的实例并不存在，于是执行createBean创建user002Mapper； 10. user002Mapper有个属性需要注入，这个属性的类型是SqlSessionFactory； 11. …… 11. 执行createBean创建user003Mapper…… 12. …… 13. 执行createBean创建user004Mapper…… 14. …… 14. 每一次createBean都是在上一次createBean执行的过程中被调用的，堆栈层次会越来越深； 15. com.ssm.dao包下面的接口越多，对应的动态代理实例就越多，此处的堆栈就越深； 16. 深到一定层次的时候，例如创建user019Mapper时，就会抛出StackOverflowError异常了； 17. 在AbstractAutowireCapableBeanFactory.doCreateBean方法中，对创建bean时抛出的异常做了try…catch处理，捕获到StackOverflowError之后，抛出的是beanName参数为user019Mapper的BeanCreationException，如下图：

这里写图片描述

1. 按照方法堆栈层次的关系，创建user019Mapper时抛出BeanCreationException异常后，回到了创建user018Mapper的doCreateBean方法中，此时捕获的异常又被包装成beanName参数为user018Mapper的BeanCreationException；
2. 按照上述的捕获抛出逻辑一层一层返回堆栈，最终抛出的异常是beanName参数为userController的BeanCreationException；

至此真相大白，在spring依赖注入的时候，AUTOWIRE_BY_TYPE类型的注入，总是要挨个获取所有bean的类型，从中选出类型合适的bean来注入，获取这些bean的过程中，如果还没有实例化就立即做实例化，做的时候又要对这些bean自身的属性进行注入，于是就出现了AbstractAutowireCapableBeanFactory.createBean方法的一层一层嵌套式调用，bean越多嵌套越深，导致栈内存被耗光

重要推断

根据以上的分析和追踪，我们可以推断出一种临时避免启动失败的方法，就是把栈的大小在java启动参数中配置得大一些，但这种方法是不可靠的，因为随着动态代理类数量的增加，栈的消耗越来越大，很有可能会再次耗尽栈内存，所以配置MapperScannerConfigurer的sqlSessionFactoryBeanName属性，以此来避免AUTOWIRE_BY_TYPE带来的栈层次加深才是可靠办法。

以上就是定位和分析异常的过程，看懂了整个过程，再回头来看看spring启动时抛出的异常，如下图，很多关键信息都被没有输出，如果不打断点，仅凭输出信息来定位问题是很难定位到问题所在的，下一篇，三部曲之三，我们去修改和编译spring的源码，让spring环境在抛出异常时带上更详细的错误信息。

这里写图片描述

对修改spring源码有兴趣的读者，可以先看下这篇文章《修改和编译spring源码，构建jar(spring-context-4.0.2.RELEASE)》，然后，咱们在下一章一起动手实践；