深刻Spring Boot：ClassLoader的继承关系和影响

前言

对spring boot自己启动原理的分析，请参考：http://hengyunabc.github.io/s...

Spring boot里的ClassLoader继承关系

能够运行下面提供的demo，分别在不一样的场景下运行，能够知道不一样场景下的Spring boot应用的ClassLoader继承关系。

https://github.com/hengyunabc...

分三种状况：

在IDE里，直接run main函数

则Spring的ClassLoader直接是SystemClassLoader。ClassLoader的urls包含所有的jar和本身的target/classes

========= Spring Boot Application ClassLoader Urls =============

ClassLoader urls: sun.misc.Launcher$AppClassLoader@2a139a55

file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/classes/

file:/Users/hengyunabc/.m2/repository/org/springframework/cloud/spring-cloud-starter/1.1.9.RELEASE/spring-cloud-starter-1.1.9.RELEASE.jar

file:/Users/hengyunabc/.m2/repository/org/springframework/boot/spring-boot-starter/1.4.7.RELEASE/spring-boot-starter-1.4.7.RELEASE.jar

...

以fat jar运行

mvn clean package

java -jar target/demo-classloader-context-0.0.1-SNAPSHOT.jar

执行应用的main函数的ClassLoader是LaunchedURLClassLoader，它的parent是SystemClassLoader。

========= ClassLoader Tree=============

org.springframework.boot.loader.LaunchedURLClassLoader@1218025c

- sun.misc.Launcher$AppClassLoader@6bc7c054

-- sun.misc.Launcher$ExtClassLoader@85ede7b

而且LaunchedURLClassLoader的urls是 fat jar里的BOOT-INF/classes!/目录和BOOT-INF/lib里的全部jar。

========= Spring Boot Application ClassLoader Urls =============

ClassLoader urls: org.springframework.boot.loader.LaunchedURLClassLoader@1218025c

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/classes!/

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-1.4.7.RELEASE.jar!/

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-web-4.3.9.RELEASE.jar!/

...

SystemClassLoader的urls是demo-classloader-context-0.0.1-SNAPSHOT.jar自己。

========= System ClassLoader Urls =============

ClassLoader urls: sun.misc.Launcher$AppClassLoader@6bc7c054

file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo-classloader-context-0.0.1-SNAPSHOT.jar

以解压目录运行

mvn clean package

cd target

unzip demo-classloader-context-0.0.1-SNAPSHOT.jar -d demo

cd demo

java org.springframework.boot.loader.PropertiesLauncher

执行应用的main函数的ClassLoader是LaunchedURLClassLoader，它的parent是SystemClassLoader。

========= ClassLoader Tree=============

org.springframework.boot.loader.LaunchedURLClassLoader@4aa298b7

- sun.misc.Launcher$AppClassLoader@2a139a55

-- sun.misc.Launcher$ExtClassLoader@1b6d3586

LaunchedURLClassLoader的urls是解压目录里的BOOT-INF/classes/和/BOOT-INF/lib/下面的jar包。

========= Spring Boot Application ClassLoader Urls =============

ClassLoader urls: org.springframework.boot.loader.LaunchedURLClassLoader@4aa298b7

file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/classes/

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/bcpkix-jdk15on-1.55.jar!/

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/bcprov-jdk15on-1.55.jar!/

jar:file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/BOOT-INF/lib/classmate-1.3.3.jar!/

SystemClassLoader的urls只有当前目录：

========= System ClassLoader Urls =============

ClassLoader urls: sun.misc.Launcher$AppClassLoader@2a139a55

file:/Users/hengyunabc/code/java/spring-boot-inside/demo-classloader-context/target/demo/

其实还有两种运行方式： mvn spring-boot:run 和 mvn spring-boot:run -Dfork=true，可是比较少使用，不单独讨论。感受兴趣的话能够自行跑下。

总结spring boot里ClassLoader的继承关系

• 在IDE里main函数执行时，只有一个ClassLoader，也就是SystemClassLoader
• 在以fat jar运行时，有一个LaunchedURLClassLoader，它的parent是SystemClassLoader

  LaunchedURLClassLoader的urls是fat jar里的BOOT-INF/classes和BOOT-INF/lib下的jar。SystemClassLoader的urls是fat jar自己。

• 在解压目录（exploded directory）运行时，和fat jar相似，不过url都是目录形式。目录形式会有更好的兼容性。

spring boot 1.3. 和 1.4. 版本的区别

在spring boot 1.3.* 版本里

• 应用的类和spring boot loader的类都是打包在一个fat jar里
• 应用依赖的jar放在fat jar里的/lib下面。

在spring boot 1.4.* 版本后

• spring boot loader的类放在fat jar里
• 应用的类打包放在fat jar的BOOT-INF/classes目录里
• 应用依赖的jar放在fat jar里的/lib下面。

spring boot 1.4的打包结构改动是这个commit引入的

https://github.com/spring-pro...

这个commit的本意是简化classloader的继承关系，以一种直观的parent优先的方式来实现LaunchedURLClassLoader，同时打包结构和传统的war包应用更接近。

可是这个改动引发了不少复杂的问题，从上面咱们分析的ClassLoader继承关系就有点头晕了。

目前的ClassLoader继承关系带来的一些影响

有不少用户可能会发现，一些代码在IDE里跑得很好，可是在实际部署运行时不工做。不少时候就是ClassLoader的结构引发的，下面分析一些案例。

demo.jar!/BOOT-INF/classes!/ 这样子url不工做

由于spring boot是扩展了标准的jar协议，让它支持多层的jar in jar，还有directory in jar。参考spring boot应用启动原理分析

在spring boot 1.3的时候尽管会有jar in jar，可是一些比较健壮的代码能够处理这种状况，好比tomcat8本身就支持jar in jar。

可是绝大部分代码都不会支持像demo.jar!/BOOT-INF/classes!/ 这样子directory in jar的多重url，因此在spring boot1.4里，不少库的代码都会失效。

demo.jar!/META-INF/resources 下的资源问题

在servlet 3.0规范里，应用能够把静态资源放在META-INF/resources下面，servlet container会支持读取。可是从上面的继承结果，咱们能够发现一个问题：

• 应用以fat jar来启动，启动embedded tomcat的ClassLoader是LaunchedURLClassLoader
• LaunchedURLClassLoader的urls并无fat jar自己
• 应用的main函数所在的模块的src/main/resources/META-INF/resources目录被打包到了fat jar里，也就是demo.jar!/META-INF/resources
• 应用的fat jar是SystemClassLoader的url，也就是LaunchedURLClassLoader的parent

这样子就形成了一些奇怪的现象：

• 应用直接用本身的ClassLoader.getResources()是能够获取到META-INF/resources的资源的
• 可是embedded tomcat并无把fat jar自己加入到它的 ResourcesSet 里，由于它在启动时ClassLoader是LaunchedURLClassLoader，它只扫描本身的ClassLoader的urls
• 应用把资源放在其它的jar包的META-INF/resources下能够访问到，把资源放在本身的main函数的src/main/resources/META-INF/resources下时，访问不到了

另外，spring boot的官方jsp的例子只支持war的打包格式，不支持fat jar，也是由这个引发的。

getResource("") 和 getResources("") 的返回值的问题

getResource("")的语义是返回ClassLoader的urls的第一个url，不少时候使用者觉得这个就是它们本身的classes的目录，或者是jar的url。

可是实际上，由于ClassLoader加载urls列表时，有随机性，和OS低层实现有关，并不能保证urls的顺序都是同样的。因此getResource("")不少时候返回的结果并不同。

可是不少库，或者应用依赖这个代码来定位扫描资源，这样子在spring boot下就不工做了。

另外，值得注意的是spring boot在三种不一样形式下运行，getResources("")返回的结果也不同。用户能够本身改下demo里的代码，打印下结果。

简而言之，不要依赖这两个API，最好本身放一个资源来定位。或者直接利用spring自身提供的资源扫描机制。

相似 classpath*:**-service.xml 的通配问题

用户有多个代码模块，在不一样模块下都放了多个*-service.xml的spring配置文件。

用户若是使用相似classpath*:**-service.xml的通配符来加载资源的话，颇有可能出如今IDE里跑时，能够正确加载，可是在fat jar下，却加载不到的问题。

从spring本身的文档能够看到相关的解析：

https://docs.spring.io/spring...

WARNING: Note that "classpath :" when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like "classpath:*.xml" will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK's ClassLoader.getResources() method which only returns file system locations for a passed-in empty String (indicating potential roots to search). This ResourcePatternResolver implementation is trying to mitigate the jar root lookup limitation through URLClassLoader introspection and "java.class.path" manifest evaluation; however, without portability guarantees.

就是说使用 classpath*来匹配其它的jar包时，须要有一层目录在前面，否则的话是匹配不到的，这个是ClassLoader.getResources() 函数致使的。

由于在IDE里跑时，应用所依赖的其它模块一般就是一个classes目录，因此一般没有问题。

可是当以fat jar来跑时，其它的模块都被打包为一个jar，放在BOOT-INF/lib下面，因此这时通配就会失败。

总结

• 这个新的BOOT-INF打包格式有它的明显好处：更清晰，更接近war包的格式。
• spring boot的ClassLoader的结构修改带来的复杂问题，并不是当初修改的人所能预见的
• 不少问题须要理解spring boot的ClassLoader结构，不然不能找到根本缘由

微信公众号

横云断岭的专栏