当前位置： 移动技术网 > IT编程>开发语言>Java > 深入Spring Boot之ClassLoader的继承关系和影响

深入Spring Boot之ClassLoader的继承关系和影响

2019年07月19日  | 移动技术网IT编程  | 我要评论

前言

对spring boot本身启动原理的分析，请参考：

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=============
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下面。

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

这个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. 应用直接用自己的classloader.getresources()是可以获取到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*:**-service.xml 的通配问题

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

用户如果使用类似classpath*:**-service.xml的通配符来加载资源的话，很有可能出现在ide里跑时，可以正确加载，但是在fat jar下，却加载不到的问题。

从spring自己的文档可以看到相关的解析：

https://docs.spring.io/spring/docs/4.3.9.release/javadoc-api/org/springframework/core/io/support/pathmatchingresourcepatternresolver.html

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下面，所以这时通配就会失败。

总结

  1. 这个新的boot-inf打包格式有它的明显好处：更清晰，更接近war包的格式。
  2. spring boot的classloader的结构修改带来的复杂问题，并非当初修改的人所能预见的
  3. 很多问题需要理解spring boot的classloader结构，否则不能找到根本原因

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持移动技术网。

您可能感兴趣的文章:

如对本文有疑问， 点击进行留言回复！！

相关文章:

验证码：
最近更新的文章
大家感兴趣的文章
移动技术网