今天项目依赖了一个基础组件之后，启动失败，排查程序走了一些弯路，最终确认是因为依赖组件版本冲突造成了java.lang.NoClassDefFoundError例外，下面是排查程序，希望可以给你提供一些思路，
观察例外堆栈
下面是打印的例外堆栈信息，从其中提炼可能的关键信息，能够找到“Could not convert argument value of type [java.lang.String] to required type [java.lang.Class]”，还有“Unresolvable class definition for class [cn.howardliu.demo.AddressMapper]”，继续从例外堆栈中找一下发生的时机，可以发现是呼叫AbstractAutowireCapableBeanFactory.createBeanInstance时，这个方法是创建 Bean 实体，
这块是例外信息（getMessage 的内容，横向太长，手动换行了）： org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'methodValidationPostProcessor' defined in class path resource [org/springframework/boot/autoconfigure/validation/ValidationAutoConfiguration.class]: Unsatisfied dependency expressed through method 'methodValidationPostProcessor' parameter 0; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'addressMapper' defined in file [/Users/liuxinghao/Documents/work/code/cn.howardliu/effective-spring/target/classes/cn/howardliu/demo/AddressMapper.class]: Unsatisfied dependency expressed through constructor parameter 0: Could not convert argument value of type [java.lang.String] to required type [java.lang.Class]: Failed to convert value of type 'java.lang.String' to required type 'java.lang.Class'; nested exception is java.lang.IllegalArgumentException: Unresolvable class definition for class [cn.howardliu.demo.AddressMapper] 下面是例外堆栈： at org.springframework.beans.factory.support.ConstructorResolver.createArgumentArray(ConstructorResolver.java:799) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.ConstructorResolver.instantiateUsingFactoryMethod(ConstructorResolver.java:540) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateUsingFactoryMethod(AbstractAutowireCapableBeanFactory.java:1341) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1181) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:556) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:516) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:324) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:234) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:322) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:207) ~[spring-beans-5.2.13.RELEASE.jar:5.2.13.RELEASE] 其他例外堆栈信息可以忽略了
我们可以根据目前有效的信息进行排查，首先看下我们的cn.howardliu.demo.AddressMapper定义是否有问题，再看看依赖它的 Service 有没有问题，什么问题也没有发现，下一个检查点是配置，比如@MapperScan是否正确、Mapper 类上有没有加上@Mapper注解，发现也没有问题，
从例外信息找不到思路了，只能从代码入手了，
这里需要说一下，打印例外信息至关重要，直接影响我们排错的思路，如果打印的信息没有办法准确定位，我们将会花费大量的时间查找真正的错误，这就需要走查代码，有时候还需要一些经验，
定位问题
我们由例外堆栈``ConstructorResolver.createArgumentArray(ConstructorResolver.java:799) 入手，跟着断点往下追，最侄训追到org.springframework.util.ClassUtils#forName方法，其中会抛出例外的代码是下面这块：
try {
return Class.forName(name, false, clToUse);}catch (ClassNotFoundException ex) {
int lastDotIndex = name.lastIndexOf(PACKAGE_SEPARATOR);
if (lastDotIndex != -1) {
String innerClassName =
name.substring(0, lastDotIndex) + INNER_CLASS_SEPARATOR + name.substring(lastDotIndex + 1);
try {
return Class.forName(innerClassName, false, clToUse);
}
catch (ClassNotFoundException ex2) {
// Swallow - let original exception get through
}
}
throw ex;}出现错误的是Class.forName(name, false, clToUse)这句，name传的是"cn.howardliu.demo.AddressMapper"字符串，抛出的例外是java.lang.NoClassDefFoundError，由于不是ClassNotFoundException例外，不会进入catch逻辑，会直接向上抛出，
找到错误我们就好定位问题了，
一般来说，java.lang.NoClassDefFoundError错误是需要加载的类能够找到，但是加载时出现了例外，简单说就是，类的定义有问题，我们借助 JD-GUI 反编译一下运行 jar 包，结果如下：
import com.baomidou.mybatisplus.core.mapper.BaseMapper;import cn.howardliu.demo.Address;import org.apache.ibatis.annotations.Mapper;@Mapperpublic interface AddressMapper extends BaseMapper {}观察仔细的话，我们可以看到import com.baomidou.mybatisplus.core.mapper.BaseMapper;这行没有下划线，也就是说，在反编译工具中追溯不到这个界面，推断出来就是在运行环境中，找不到BaseMapper这个类定义，
所以，当Class.forName加载类的时候抛出了java.lang.NoClassDefFoundError例外，
解决问题
如果有一定经验，就会立刻想到，大概率出现了依赖 jar 的版本冲突，
我们可以借助 maven 命令列找到版本冲突的依赖：
mvn dependency:tree -Dverbose | grep conflict
打印结果为：
[INFO] | +- (com.baomidou:mybatis-plus:jar:3.1.2:compile - omitted for conflict with 2.1.6)
我们也可以借助 IDEA 的可视化工具，在 pom.xml 上打开依赖图：
我们可以看到 mybatis-plus 的红线指示出冲突信息：
结论就是 Mybatis-Plus 版本冲突了，项目中依赖了 mybatis-plus 的 2.1.6 和 3.1.2 两个版本，由于 2.1.6 路径更短，最终被选中，
此时只需要将低版本的依赖去掉即可，
复盘问题
mybatis-plus 的版本问题
为什么低版本的 mybatis-plus 会造成类加载失败呢？是因为 mybatis-plus 跨版本更新时，把BaseMapper的包路径改了：
// 3.1.2 版本import com.baomidou.mybatisplus.core.mapper.BaseMapper;// 2.1.6 版本import com.baomidou.mybatisplus.mapper.BaseMapper;
而且还不止这一个，IService、ServiceImpl、TableName、TableField、Model、TableField等等，很多常用的类都改了位置，所以会造成找不到依赖的类，编译是 3.1.2 依赖还在运行环境中，就会出现编译没有问题，执行时出现加载类例外，
想要工程化的解决这个问题，我们可以创建基础的依赖 bom 配置，定义好基础依赖包，在项目中不在指定版本，这样做到统一版本，可以有效的避免这类问题，
我们还可以在 CI/CD 中加入冲突依赖检查，如果发现冲突依赖，就终止流水线，
真实体外被隐藏问题
接下来我们看下为什么明明是java.lang.NoClassDefFoundError例外，结果例外堆栈中打印的是一堆不相干的错误，继续跟着刚才的断点 Debug：
org.springframework.util.ClassUtils#resolveClassName会捕捉LinkageError错误，然后包装成IllegalArgumentException例外，这个时候真是例外还是继续上抛，
然后在org.springframework.beans.TypeConverterSupport#convertIfNecessary方法会包装成TypeMismatchException例外，此时，真实体外还在例外cause自变量中，并没有丢失，
等回到org.springframework.beans.factory.support.ConstructorResolver#createArgumentArray方法后，捕捉例外的方法是：
try {
convertedValue = converter.convertIfNecessary(originalValue, paramType, methodParam);}catch (TypeMismatchException ex) {
throw new UnsatisfiedDependencyException(
mbd.getResourceDescription(), beanName, new InjectionPoint(methodParam),
"Could not convert argument value of type [" +
ObjectUtils.nullSafeClassName(valueHolder.getValue()) +
"] to required type [" + paramType.getName() + "]: " + ex.getMessage());}此时我们可以注意到，在包装成UnsatisfiedDependencyException例外的时候，只是把捕捉到的TypeMismatchException通过getMessage方法追加在例外描述后面，此时经过前面几轮的包装再包装，真实的例外的例外信息仅剩Unresolvable class definition for class [cn.howardliu.demo.AddressMapper]这段经过处理的信息，完全没有java.lang.NoClassDefFoundError的影子了，
至此，真实体外消失无踪，
这也给我们一个提醒，我们要保证例外的时候，一定要保留有效信息，否则，排错会非常麻烦，
文末总结
本文是抓虫文，从问题出发，到解决问题，给出完整的思路，java.lang.NoClassDefFoundError一般都是出现在版本冲突的时候，这种例外是编译打包没有问题，在运行时加载类失败，在本文中之所以排查时走了一些弯路，是因为Spring隐藏了真实体外，给我们排错造成了一些阻碍，所以，我们在日常开发时也要重视例外的明确信息，可以给我们排错提供准确的目标，
青山不改，绿水长流，我们下次见，
推荐阅读
一文掌握 Java8 Stream 中 Collectors 的 24 个操作
一文掌握 Java8 的 Optional 的 6 种操作
使用 Lambda 表达式实作超强的排序功能
Java8 的时间库（1）：介绍 Java8 中的时间类及常用 API
Java8 的时间库（2）：Date 与 LocalDate 或 LocalDateTime 互相转换
Java8 的时间库（3）：开始使用 Java8 中的时间类
Java8 的时间库（4）：检查日期字符串是否合法
Java8 的新特性
Java9 的新特性
0 评论