你好，我是看山。
今天项目依赖了一个基础组件之后，启动失败，排查过程走了一些弯路，最终确认是因为依赖组件版本冲突造成了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<Address> {}
复制代码
观察仔细的话，我们可以看到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隐藏了真实异常，给我们排错造成了一些阻碍。所以，我们在日常开发时也要重视异常的明确信息，可以给我们排错提供准确的目标。
青山不改，绿水长流，我们下次见。
推荐阅读
你好，我是看山。游于码界，戏享人生。如果文章对您有帮助，请点赞、收藏、关注。
评论