从Jar包冲突搞到类加载机制，就是这么霸气

╰半橙微兮° 2022-08-28 07:46 111阅读 0赞

接手了一套比较有年代感的系统，计划把重构及遇到的问题写成系列文章，老树发新枝，重温一些实战技术，分享给大家。【重构01篇】，给大家讲讲Jar包冲突及原理。

## 背景 ##

目前市面上项目管理要么是基于Maven，要么是基于Gradle，最近接手了一套纯手动添加jar包的项目。

对于纯手动添加jar包的项目已经是多年前的方式了，现在工作三五年的技术人员可能都没有经历过。就是把项目中所需的jar包挨个找出来，添加到一个lib目录中，在IDE中再将jar包依赖手动添加上。

这种方式来添加jar包依赖，不仅费事，而且很容易出现jar包冲突，同时分析冲突手段，只能凭借经验。

最近就遇到这样一种情况：一个项目在开发者A的环境中可以正常启动，在B那里就无法启动，而异常信息是找不到什么什么类。

稍微有一些开发经验的人，马上就可以断定是jar包冲突导致。下面就看看如何解决及引申出来的知识点。

## 临时解决方案 ##

由于暂时无法对项目进行大范围重构，也不敢轻易将Jar包进行替换升级。只能采用临时的手段来进行解决。

这里总结几个步骤以备不时之需，通常也是解决Jar依赖问题的小技巧。

第一：在IDE中查找异常中找不到的类。比如IDEA MAC操作系统，我用的快捷键是command + shift + n。

![image-20210930093631187][]

以Assert类为例，可以看到有很多包都包含了Assert，但启动程序却报找不到该类的某个方法，问题基本上就出在Jar包冲突上了。

第二，定位到Jar包冲突之后，找到系统本应该使用的Jar包。

比如这里需要使用的spring-core中的类，而不spring.jar中的类。那么，就可以利用JVM的类加载顺序机制，让JVM先加载spring-core的jar包。

知识点：**在同一目录下的jar包，JVM是按照jar包的先后顺序进行加载，一旦一个全路径名相同的类被加载之后，后面再有相同的类便不会进行加载了。**

因此，临时解决方案就是调整JVM编译（加载）Jar包的顺序。这个在Eclipse和Idea中都有支持，可以手动进行调整。

Eclipse中调整方式：

![image-20210930094452201][]

Idea中调整方式：

![image-20210930094516514][]

把需要优先加载的jar包往上调整，这样就可以优先加载它，总算是临时解决了jar包冲突的问题。

## 类加载机制的延伸 ##

上面只是受限于项目现状的临时解决方案，最终肯定是要进行改造升级的，基于Maven或Gradle进行Jar包管理，同时解决掉Jar包冲突的问题的。

在这个临时解决方案，涉及到一个JVM的关键知识点：JVM的类加载器的隔离问题及双亲委派机制。如果没有JVM类加载机制的相关知识，可能连上面的临时方案都无法想到。

### 类加载器的隔离问题 ###

每个**类装载器**都有一个自己的**命名空间**用来保存已装载的类。当一个类装载器装载一个类时，它会通过保存在命名空间里的**类全局限定名**(`Fully Qualified Class Name`) 进行搜索来检测这个类是否已经被加载了。

`JVM` 对类唯一的识别是 `ClassLoader id` \+ `PackageName` \+ `ClassName`，所以一个运行程序中是有可能存在两个**包名**和**类名**完全一致的类的。并且如果这两个类不是由一个 `ClassLoader` 加载，是无法将一个类的实例强转为另外一个类的，这就是 `ClassLoader` 隔离性。

为了解决类加载器的**隔离问题**，`JVM`引入了**双亲委派机制**。

### 双亲委派机制 ###

双亲委派机制的核心有两点：第一，**自底向上**检查类是否**已加载**；其二，**自顶向下**尝试**加载类**。

![image-20211001215941215][]

类加载器通常有四类：启动类加载器、拓展类加载器、应用程序类加载器和自定义类加载器。

暂且不考虑自定义类加载器，JDK自带类加载器具体执行过程如下：

第一：当`AppClassLoader`加载一个`class`时，会把类加载请求**委派**给**父类加载器**`ExtClassLoader`去完成；

第二：当`ExtClassLoader`加载一个`class`时，会把类加载请求**委派**给`BootStrapClassLoader`去完成；

第三：如果`BootStrapClassLoader`加载失败（例如在`%JAVA_HOME%/jre/lib`里未查找到该`class`），会使用`ExtClassLoader`来尝试加载；

第四：如果`ExtClassLoader`也加载失败，则会使用`AppClassLoader`来加载，如果`AppClassLoader`也加载失败，则会报出异常`ClassNotFoundException`。

### ClassLoader的双亲委派实现 ###

`ClassLoader`通过`loadClass()`方法实现了**双亲委托机制**，用于类的**动态加载**。

该方法的源码如下：

protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException{
            synchronized (getClassLoadingLock(name)) {
                // First, check if the class has already been loaded
                Class<?> c = findLoadedClass(name);
                if (c == null) {
                    long t0 = System.nanoTime();
                    try {
                        if (parent != null) {
                            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;
            }
        }

loadClass方法本身是一个递归向上调用的过程，上述代码中从parent.loadClass的调用就可以看出。

在执行其他操作之前，首先通过findLoadedClass方法从最底端的类加载器开始检查是否已经加载指定的类。如果已经加载，则根据resolve参数决定是否要执行**连接**过程，并返回`Class`对象。

而Jar包冲突往往发生在这里，当第一个同名的类被加载之后，在这一步检查时就会直接返回，不会再加载真正需要的类。那么，程序用到该类时就会抛出找不到类，或找不到类方法的异常。

### Jar包的加载顺序 ###

上面已经看到一旦一个类被加载之后，全局限定名相同的类可能就无法被加载了。而Jar包被加载的顺序直接决定了类加载的顺序。

决定Jar包加载顺序通常有以下因素：

*  第一，Jar包所处的加载路径。也就是加载该Jar包的类加载器在JVM类加载器树结构中所处层级。上面讲到的四类类加载器加载的Jar包的路径是有不同的优先级的。
 *  第二，文件系统的文件加载顺序。因Tomcat、Resin等容器的ClassLoader获取加载路径下的文件列表时是不排序的，这就依赖于底层文件系统返回的顺序，当不同环境之间的文件系统不一致时，就会出现有的环境没问题，有的环境出现冲突。

本人遇到的问题属于第二种因素中的一个分支情况，即同一目录下不同Jar包的加载顺序不同。因此，通过调整Jar包的加载顺序就暂时解决了问题。

### Jar包冲突的通常表现 ###

Jar包冲突往往是很诡异的事情，也很难排查，但也会有一些共性的表现。

*  抛出java.lang.ClassNotFoundException：典型异常，主要是依赖中没有该类。导致原因有两方面：第一，的确没有引入该类；第二，由于Jar包冲突，Maven仲裁机制选择了错误的版本，导致加载的Jar包中没有该类。
 *  抛出java.lang.NoSuchMethodError：找不到特定的方法。Jar包冲突，导致选择了错误的依赖版本，该依赖版本中的类对不存在该方法，或该方法已经被升级。
 *  抛出java.lang.NoClassDefFoundError，java.lang.LinkageError等，原因同上。
 *  没有异常但预期结果不同：加载了错误的版本，不同的版本底层实现不同，导致预期结果不一致。

### Tomcat启动时Jar包和类的加载顺序 ###

最后，梳理一下Tomcat启动时，对Jar包和类的加载顺序，其中包含上面提到的不同种类的类加载器默认加载的目录：

*  $java\_home/lib 目录下的java核心api；
 *  $java\_home/lib/ext 目录下的java扩展jar包；
 *  java -classpath/-Djava.class.path所指的目录下的类与jar包；
 *  $CATALINA\_HOME/common目录下按照文件夹的顺序从上往下依次加载；
 *  $CATALINA\_HOME/server目录下按照文件夹的顺序从上往下依次加载；
 *  $CATALINA\_BASE/shared目录下按照文件夹的顺序从上往下依次加载；
 *  项目路径/WEB-INF/classes下的class文件；
 *  项目路径/WEB-INF/lib下的jar文件；

上述目录中，同一文件夹下的Jar包，按照顺序从上到下一次加载。如果一个class文件已经被加载到JVM中，后面相同的class文件就不会被加载了。

## 小结 ##

Jar包冲突在我们的日常开发中是非常常见的问题，如果能够很好理解冲突的原因及底层机制，可以极大的提高解决问题的能力和团队影响力。因此，在不少面试中都会被提及此类问题。

这篇文章我们重点讲了手动添加依赖情况下导致Jar包冲突的原因及解决方案。在解决该问题时往往还会设计到Maven对Jar包冲突管理的一些策略，比如依赖传递原则、最短路径优先原则、最先声明原则等，我们下篇文章再来详细聊聊。

> 博主简介：《SpringBoot技术内幕》技术图书作者，酷爱钻研技术，写技术干货文章。
> 
> 公众号：「程序新视界」，博主的公众号，欢迎关注~
> 
> 技术交流：请联系博主微信号：zhuan2quan

--------------------

![微信公众号：程序新视界][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]

“ **程序新视界**”，一个100%技术干货的公众号

--------------------

[image-20210930093631187]: /images/20220828/9ec1ea4ec23d4e17bcfb8bdfe885bc26.png
[image-20210930094452201]: /images/20220828/66af62c9c7df4288899b52e7b3637e2f.png
[image-20210930094516514]: /images/20220828/7f9085ee8d0b4160ab075a3a7b9f98e6.png
[image-20211001215941215]: /images/20220828/6aa2c92002ce4f9291b5244e6d74a869.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dvNTQxMDc1NzU0_size_16_color_FFFFFF_t_70_pic_center]: /images/20220828/55ea5453240544babf04fe7d8e7ab58e.png