冲突提示信息

「java.lang.ClassNotFoundException」：类型转换错误，本应该引入的是 logback 包的类，但是实际引入的是 slf4j 下的同名类，导致类型转换错误。

「java.lang.NoSuchMethodError」：找不到特定方法，如果有两个同名的包但是不同版本，例如 xxx-1.1和 xxx-1.2包同时存在，先加载了 1.1 版本的类，但是 1.2 版本中才提供了新方法，导致提示找不到特定方法

「java.lang.NoClassDefFoundError，java.lang.LinkageError」

解决方式：

查看catalina.sh堆栈信息，找到有问题的类
通过IDEA，在打包的POM文件中，使用Maven Helper插件找出冲突的依赖，确定项目需要的jar包，Exclude掉不需要的依赖

使用工具检查依赖冲突，冲突插件：maven-enforcer-plugin
引用第三方依赖（工具包或者框架包），通过Maven插件检查一下conflict依赖，提前进行Exclude

统一服务器版本
在测试阶段，准备好和生产环境一样的服务器，提前进行测试，避免依赖冲突的 WAR 包上传到生产环境，例如我们有一台 UAT 服务器，与生产环境一样配置，提前测试，暴露风险和解决问题。

==============================================

实际场景开发中遇得到的报错

如下两个报错原因：

「Class path contains multiple SLF4J binding」

「org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext」

查看报错代码

通过 StaticLoggerBinder.getSingleton().getLoggerFactory() 获取 logger 上下文这段代码报错了，通过仔细定位，发现了有两个 StaticLoggerBinder 类

public static void initLogging(String location) throws FileNotFoundException, JoranException {
   String resolvedLocation = SystemPropertyUtils.resolvePlaceholders(location);
   URL url = ResourceUtils.getURL(resolvedLocation);
   LoggerContext loggerContext = (LoggerContext)StaticLoggerBinder.getSingleton().getLoggerFactory();//报错代码，两个StaticLoggerBinder
   loggerContext.reset();
   new ContextInitializer(loggerContext).configureByResource(url);
}

虽然不是同一个 jar 包，但是包路径和名称都一模一样！！！

由于我们需要的是 logback 包，而不是 slf4j-log4j12 包，所以需要排除掉 slf4j-log4j12 依赖

解决方法

① 通过 POM 文件排查包冲突

② 安装 IDEA 的插件 Maven Helper

③ 定位到编译 WAR 包的 POM 文件（我们框架定义的在 Deploy 模块中）

④ 在搜索框中，输入搜索内容，点击右键可以看到选项框

Jump To Source（跳转到源文件处）
Exclude（排除掉）
例如我点击了 Exclude ，就能看到 pom 文件中，这个依赖就被排除掉了

<dependency>
    <groupId>cn.com.xxx</groupId>
    <artifactId>framework-conf-client</artifactId>
    <version>${xqy.framework.version}</version>
    <exclusions>
        <exclusion>
            <artifactId>slf4j-log4j12</artifactId>
            <groupId>org.slf4j</groupId>
        </exclusion>
    </exclusions>
</dependency>

排除依赖后，提交代码，重新打包，部署一条龙，顺利启动

=========================================================

类加载机制

在本地开发、测试环境都没有出现的问题，却在预发环境出现了，所以排除了业务逻辑代码的原因，简单考虑了几个因素和原因：

• jdk 版本
• tomcat 版本
• 类加载机制
• 第三方 jar 互相依赖

由于jdk/tomcat两者容易排查，未发现问题，所以再去排查类的加载机制

类加载机制

我们写的 Java 应用代码，一般是通过 App ClassLoader 应用加载器进行加载，它不会自己先去加载它，而是通过 Extension ClassLoader 扩展类加载器进行加载（其中扩展类加载器又会去找 Bootstrap ClassLoader 启动类加载器进行加载），只有父加载器无法加载情况下，才会让下级加载器进行加载。

Java 使用的是双亲委派加载机制，通过查看 ClassLoader 类。
类被成功加载后，将被放入到内存中，内存中存放 Class 实例对象。

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        // 首先，检查 class 是否已经被加载
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            // 如果没有被加载
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    // 寻找 parent 加载器
                    c = parent.loadClass(name, false);
                } else {
                    // 如果父加载器不存在，则委托给启动类加载器加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                // 如果仍然无法加载，才会尝试自身加载
                long t1 = System.nanoTime();
                c = findClass(name);
                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

类加载顺序

从代码中了解到，如果某个名字的类被加载后，类加载器是不会再重新加载，所以我们的问题根本原因可以是出现在：

「先加载了 org.slf4j 包的 org.slf4j.impl.StaticLoggerBinder，同名的 ch.qos.logback 包下的 StaticLoggerBinder 类没有被加载」

在 jvm 启动脚本中，添加 -verbose 参数或者 -XX:+TraceClassLoading
查看加载顺序

之前在本地开发中，IDEA 优化先加载了 ch.qos.logback 的 StaticLoggerBinder 类，然后后面的 org.slf4j 包下的同名类就没有被加载。

但这样也有个不明白，按理说加载顺序按照「字母顺序」加载，预发环境还是能够跟本地开发一样，加载到我们需要的类。实际上，加载器加载到的是另一个类，导致应用无法启动。

验证 inode 是否是问题的原因：

本地 Tomcat8 测试（正常启动）
将之前在 uat 环境有问题的代码版本重新打包，不使用 idea 工具，直接用 tomcat8 启动，并且在 catalina.sh 脚本中加入类加载打印参数 -XX:+TraceClassLoading

查看 catalina.out 输入日志，发现先加载的是 logback 包中 StaticLoggerBinder

本地 Tomcat8 测试（删包，先添加 slf4j，后添加 logback）

• 清理掉 catalina.out
• 重新上传包
• 比较 inode 大小
• 重新启动，查看类加载日志

「比较 inode 大小（发现 slf4j < logback)」

在 uat 环境服务器测试

在 WEB-INF/lib 路径下，先将这两个包删掉，尝试有不同的上传顺序，模拟 tomcat 解压 war 包

分别测试了两种场景，发现只要这两个包都存在的情况下，无论 inode 两者的大小，都是先加载了 slf4j 包的类，导致启动报错

通过多种测试场景，发现本地开发、测试环境都无法复现的问题，在 uat 环境下，只要这两个包同时存在，都会启动报错，系统版本是这个：

大意为：同一个目录下，jvm加载jar包顺序是无法保证的，每个系统的都不一样，甚至同一个系统不同的时刻加载都不一样。

于是乎，我也不纠结某台服务器上的类加载顺序，在开发阶段就先将这个包冲突的情况，给提前解决掉~

Spring Boot 项目打包成的 jar ，被其他项目依赖之后，总是报找不到类的错误

普通的jar：普通的 jar 不可以通过 java -jar xxx.jar 命令执行，普通的 jar 主要是被其他应用依赖

可执行的jar：Spring Boot 中默认打包成的 jar 叫做 可执行 jar，不可以被其他的应用所依赖，即使强制依赖，也无法获取里边的类。但是可执行 jar 并不是 Spring Boot 独有的，Java 工程本身就可以打包成可执行 jar

同样是执行 mvn package 命令进行项目打包，为什么 Spring Boot 项目就打成了可执行 jar ，而普通项目则打包成了不可执行 jar 呢？
Spring Boot 项目中一个默认的插件配置 spring-boot-maven-plugin ，这个打包插件存在 5 个方面的功能，从插件命令就可以看出：

• build-info：生成项目的构建信息文件 build-info.properties
• repackage：这个是默认 goal，在 mvn package 执行之后，这个命令再次打包生成可执行的 jar，同时将 mvn package 生成的 jar 重命名为 *.origin
• run：这个可以用来运行 Spring Boot 应用
• start：这个在 mvn integration-test 阶段，进行 Spring Boot 应用生命周期的管理
• stop：这个在 mvn integration-test 阶段，进行 Spring Boot 应用生命周期的管理

这里功能，默认情况下使用就是 repackage 功能，其他功能要使用，则需要开发者显式配置。
repackage 功能的 作用，就是在打包的时候，多做一点额外的事情：

1. 首先 mvn package 命令 对项目进行打包，打成一个 jar，这个 jar 就是一个普通的 jar，可以被其他项目依赖，但是不可以被执行
2. repackage 命令，对第一步 打包成的 jar 进行再次打包，将之打成一个 可执行 jar ，通过将第一步打成的 jar 重命名为 *.original 文件

举个例子：

对任意一个 Spring Boot 项目进行打包，可以执行 mvn package 命令，也可以直接在 IDEA 中点击 package ，如下 ：

打包成功之后， target 中的文件如下：

这里有两个文件，第一个 restful-0.0.1-SNAPSHOT.jar 表示打包成的可执行 jar ，
第二个 restful-0.0.1-SNAPSHOT.jar.original 则是在打包过程中 ，被重命名的 jar，这是一个不可执行 jar，但是可以被其他项目依赖的 jar。通过对这两个文件的解压，我们可以看出这两者之间的差异。

两种 jar 的比较：

可执行 jar 解压之后，目录如下：

可以看到，可执行 jar 中，我们自己的代码是存在 于 BOOT-INF/classes/ 目录下，另外，还有一个 META-INF 的目录，该目录下有一个 MANIFEST.MF 文件，打开该文件，内容如下：

Manifest-Version: 1.0
Implementation-Title: restful
Implementation-Version: 0.0.1-SNAPSHOT
Start-Class: org.javaboy.restful.RestfulApplication
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Build-Jdk-Spec: 1.8
Spring-Boot-Version: 2.1.6.RELEASE
Created-By: Maven Archiver 3.4.0
Main-Class: org.springframework.boot.loader.JarLauncher

可以看到，这里定义了一个 Start-Class，这就是可执行 jar 的入口类，Spring-Boot-Classes 表示我们自己代码编译后的位置，Spring-Boot-Lib 则表示项目依赖的 jar 的位置。

换句话说，如果自己要打一个可执行 jar 包的话，除了添加相关依赖之外，还需要配置 META-INF/MANIFEST.MF 文件。

这是可执行 jar 的结构，那么不可执行 jar 的结构呢？

我们首先将默认的后缀 .original 除去，然后给文件重命名，重命名完成，进行解压：

解压后可以看到，不可执行 jar 根目录就相当于我们的 classpath，解压之后，直接就能看到我们的代码，它也有 META-INF/MANIFEST.MF 文件，但是文件中没有定义启动类等。

Manifest-Version: 1.0
Implementation-Title: restful
Implementation-Version: 0.0.1-SNAPSHOT
Build-Jdk-Spec: 1.8
Created-By: Maven Archiver 3.4.0

【注意】
这个不可以执行 jar 也没有将项目的依赖打包进来。

从这里我们就可以看出，两个 jar ，虽然都是 jar 包，但是内部结构是完全不同的，因此一个可以直接执行，另一个则可以被其他项目依赖。

一次打包两个 jar

一般来说，Spring Boot 直接打包成可执行 jar 就可以了，不建议将 Spring Boot 作为普通的 jar 被其他的项目所依赖。
如果有这种需求，建议将被依赖的部分，单独抽出来做一个普通的 Maven 项目，然后在 Spring Boot 中引用这个 Maven 项目。

如果非要将 Spring Boot 打包成一个普通 jar 被其他项目依赖，技术上来说，也是可以的，给 spring-boot-maven-plugin 插件添加如下配置：

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <configuration>
            	<!--配置的 classifier 表示可执行 jar 的名字-->
                <classifier>exec</classifier>
            </configuration>
        </plugin>
    </plugins>
</build>

配置了这个之后，在插件执行 repackage 命令时，就不会给 mvn package 所打成的 jar 重命名了，所以，打包后的 jar 如下：

第一个 jar 表示可以被其他项目依赖的 jar ，第二个 jar 则表示一个可执行 jar。