曹工说面试：当应用依赖jar包的A版本，中间件jar包依赖B版本，两个版本不兼容，这还怎么玩？

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

背景

大一点的公司，可能有一些组，专门做中间件的；假设，某中间件小组，给你提供了一个jar包，你需要集成到你的应用里。假设，它依赖了一个日期类，版本是v1；我们应用也依赖了同名的一个日期类，版本是v2.

两个版本的日期类，方法逻辑的实现，有一些差异。

举个例子，中间件提供的jar包中，依赖如下工具包：

<dependency> <groupId>com.example</groupId> <artifactId>common-v1</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

该版本中，包含了com.example.date.util.CommonDateUtil这个类。

package com.example.date.util;import lombok.extern.slf4j.Slf4j;@Slf4j public class CommonDateUtil { public static String format(String date) { // 1 String s = date + "- v1"; log.info("v1 result:{}", s); return s; } }

应用中，依赖如下jar包：

<dependency> <groupId>com.example</groupId> <artifactId>common-v2</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

该jar包中，包含同名的class，但里面的方法实现不一样：

@Slf4j public class CommonDateUtil { public static String format(String date) { String s = date + "- v2"; log.info("v2 result:{}", s); return s; } }

ok，那假设我们是一个spring boot应用，当中间件小组的哥们找到你，让你集成，你可能就愉快地弄进去了；但是，有个问题时，你的jar包、和中间件小哥的jar包，都是放在fatjar的lib目录的（我这里解压了，方便查看）：

请问，最终加载的CommonDateUtil类，到底是common-v1的，还是commonv2中的呢？因为spring boot加载BOOT-INF/lib时，肯定都是同一个类加载器，同一个类加载器，对于一个包名和类名都相同的类，只会加载一次；那么，加载了v1，就不可能再加载V2；反之亦然。

那这就出问题了。我们应用要用V2；中间件要用V1，水火不容啊，这可怎么办？

分析

首先，我们要重写spring boot的启动类，这是毋庸置疑的，启动类是哪个呢？

为什么要重写这个？因为，我们问题分析里说了，当打成fat jar运行时，其结构如下：

[root@mini2 temp]# tree . ├── BOOT-INF │ ├── classes │ │ ├── application.properties │ │ ├── application.yml │ │ └── com │ │ └── example │ │ └── demo │ │ ├── CustomMiddleWareClassloader.class │ │ └── OrderServiceApplication.class │ └── lib │ ├── classmate-1.4.0.jar │ ├── common-v1-0.0.1-SNAPSHOT.jar │ ├── common-v2-0.0.1-SNAPSHOT.jar │ ├── hibernate-validator-6.0.17.Final.jar │ ├── jackson-annotations-2.9.0.jar │ ├── jackson-core-2.9.9.jar │ ├── jackson-databind-2.9.9.jar │ ├── jackson-datatype-jdk8-2.9.9.jar │ ├── jackson-datatype-jsr310-2.9.9.jar │ ├── jackson-module-parameter-names-2.9.9.jar │ ├── javax.annotation-api-1.3.2.jar │ ├── jboss-logging-3.3.2.Final.jar │ ├── jul-to-slf4j-1.7.26.jar │ ├── log4j-api-2.11.2.jar │ ├── log4j-to-slf4j-2.11.2.jar │ ├── logback-classic-1.2.3.jar │ ├── logback-core-1.2.3.jar │ ├── lombok-1.18.10.jar │ ├── middle-ware-0.0.1-SNAPSHOT.jar │ ├── middle-ware-api-0.0.1-SNAPSHOT.jar │ ├── slf4j-api-1.7.26.jar │ ├── snakeyaml-1.23.jar │ ├── spring-aop-5.1.9.RELEASE.jar │ ├── spring-beans-5.1.9.RELEASE.jar │ ├── spring-boot-2.1.7.RELEASE.jar │ ├── spring-boot-autoconfigure-2.1.7.RELEASE.jar │ ├── spring-boot-loader-2.1.7.RELEASE.jar │ ├── spring-boot-starter-2.1.7.RELEASE.jar │ ├── spring-boot-starter-json-2.1.7.RELEASE.jar │ ├── spring-boot-starter-logging-2.1.7.RELEASE.jar │ ├── spring-boot-starter-tomcat-2.1.7.RELEASE.jar │ ├── spring-boot-starter-web-2.1.7.RELEASE.jar │ ├── spring-context-5.1.9.RELEASE.jar │ ├── spring-core-5.1.9.RELEASE.jar │ ├── spring-expression-5.1.9.RELEASE.jar │ ├── spring-jcl-5.1.9.RELEASE.jar │ ├── spring-web-5.1.9.RELEASE.jar │ ├── spring-webmvc-5.1.9.RELEASE.jar │ ├── tomcat-embed-core-9.0.22.jar │ ├── tomcat-embed-el-9.0.22.jar │ ├── tomcat-embed-websocket-9.0.22.jar │ └── validation-api-2.0.1.Final.jar ├── META-INF │ ├── MANIFEST.MF │ └── maven │ └── com.example │ └── web-application │ ├── pom.properties │ └── pom.xml └── org └── springframework └── boot └── loader ├── archive │ ├── Archive.class │ ├── Archive$Entry.class │ ├── Archive$EntryFilter.class │ ├── ExplodedArchive$1.class │ ├── ExplodedArchive.class │ ├── ExplodedArchive$FileEntry.class │ ├── ExplodedArchive$FileEntryIterator.class │ ├── ExplodedArchive$FileEntryIterator$EntryComparator.class │ ├── JarFileArchive.class │ ├── JarFileArchive$EntryIterator.class │ └── JarFileArchive$JarFileEntry.class ├── data │ ├── RandomAccessData.class │ ├── RandomAccessDataFile$1.class │ ├── RandomAccessDataFile.class │ ├── RandomAccessDataFile$DataInputStream.class │ └── RandomAccessDataFile$FileAccess.class ├── ExecutableArchiveLauncher.class ├── jar │ ├── AsciiBytes.class │ ├── Bytes.class │ ├── CentralDirectoryEndRecord.class │ ├── CentralDirectoryFileHeader.class │ ├── CentralDirectoryParser.class │ ├── CentralDirectoryVisitor.class │ ├── FileHeader.class │ ├── Handler.class │ ├── JarEntry.class │ ├── JarEntryFilter.class │ ├── JarFile$1.class │ ├── JarFile$2.class │ ├── JarFile.class │ ├── JarFileEntries$1.class │ ├── JarFileEntries.class │ ├── JarFileEntries$EntryIterator.class │ ├── JarFile$JarFileType.class │ ├── JarURLConnection$1.class │ ├── JarURLConnection.class │ ├── JarURLConnection$JarEntryName.class │ ├── StringSequence.class │ └── ZipInflaterInputStream.class ├── JarLauncher.class ├── LaunchedURLClassLoader.class ├── LaunchedURLClassLoader$UseFastConnectionExceptionsEnumeration.class ├── Launcher.class ├── MainMethodRunner.class ├── PropertiesLauncher$1.class ├── PropertiesLauncher$ArchiveEntryFilter.class ├── PropertiesLauncher.class ├── PropertiesLauncher$PrefixMatchingArchiveFilter.class ├── util │ └── SystemPropertyUtils.class └── WarLauncher.class

BOOT-INF/lib下，是由同一个类加载器去加载的，而我们的V1和V2的jar包，全部混在这个目录下。

我们要想同时加载V1和V2的jar包，必须用两个类加载器来做隔离。

即，应用类加载器，不能加载V1；而中间件类加载器，只管加载V2，其他一概不能加载。

spring boot 的启动类

前面我们提到，启动类是org.springframework.boot.loader.JarLauncher，这个是在BOOT-INF/MANIFEST中指定了的。

这个类在哪里呢，一般在如下这个依赖中：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-loader</artifactId> </dependency>

该依赖，会在打包阶段，由maven插件，打到我们的fat jar中：

<build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build>

这个jar包，打到哪里去了呢？实际是解压后，放到fat jar的如下路径了，可以再去上面看看那个fat jar结构：

上面那个启动类，就是在这个里面。

启动类简单解析

先来看看uml：

先看看JarLauncher：

public class JarLauncher extends ExecutableArchiveLauncher { static final String BOOT_INF_CLASSES = "BOOT-INF/classes/"; static final String BOOT_INF_LIB = "BOOT-INF/lib/"; public JarLauncher() { } protected JarLauncher(Archive archive) { super(archive); } @Override protected boolean isNestedArchive(Archive.Entry entry) { if (entry.isDirectory()) { return entry.getName().equals(BOOT_INF_CLASSES); } return entry.getName().startsWith(BOOT_INF_LIB); } public static void main(String[] args) throws Exception { // 1 new JarLauncher().launch(args); }}

这里1处，new了自身，然后调用launch。

public abstract class Launcher { /** * Launch the application. This method is the initial entry point that should be * called by a subclass {@code public static void main(String[] args)} method. * @param args the incoming arguments * @throws Exception if the application fails to launch */ protected void launch(String[] args) throws Exception { JarFile.registerUrlProtocolHandler(); // 1 ClassLoader classLoader = createClassLoader(getClassPathArchives()); // 2 launch(args, getMainClass(), classLoader); }

1处这里，就是创建类加载器了，期间，先调用了getClassPathArchives。

我们看看：

org.springframework.boot.loader.Launcher#getClassPathArchives protected abstract List<Archive> getClassPathArchives() throws Exception;

这是个抽象方法，此处使用了模板方法设计模式，在如下类中实现了：

org.springframework.boot.loader.ExecutableArchiveLauncher#getClassPathArchives@Override protected List<Archive> getClassPathArchives() throws Exception { // 1 List<Archive> archives = new ArrayList<>(this.archive.getNestedArchives(this::isNestedArchive)); postProcessClassPathArchives(archives); return archives; }

此处的1处，不用深究，就是获取类加载器的classpath集合。我们这里打个断点，直接看下：

这里面细节就先不看了，主要就是拿到BOOT-INF/lib下的每个jar包。

然后我们继续之前的：

protected void launch(String[] args) throws Exception { JarFile.registerUrlProtocolHandler(); // 1 ClassLoader classLoader = createClassLoader(getClassPathArchives()); // 2 launch(args, getMainClass(), classLoader); }

现在getClassPathArchives已经ok了，接着就调用createClassLoader来创建类加载器了。

protected ClassLoader createClassLoader(List<Archive> archives) throws Exception { List<URL> urls = new ArrayList<>(archives.size()); for (Archive archive : archives) { urls.add(archive.getUrl()); } // 1 return createClassLoader(urls.toArray(new URL[0])); }

1处，继续调用内层函数，传入了url数组。

protected ClassLoader createClassLoader(URL[] urls) throws Exception { return new LaunchedURLClassLoader(urls, getClass().getClassLoader()); }

这里new了一个LaunchedURLClassLoader，参数就是url数组。我们看看这个类：

public class LaunchedURLClassLoader extends URLClassLoader { static { ClassLoader.registerAsParallelCapable(); } /** * Create a new {@link LaunchedURLClassLoader} instance. * @param urls the URLs from which to load classes and resources * @param parent the parent class loader for delegation */ public LaunchedURLClassLoader(URL[] urls, ClassLoader parent) { super(urls, parent); }

这个类，继承了URLClassLoader，所以，大家如果对类加载器有一定了解，就知道，URLClassLoader就是接收一堆的url，然后loadClass的时候，遵从双亲委派，双亲加载不了，就交给它，它就去url数组里，去加载class。

思路分析

我的打算是，修改fat jar中的启动类，为我们自定义的启动类。

Manifest-Version: 1.0 Implementation-Title: web-application Implementation-Version: 0.0.1-SNAPSHOT Start-Class: com.example.demo.OrderServiceApplication Spring-Boot-Classes: BOOT-INF/classes/ Spring-Boot-Lib: BOOT-INF/lib/ Build-Jdk-Spec: 1.8 Spring-Boot-Version: 2.1.7.RELEASE Created-By: Maven Archiver 3.4.0 // 1 Main-Class: com.example.demo.CustomJarLauncher

1处，指定我们自定义的class，这个class，我们会在打好fat jar后，手动拷贝进去。

然后，我们自定义启动类里面要干啥呢？

public class CustomJarLauncher extends JarLauncher { public static void main(String[] args) throws Exception { new CustomJarLauncher().launch(args); } @Override protected void launch(String[] args) throws Exception { JarFile.registerUrlProtocolHandler(); // 1 List<Archive> classPathArchives = getClassPathArchives(); /** * 2 */ List<URL> allURLs = classPathArchives.stream().map(entries -> { try { return entries.getUrl(); } catch (MalformedURLException e) { return null; } }).filter(Objects::nonNull).collect(Collectors.toList());// 3 List<URL> middleWareClassPathArchives = new ArrayList<>(); for (URL url : allURLs) { String urlPath = url.getPath(); if (urlPath == null) { continue; } boolean isMiddleWareJar = urlPath.contains("common-v1") || urlPath.contains("middle-ware"); if (isMiddleWareJar) { if (urlPath.contains("middle-ware-api")) { continue; } middleWareClassPathArchives.add(url); } } /** * 4 从全部的应用lib目录，移除中间件需要的jar包，但是，中间件的api不能移除 */ allURLs.removeAll(middleWareClassPathArchives);// 5 CustomLaunchedURLClassLoader loader = new CustomLaunchedURLClassLoader(allURLs.toArray(new URL[0]), getClass().getClassLoader()); loader.setMiddleWareClassPathArchives(middleWareClassPathArchives); launch(args, getMainClass(), loader); }}

1处，获取fat jar的lib目录下的全部包
2处，将1处得到的集合，转为url集合
3处，筛选出中间件的包，复制到单独的集合中，我这边有2个，直接写死了（毕竟是demo）
4处，将原集合中，移除中间件的jar包
5处，创建一个自定义的classloader，主要是方便我们存放中间件相关jar包集合

5处自定义的classloader，这里可以看下：

public class CustomLaunchedURLClassLoader extends LaunchedURLClassLoader { // 中间件jar包 List<URL> middleWareClassPathArchives;/** * Create a new {@link LaunchedURLClassLoader} instance. * * @param urls the URLs from which to load classes and resources * @param parent the parent class loader for delegation */ public CustomLaunchedURLClassLoader(URL[] urls, ClassLoader parent) { super(urls, parent); }public List<URL> getMiddleWareClassPathArchives() { return middleWareClassPathArchives; }public void setMiddleWareClassPathArchives(List<URL> middleWareClassPathArchives) { this.middleWareClassPathArchives = middleWareClassPathArchives; } }

最终，在我们的业务代码，要怎么去写呢？

我们现在自定义了一个类加载器，那么，后续业务代码都会由这个类加载器去加载。

我们再想想标题说的问题，我们是需要：加载中间件代码时，不能用这个类加载器去加载，因为这个类加载器中，已经排除了中间件相关jar包，是加载不到的。

此时，我们需要自定义一个classloader，去如下类中的middleWareClassPathArchives这个地方加载：

public class CustomLaunchedURLClassLoader extends LaunchedURLClassLoader { // 中间件jar包 List<URL> middleWareClassPathArchives; ... }

只有当它加载不到之后，才丢给应用类加载器去加载。

代码如下：

@SpringBootApplication @RestController @Slf4j public class OrderServiceApplication { /** * 中间件使用的classloader */ static ClassLoader delegatingClassloader;public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, IllegalAccessException { // 1 ClassLoader loader = Thread.currentThread().getContextClassLoader(); Method method = loader.getClass().getMethod("getMiddleWareClassPathArchives"); List<URL> middleWareUrls = (List<URL>) method.invoke(loader); // 2 delegatingClassloader = new CustomMiddleWareClassloader(middleWareUrls.toArray(new URL[0]), loader); // 3 SpringApplication.run(OrderServiceApplication.class, args); }

1，这里，我们要通过当前线程，拿到我们的类加载器，此时拿到的，肯定就是我们的自定义类加载器；然后通过反射方法，拿到中间件url集合，其实这里自己去拼这个url也可以，我们这里为了省事，所以就这么写；
2处，创建一个类加载器，主要就是给中间件代码使用，进行类加载器隔离。
注意，这里，我们把当前应用的类加载器，传给了这个中间件类加载器。

@Data @Slf4j public class CustomMiddleWareClassloader extends URLClassLoader { ClassLoader classLoader; public CustomMiddleWareClassloader(URL[] urls, ClassLoader parent) { super(urls); classLoader = parent; } @Override public Class<?> loadClass(String name) throws ClassNotFoundException { /** * 先自己来加载中间件相关jar包，这里调用findClass，就会去中间件那几个jar包加载class */ try { Class<?> clazz = findClass(name); if (clazz != null) { return clazz; } throw new ClassNotFoundException(name); } catch (Exception e) { /** * 在中间件自己的jar包里找不到，就交给自己的parent，此处即应用类加载器 */ return classLoader.loadClass(name); } }}

代码结构

中间件整体模块概览

在继续之前，有必要说下代码结构。

中间件总共三个jar包：

common-v1，middle-ware，middle-ware-api。

其中，middle-ware的pom如下：

中间件api模块

该模块无任何依赖，就是个接口

public interface IGisUtilInterface { String getFormattedDate(String date);}

该模块是很有必要的，该api模块必须由应用的类加载器加载，没错，是应用类加载器。

类似于servlet-api吧。

大家可以暂时这么记着，至于原因，那就有点长了。

可以参考：

不吹不黑，关于 Java 类加载器的这一点，市面上没有任何一本图书讲到

中间件实现模块

实现模块的pom：

<groupId>com.example</groupId> <artifactId>middle-ware</artifactId> <version>0.0.1-SNAPSHOT</version> <name>middle-ware</name><dependencies> <dependency> <groupId>com.example</groupId> <artifactId>middle-ware-api</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>com.example</groupId> <artifactId>common-v1</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency></dependencies>

里面只有一个类，就是实现api模块的接口。

@Slf4j public class GisUtilImpl implements IGisUtilInterface{ @Override public String getFormattedDate(String date) { String v1 = CommonDateUtil.format(date); log.info("invoke common v1,get result:{}", v1); return v1; }}

spring boot 的自定义loader模块

这部分和业务关系不大，主要就是自定义我们前面的那个fat jar启动类。

<groupId>com.example</groupId> <artifactId>custom-jar-launch</artifactId> <version>0.0.1-SNAPSHOT</version> <name>custom-jar-launch</name> <description>Demo project for Spring Boot</description><properties> <java.version>1.8</java.version> <spring-cloud.version>Greenwich.SR3</spring-cloud.version> </properties><dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.10</version> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-loader</artifactId> </dependency></dependencies>

这里有个特别的依赖：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-loader</artifactId> </dependency>

该模块，主要包含：

com.example.demo.CustomJarLauncher

com.example.demo.CustomLaunchedURLClassLoader

应用程序

<groupId>com.example</groupId> <artifactId>web-application</artifactId> <version>0.0.1-SNAPSHOT</version> <name>web-application</name> <description>Demo project for Spring Boot</description><dependencies> <dependency> <groupId>com.example</groupId> <artifactId>common-v2</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>com.example</groupId> <artifactId>middle-ware-api</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency> <dependency> <groupId>com.example</groupId> <artifactId>middle-ware</artifactId> <version>0.0.1-SNAPSHOT</version> </dependency>

模拟jar包冲突场景，此时，我们已经同时依赖了v1和v2了。

其测试代码如下：

public class OrderServiceApplication { /** * 中间件使用的classloader */ static ClassLoader delegatingClassloader;@RequestMapping("/") public void test() throws ClassNotFoundException, IllegalAccessException { // 1 Class<?> middleWareImplClass = delegatingClassloader.loadClass("com.example.demo.GisUtilImpl"); // 2 IGisUtilInterface iGisUtilInterface = (IGisUtilInterface) middleWareImplClass.newInstance(); // 3 String middleWareResult = iGisUtilInterface.getFormattedDate("version:"); log.info("middle ware result:{}",middleWareResult); // 4 String result = CommonDateUtil.format("version:"); log.info("application result:{}",result);}

1处，类似于servlet，也是把servlet实现类写死在web.xml的，我们这里也一样，把中间件的实现类写死了。
可能有更好的方式，暂时先这样。
2处，将实现类（中间件类加载器加载），转换为接口类（应用类加载器加载）。之所以要定义接口，这里很关键。
可以再仔细看看：
不吹不黑，关于 Java 类加载器的这一点，市面上没有任何一本图书讲到
3处，调用中间件代码
4处，调用应用代码

效果展示

2020-05-22 06:37:13.481 INFO 6676 --- [nio-8082-exec-1] com.example.demo.GisUtilImpl : invoke common v1,get result:version:- v1 2020-05-22 06:37:13.481 INFO 6676 --- [nio-8082-exec-1] c.example.demo.OrderServiceApplication : middle ware result:version:- v1 2020-05-22 06:37:13.482 INFO 6676 --- [nio-8082-exec-1] com.example.date.util.CommonDateUtil : v2 result:version:- v2 2020-05-22 06:37:13.482 INFO 6676 --- [nio-8082-exec-1] c.example.demo.OrderServiceApplication : application result:version:- v2

可以发现，中间件那里，是v1；而调用应用的方法，则是v2。

说明我们成功了。

我这里用arthas分析了下这个类：