【转】深入Spring Boot：ClassLoader的继承关系和影响

最新推荐文章于 2024-03-21 17:27:12 发布
最新推荐文章于 2024-03-21 17:27:12 发布
阅读量294 收藏
点赞数
CC 4.0 BY-SA版权
文章标签： java
原文链接：https://my.oschina.net/werngin/blog/1930855
本文深入探讨SpringBoot中ClassLoader的继承关系，分析不同运行场景下的ClassLoaders结构，包括IDE直接运行、fatjar运行和解压目录运行。揭示了springboot1.3与1.4版本之间的区别及新结构对资源加载的影响。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

前言

对spring boot本身启动原理的分析，请参考：https://my.oschina.net/werngin/blog/1930848

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

1
2
3
4
5
6
 
========= 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运行

1
2
 
mvn clean package
java -jar target/demo-classloader-context-0.0.1-SNAPSHOT.jar

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

1
2
3
4
 
========= 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。

1
2
3
4
5
6
 
========= 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本身。

1
2
3
 
========= 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

以解压目录运行

1
2
3
4
5
 
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。

1
2
3
4
 
========= 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包。

1
2
3
4
5
6
 
========= 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只有当前目录：

1
2
3
 
========= 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-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会支持读取。但是从上面的继承结果，我们可以发现一个问题：

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

总结

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

转载于:https://my.oschina.net/werngin/blog/1930855

chengtun6091
关注
【Spring】Spring boot:注解@SpringBootApplication
九师兄
01-02 543
我们先来了解一下 @SpringBootApplication 是什么，以及如何在一个简单的 Spring Boot 应用程序中使用它。我们先看看 Spring Team 在源码中对它的定义是什么？表示一个配置类，它声明了一个或多个@Bean方法，也触发了自动配置和组件扫描。这是一个方便的注解，相当于声明了@Configuration、@EnableAutoConfiguration和@ComponentScan。从上面的定义我们可以看出，注解其实是一个组合注解。
Java：115-Spring Boot的底层原理（下篇）
qq_59609098的博客
07-22 1249
上述代码中，"xmlns:th="http://www.thymeleaf.org"用于引入Thymeleaf模板引擎标签，使用关键字"th"标注标签是Thymeleaf模板提供的标签，其中，"th:href"用于引入外联样式文件，"th:text"用于动态显示标签文本内容（没有则操作默认值，一般是标签里面的） 除此之外，Thymeleaf模板提供了很多标签，接下来，通过一张表罗列Thymeleaf的常用标签： 示例使用了Thymeleaf模板的变量表达式${…}用来动态获取P标签中的内容 如果当前程序没
深入Spring Boot之ClassLoader的继承关系和影响
08-27
主要介绍了深入Spring Boot之ClassLoader的继承关系和影响，小编觉得挺不错的，现在分享给大家，也给大家做个参考。一起跟随小编过来看看吧
深入Spring Boot：ClassLoader的继承关系和影响
weixin_33744854的博客
12-10 240
　　前言　　　　对spring boot本身启动原理的分析，　　　　Spring boot里的ClassLoader继承关系　　　　可以运行下面提供的demo，分别在不同的场景下运行，可以知道不同场景下的Spring boot应用的ClassLoader继承关系。　　　　分三种情况：　　　　在IDE里，直接run main函数　　　　则Spring的ClassLoader直接是SystemClas...
类加载器的继承结构
chenzhiyuan09的专栏
11-05 1443
类加载器的继承结构   类加载器的继承结构： Java类加器分类：                                           类的装载，连接，初始化 装载：  把二进制的java类读入到Java虚拟机中 连接：  把已读入虚拟机的二进制Java类数据合并到虚拟机的运行时状态中去          分为三步1.
Java 自定义classloader 最简单的实现就是继承URLClassLoader
修也
05-06 2321
package demo; import java.io.File; import java.net.MalformedURLException; import java.net.URISyntaxException; import java.net.URL; import java.net.URLClassLoader; import java.util.Arrays; import co...
继承classLoader加载一个class文件demo
u014609356的专栏
01-22 875
public class Loader extends ClassLoader{ private String classPath; private String classname="Test"; public Loader(String classPath){ this.classPath=classPath; } @Override protected Class f
Spring Boot：基本应用和源码解析
bier_zm的博客
11-13 2016
SpringBoot 基本应用 约定优于配置 约定优于配置（Convention over Configuration），又称按约定编程，是一种软件设计范式。 本质上是说，系统、类库或框架应该假定合理的默认值，而非要求提供不必要的配置。比如说模型中有一个名为 User 的类，那么数据库中对应的表就会默认命名为 User。只有在偏离这一个约定的时候，例如想要将该表命名为 person，才需要写有关这个名字的配置。 比如平时架构师搭建项目就是限制软件开发随便写代码，制定出一套规范，让开发人员按统一的要求
Spring Boot：基本应用，源码解析，数据访问和视图技术
qq_40286307的博客
11-07 917
SpringBoot 基本应用 约定优于配置 约定优于配置（Convention over Configuration），又称按约定编程，是一种软件设计范式。 本质上是说，系统、类库或框架应该假定合理的默认值，而非要求提供不必要的配置。比如说模型中有一个名为 User 的类，那么数据库中对应的表就会默认命名为 User。只有在偏离这一个约定的时候，例如想要将该表命名为 person，才需要写有关这个名字的配置。 比如平时架构师搭建项目就是限制软件开发随便写代码，制定出一套规范，让开发人员按统一的要求进行开发
类加载机制之ClassLoader
04stone37
09-15 647
基础知识 JVM如何区分不同类型？ JVM通过类全名+加载该类的ClassLoader区分的； 同一个ClassLoader能够重复加载同一个类？同一个ClassLoader不允许多次加载一个类的，否则会报java.lang.LinkageError； JVM只提供了加载类的方法，但并没有提供卸载的方法（主动回收，可预期），当发生FGC时才被回收（被动回收，不可预期）； ClassLo...
JVM之ClassLoader
pure_adoration的博客
09-04 228
      ClassLoader的继承关系是从 BootStrapClassLoader开始的，也是由它最先加载类，然后是 ExtClassLoader，接下来是 AppClassLoader（应用程序默认的），最后是用户自己的ClassLoader（通常在容器下编写代码，都是由容器自定义创建的 ClassLoader创建的类）。 （1） Bootstrapclass Loader主要用于加载一...
02-类加载子系统
海涛帅帅的博客
09-26 171
内存结构概述 内存图 类加载器与类的加载过程 类加载子系统作用 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射） 类加载ClassLoader角色
ClassLoader详解
u010457514的博客
08-27 620
1.Java中的ClassLoader 1.1 CLassLoader的类型 Java的类加载器主要有两种类型，即系统类加载器和自定义类加载器。系统类加载器包括3中，分别是Bootstrap ClassLoader,Extensions ClassLoader和Application ClassLoader。 Bootstrap ClassLoader（引导类加载器） C/C++代码实现的加载器，...
ClassLoader类解析
weixiaohuai的博客
09-03 1050
目录 一、概述 二、ClassLoader的主要方法 三、SecureClassLoader与URLClassLoader 四、ExtClassLoader与AppClassLoader 五、Class.forName()与ClassLoader.loadClass() 六、 loadClass()方法解析 一、概述 ClassLoader类继承关系图如下： 除了以上虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所.
4、类加载器
weixin_45817985的博客
03-21 639
类加载器
java classLoader机制解析
小小懒羊羊
04-01 2107
类从被加载到虚拟机内存中开始，到卸装出内存为止，它的整个生命周期包括了:加载，连接(验证，准备，解析)，初始化，使用和卸载七个阶段。其中验证、准备和解析三个部分称为连接，也就是说，一个Java类从字节代码到能够在JVM中被使用，需要经过加载、链接和初始化这三个步骤 。
Android进阶解密读书笔记（十一）——理解 ClassLoader
qq_29639599的博客
08-28 746
定义一个自定义 ClassLoader 并继承抽象类 ClassLoader复写 findClass 方法，并在 findClass 方法中调用 defineClass 方法。
JVM之类加载子系统
成长永远没有尽头
05-17 387
类加载子系统的结构 作用 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。 ClassIoader只负责class文件的加载，至于它是否可以运行，则由ExecutionEngine决定。 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射） 扮演的角色 类加载子系统主要负责将磁盘上...
Java 面试准备3 JVM和类加载器
藏经阁
09-20 184
众所周知，Java 是面向对象的一门语言 绝大部分的东西都是以class类的形式存在的 甚至连把.class文件加载进JVM的类加载器（class loader）都是一个类 那有人就会问了，那第一个类加载器是怎么来的呢？ 这个和鸡生蛋，蛋生鸡的问题就不一样了~ 这个是有明确答案的 首先，JVM 是用C++ 写的（这里指的是 SUN 的默认JVM HotSpot） （维基百科上查的） HotSpot is written in C++ （大家可以在命令行下输入） java -version 应该会看到
金蝶Apusic应用服务器V9来部署一个基于Spring Boot和Vue的网站
最新发布
03-12
<think>好的，我现在需要帮助用户解决如何在金蝶Apusic应用服务器V9上部署Spring Boot和Vue构建的网站的问题。首先，我得回顾用户提供的引用内容，看看有没有相关的配置步骤。 用户提供的引用[1]中提到了一个SpringBootServletInitializer的子类，这是为了将Spring Boot应用打包成WAR文件，并部署到外部的Servlet容器中，比如金蝶AAS。所以，我需要确认用户是否已经将Spring Boot应用正确配置为生成WAR包，并且处理了启动类。 引用[2]提到需要在金蝶的web.xml中添加一个上下文参数，允许解析Multipart请求。这可能涉及到文件上传的配置，避免出现相关错误。此外，用户可能需要将Vue项目构建后的静态文件整合到Spring Boot的静态资源目录中，或者单独部署到Apusic服务器上。 接下来，我应该分步骤来整理部署流程。首先是后端Spring Boot的调整，包括修改pom.xml为war包，创建SpringBootServletInitializer的子类，确保应用可以正确初始化。然后处理可能的依赖冲突，特别是排除内嵌的Tomcat，避免与Apusic的依赖冲突。 然后是Vue前端部分的处理，需要构建生产环境的静态文件，通常使用npm run build生成dist目录。这些静态文件需要放到Spring Boot的src/main/resources/static目录下，这样打包WAR时会包含进去。或者，如果前端和后端分开部署，可能需要将静态文件部署到Apusic的指定目录，并配置反向代理。 接下来是金蝶AAS的配置部分，用户需要将生成的WAR包部署到服务器上，可能需要通过管理控制台进行操作。同时，需要按照引用[2]的说明修改web.xml，添加上下文参数apusic.allowCasualMultipartParsing为true，确保文件上传功能正常。 可能遇到的问题包括依赖冲突、路径配置错误、静态资源无法访问等，需要检查日志文件来排查问题。此外，如果使用JSP或其他视图技术，可能需要额外的配置，但Vue作为前端框架可能不需要。 最后，生成相关的问题，比如如何打包Spring Boot为WAR，如何处理跨域问题，或者如何配置金蝶AAS的虚拟主机等，这些都能帮助用户进一步了解部署过程中的其他方面。</think>### 金蝶Apusic V9部署Spring Boot+Vue网站教程 #### 一、后端Spring Boot调整 1. **修改打包方式为WAR** 在`pom.xml`中添加： ```xml <packaging>war</packaging> ``` 并排除内嵌Tomcat依赖： ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency> ``` 2. **继承`SpringBootServletInitializer`** 创建`ApplicationServletInitializer`类（如引用[1]所示）： ```java public class ApplicationServletInitializer extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(YourSpringBootApplication.class); } } ``` #### 二、Vue前端部署配置 1. **构建生产环境代码** 执行`npm run build`生成`dist`目录，将内容复制到Spring Boot的静态资源目录`src/main/resources/static`中。 2. **配置反向代理（可选）** 若前后端分离部署，需在金蝶AAS中配置反向代理，将API请求转发到Spring Boot后端端口。 #### 三、金蝶Apusic V9配置 1. **修改`web.xml`** 按照引用[2]的要求，在金蝶域配置的`config/web.xml`中添加： ```xml <context-param> <param-name>apusic.allowCasualMultipartParsing</param-name> <param-value>true</param-value> </context-param> ``` 2. **部署WAR文件** - 将生成的WAR包放入金蝶AAS的`domains/yourdomain/autodeploy`目录 - 通过管理控制台（`http://localhost:6888/console`）手动部署 #### 四、验证部署 1. 访问`http://服务器IP:端口/上下文路径`查看Vue页面 2. 检查后端API接口是否正常响应 **典型问题排查**： - 依赖冲突：检查`apusic-classloader.log`中的类加载错误 - 静态资源404：确认`dist`文件已打包到WAR的`WEB-INF/classes/static`目录 - 文件上传失败：确认`web.xml`参数已生效[^2]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值