Mybatis-Plus 版本冲突触发“Could not convert argument value of type [java.lang.String] to required type [java.lang.Class]”的 java.lang.NoClassDefFoundError 异常||沉潜飞动|君子藏器于身，待时而动。

Mybatis-Plus 版本冲突触发“Could not convert argument value of type [java.lang.String] to required type [java.lang.Class]”的 java.lang.NoClassDefFoundError 异常

你好，我是看山。

今天项目依赖了一个基础组件之后，启动失败，排查过程走了一些弯路，最终确认是因为依赖组件版本冲突造成了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;

@Mapper
public 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隐藏了真实异常，给我们排错造成了一些阻碍。所以，我们在日常开发时也要重视异常的明确信息，可以给我们排错提供准确的目标。

青山不改，绿水长流，我们下次见。