深⼊SpringBoot之ClassLoader的继承关系和影响
前⾔
Spring boot⾥的ClassLoader继承关系
可以运⾏下⾯提供的demo，分别在不同的场景下运⾏，可以知道不同场景下的Spring boot应⽤的ClassLoader继承关系。分三种情况：
在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=============
springcloud和springboot
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.* 版本⾥
1. 应⽤的类和spring boot loader的类都是打包在⼀个fat jar⾥
2. 应⽤依赖的jar放在fat jar⾥的/lib下⾯。
3. 在spring boot 1.
4.* 版本后
spring boot loader的类放在fat jar⾥
1. 应⽤的类打包放在fat jar的BOOT-INF/classes⽬录⾥
2. 应⽤依赖的jar放在fat jar⾥的/lib下⾯。
这个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 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会⽀持读取。但是从上⾯的继承结果，我们可以发现⼀个问题：
1. 应⽤以fat jar来启动，启动embedded tomcat的ClassLoader是LaunchedURLClassLoader
2. LaunchedURLClassLoader的urls并没有fat jar本⾝
3. 应⽤的main函数所在的模块的src/main/resources/META-INF/resources⽬录被打包到了fat jar⾥，也就是
demo.jar!/META-INF/resources
4. 应⽤的fat jar是SystemClassLoader的url，也就是LaunchedURLClassLoader的parent
这样⼦就造成了⼀些奇怪的现象：
1. 应⽤直接⽤⾃⼰的Resources()是可以获取到META-INF/resources的资源的
2. 但是embedded tomcat并没有把fat jar本⾝加⼊到它的 ResourcesSet ⾥，因为它在启动时ClassLoader是
LaunchedURLClassLoader，它只扫描⾃⼰的ClassLoader的urls
3. 应⽤把资源放在其它的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*:**-l 的通配问题
⽤户有多个代码模块，在不同模块下都放了多个*-l的spring配置⽂件。
⽤户如果使⽤类似classpath*:**-l的通配符来加载资源的话，很有可能出现在IDE⾥跑时，可以正确加载，但是在fat jar下，却加载不到的问题。
从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'Resources() 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包时，需要有⼀层⽬录在前⾯，不然的话是匹配不到的，这个是
因为在IDE⾥跑时，应⽤所依赖的其它模块通常就是⼀个classes⽬录，所以通常没有问题。
但是当以fat jar来跑时，其它的模块都被打包为⼀个jar，放在BOOT-INF/lib下⾯，所以这时通配就会失败。
总结
1. 这个新的BOOT-INF打包格式有它的明显好处：更清晰，更接近war包的格式。
2. spring boot的ClassLoader的结构修改带来的复杂问题，并⾮当初修改的⼈所能预见的
3. 很多问题需要理解spring boot的ClassLoader结构，否则不能到根本原因
以上就是本⽂的全部内容，希望对⼤家的学习有所帮助，也希望⼤家多多⽀持。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。