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

前言

对spring boot本身启动原理的分析,请参考://www.jb51.net/article/141478.htm

Spring boot里的ClassLoader继承关系
可以运行下面提供的demo,分别在不同的场景下运行,可以知道不同场景下的Spring boot应用的ClassLoader继承关系。

https://github.com/hengyunabc/spring-boot-inside/tree/master/demo-classloader-context

分三种情况:

在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引入的
https://github.com/spring-projects/spring-boot/commit/87fe0b2adeef85c842c009bfeebac1c84af8a5d7

这个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会支持读取。但是从上面的继承结果,我们可以发现一个问题:

  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结构,否则不能找到根本原因

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

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

    前言 对spring boot本身启动原理的分析,请参考://www.jb51.net/article/141478.htm Spring boot里的ClassLoader继承关系 可以运行下面提供的demo,分别在不同的场景下运行,可以知道不同场景下的Spring boot应用的ClassLoader继承关系. https://github.com/hengyunabc/spring-boot-inside/tree/master/demo-classloader-context 分三种情况

  • Spring Boot中slf4j日志依赖关系示例详解

    前言 SpringBoot底层使用的是slf4j+logback来进行日志记录 把其他common-logging.log4j.java.util.logging转换为slf4j 下面这篇文章主要给大家介绍了关于Spring Boot slf4j日志依赖关系的相关内容,下面话不多说了,来一起看看详细的介绍吧 底层依赖关系 关系如何转化 底层通过偷梁换柱的方法,用jcl.jul.log4j中间转换包进行转化 如果要引入其他框架,必须将其中默认日志依赖剔除 SpringBoot从maven依赖中剔除

  • spring boot入门之诞生背景及优势影响

    目录 springboot诞生的背景 springboot改变了什么 SpringBoot主要特性 SpringBoot集成第三方类库的步骤 spring boot诞生的背景 在spring boot出现以前,使用spring框架的程序员是这样配置web应用环境的,需要大量的xml配置.下图展示了在xml配置的时代和SpringBoot的配置量的差别. 随着web项目集成软件的不断增多,xml配置也不断的增多,xml配置文件也在不断地增多,项目的依赖管理也越发的复杂.spring框架也因此饱受争

  • spring boot和spring cloud之间的版本关系

    什么是Spring Boot Spring Boot简化了基于Spring的应用开发,通过少量的代码就能创建一个独立的.产品级别的Spring应用. Spring Boot为Spring平台及第三方库提供开箱即用的设置,这样你就可以有条不紊地开始.多数Spring Boot应用只需要很少的Spring配置. Spring Boot是由Pivotal团队提供的全新框架,其设计目的是用来简化新Spring应用的初始搭建以及开发过程.该框架使用了特定的方式来进行配置,从而使开发人员不再需要定义样板化的

  • Spring Boot实战之逐行释义Hello World程序

    一.前言 研究Spring boot也有一小段时间了,最近会将研究东西整理一下给大家分享,大概会有10~20篇左右的博客,整个系列会以一个简单的博客系统作为基础,因为光讲理论很多东西不是特别容易理解,并且如果每次通过一个简单的小程序也无法系统的把握好一些知识点,所以就以一个简单的系统作为基础来讲,看看通过spring boot如何实现一个完整系统.本系列除了Spring boot基本的知识点之外,还会涉及到Spring boot与数据库.缓存(redis).消息队列等的结合以及多实例部署等方面的

  • Spring Boot利用Thymeleaf发送Email的方法教程

    前言 众所周知,现在在后台服务器中发送邮件已经是一个非常常用的功能了.通常来说虽然HTML并非是一个非常标准的信息格式,但是至少许多邮件客户端都至少支持一部分标记语言. 在这边教程中主要是关于教你如何在Spring Boot 应用中发送邮件以及使用非常简单强大的Thymeleaf模板引擎来制作邮件内容. 文章末尾附上源码,已经开源到Github上,是我公司做项目的时候处理邮件这一块用到的. 基本上覆盖了大部分邮件发送需求.稍微修改了一下,奉献给有需要的人.当你看完文章在看一下这封源码,你会对这一

  • 详解Spring Boot实战之Restful API的构建

    上一篇文章讲解了通过Spring boot与JdbcTemplate.JPA和MyBatis的集成,实现对数据库的访问.今天主要给大家分享一下如何通过Spring boot向前端返回数据. 在现在的开发流程中,为了最大程度实现前后端的分离,通常后端接口只提供数据接口,由前端通过Ajax请求从后端获取数据并进行渲染再展示给用户.我们用的最多的方式就是后端会返回给前端一个JSON字符串,前端解析JSON字符串生成JavaScript的对象,然后再做处理.本文就来演示一下Spring boot如何实现

  • Spring Boot使用Thymeleaf + Gradle构建war到Tomcat

    Spring Boot 以Jar的方式部署启动,这个不用介绍了, 之前也介绍了关于 Spring Boot + thymeleaf 的简单使用 ,但是今天遇到一个问题, 我先描述下问题的场景: 由于运维部门的需求,项目需要以war的形式放到tomcat运行 ,而不是原定的jar的方式运行 配置了一下午,也查了一下午的资料,以war的方式在Tomcat能运行,并且能访问Controller,但是在返回html视图时,找不到视图模板.最终发现问题在Thymeleaf的配置,话不多说,具体看操作步骤:

  • spring boot容器启动流程

    一.前言 spring cloud大行其道的当下,如果不了解基本原理那么是很纠结的(看见的都是 约定大于配置 ,但是原理呢?为什么要这么做?).spring cloud是基于spring boot快速搭建的,今天咱们就看看spring boot容器启动流程.(本文不讲解如何快速启动spring boot,那些直接官方看即可, 官网文档飞机票 ) 二.容器启动 spring boot一般是 指定容器启动main方法,然后以命令行方式启动Jar包 ,如下图: @SpringBootApplicati

  • Spring Boot 深入分析AutoConfigurationImportFilter自动化条件配置源码

    目录 1. AutoConfigurationImportFilter的作用 2. AutoConfigurationImportFilter UML类图说明 3. FilteringSpringBootCondition抽象类 4. AutoConfigurationImportSelector类 5. 总结 1. AutoConfigurationImportFilter的作用 之前讲解了SpringBoot的Conditional的自动化条件配置,我们分析了内部是如何具体实现,在整个实现当

随机推荐