利用FatJar彻底解决Jar包冲突一
利用FatJar彻底解决Jar包冲突（一）
序
今天整理旧电脑里的资料，偶然翻到大概10年前实习时写的笔记，之前经常遇到Java依赖冲突的问题，想通过这种方式彻底解决Java里的依赖冲突，现在回过头来看，不知道是不是有点幼稚，欢迎交流，请轻喷。
FatJar的加载与隔离
⼀、 FatJar概念
将⼀个jar和他所依赖的jar都打在⼀个包中，这个包即为FatJar。 如何打FatJar
- 使⽤ maven shade 插件
使⽤ maven shade 插件解压依赖的jar并和原⼯程class混在⼀起打包成⼀个jar。 优点：打包⽅式简单，之后加载也较容易。
缺点：⽬录多且乱，对于jar包中的配置⽂件不利于定位；对于内部依赖冲突这种打包⽅式会⾃动排除冲突，覆盖class⽂
件，不利于排查jar包本身内部的冲突，如下图。
建议：如果能够忍受这么乱的⽬录可以使⽤这种⽅式，因为加载class的时候很⽅便。
- 使⽤ SpringBoot 提供的打包插件
由于SpringBoot打出来的jar可以直接启动，这个jar就是FatJar，所以可以使⽤ Spring Boot 提供的打包插件将依赖的jar直接
打进FatJar，如下图。
优点 ：通⽤，spring boot，pandora
boot都是基于这种⽅式，很多问题都有现成的解决⽅案⽐如之后遇到的autoconfig注⼊问题，autoconfig
提供了针对fatjar注⼊的插件。⽬录⼲净明了，如下图。
缺点 ：由于原⽣jar的加载只⽀持⼀层加载，即⽆法加载 jarin jar ⾥的class，所以这个问题需要调研，但是既然使⽤的是 Spring
Boot的打包⽅式，Spring Boot本身肯定已经解决了这个问题。
考虑到通⽤性与“美感”，下⾯针对这种打包⽅式来解决相应的问题。
⼆、FatJar的加载
fatjar与普通jar的区别就是它将依赖的jar也打进了jar包⾥的lib⽬录下，所以需要加载jarin jar。对于Jar⾥的资源，定义
以‘!/ʼ来分割。原始的JarFile URL只⽀持⼀个‘!/ʼ，如图。
通过阅读Spring Boot启动加载相关的源码，发现Spring Boot扩展了这个协议，让它⽀持多个‘!/ʼ，从⽽就可以表示jarin jar的
资源了，如图。
既然这样，我们就可以复⽤Spring Boot 的 加载⽅式，即通过继承spring
boot的launcher，复⽤它的createClassLoader来构造LaunchedURLClassLoader。
三、FatJar的隔离
解决了加载的问题之后，就需要研究如何与依赖FatJar的应⽤（以下简称为“应⽤”）隔离了，因为我们最终的⽬标就是针对
应⽤和jar⾥同类名（全路径）的两个class都能够加载且不冲突。根据java classloader的委托加载机制，我们可以确定我们
的FatJarClassLoader所处的位置如下：
应⽤的classloader使⽤的是AppClassLoader，需要创建⼀个与它同级的ClassLoader即FatJarClassLoader，通过设置
LaunchedClassLoader的parent为AppClassLoader的parent即ExtensionClassLoader就可以了，这样两个ClassLoader就可以
像上图那样隔离。
四、隔离机制验证
FatJarClassLoader 构造完成之后，我们就可以验证⼀下到底能不能解决冲突了。
- 原理层⾯验证
验证代码如下：
输出结果如下：
可以看到 FatJarClassLoader 的 parent 为
ExtensionClassLoader，所以与AppClassLoader是同级的。String的ClassLoader为
空是由于BootStrapClassLoader是通过C++编写的，是最“底”层的ClassLoader。
- 实例验证-构造冲突
在⼆⽅包中添加⽇志依赖如下：
该版本的Logger是有trace⽅法的，我们在⼆⽅包中可以直接调⽤进⾏确认：
将⼆⽅包打成普通的jar包，在应⽤中依赖该jar包（conflict-b），同时也依赖⼀个低版本的⽇志包：
在应⽤中调⽤⼆⽅包中的某个⽅法，该⽅法内部会调⽤Logger的trace⽅法：
报错如下：
可⻅构造冲突已经成功了！
- 实例验证-利⽤FatJar解决冲突
将⼆⽅包打成FatJar之后在应⽤中通过反射调⽤原来会冲突的代码，调⽤成功：
可⻅，⼆⽅包是通过隔离的⽅式加载的，加载的是⼆⽅包⾃带的⾼版本的Logger；⽽应⽤本身加载的还是⽼版本的 Logger。
输出结果如下：
可以看到 FatJarClassLoader 的 parent 为
ExtensionClassLoader，所以与AppClassLoader是同级的。String的ClassLoader为
空是由于BootStrapClassLoader是通过C++编写的，是最“底”层的ClassLoader。
该版本的Logger是有trace⽅法的，我们在⼆⽅包中可以直接调⽤进⾏确认：
将⼆⽅包打成普通的jar包，在应⽤中依赖该jar包（conflict-b），同时也依赖⼀个低版本的⽇志包：
在应⽤中调⽤⼆⽅包中的某个⽅法，该⽅法内部会调⽤Logger的trace⽅法：
报错如下：
可⻅构造冲突已经成功了！
可⻅，⼆⽅包是通过隔离的⽅式加载的，加载的是⼆⽅包⾃带的⾼版本的Logger；⽽应⽤本身加载的还是⽼版本的 Logger。五、 FatJar的定位
由于是在运⾏期加载FatJar，所以需要⼿动定位FatJar的位置，这边普通Java程序和Java Web 定位⽅式不同，⽬前只是同时
使⽤这两种⽅式进⾏加载，还没有其他更通⽤的解决⽅案。 当依赖⽅是普通 Java 程序时，所有依赖的jar包路径可以通过如下代码获得：
⽽当依赖⽅是Java Web 应⽤时，根据Tomcat 中应⽤的⽬录结构：
得到 jar 包路径的步骤为：
1 AppClassLoader.getResource(“/”).getPath()
2 上溯并进⼊lib⽬录即可
六、 打包注意点
使⽤Spring Boot插件打出的FatJar是包含pom.xml 的，如下图：
可⻅pom⽂件位置和普通jar包的位置是⼀致的，这样的话应⽤maven其实是可以识别到FatJar的pom⽂件的，这样会将
FatJar依赖的jar包加⼊到应⽤⾥，还是需要⼿动排除冲突，这就跟我们的初衷不⼀致了。所以需要将pom⽂件在打包时排 除，如下代码：
