文章篇幅较长,可是包含了SpringBoot 可执行jar包从头至尾的原理,请读者耐心观看。同时文章是基于
SpringBoot-2.1.3
进行分析。涉及的知识点主要包括Maven的生命周期以及自定义插件,JDK提供关于jar包的工具类以及Springboot如何扩展,最后是自定义类加载器。java
SpringBoot 的可执行jar包又称fat jar
,是包含全部第三方依赖的 jar 包,jar 包中嵌入了除 java 虚拟机之外的全部依赖,是一个 all-in-one jar 包。普通插件maven-jar-plugin
生成的包和spring-boot-maven-plugin
生成的包之间的直接区别,是fat jar
中主要增长了两部分,第一部分是lib目录,存放的是Maven依赖的jar包文件,第二部分是spring boot loader
相关的类。git
fat jar 目录结构
├─BOOT-INF
│ ├─classes
│ └─lib
├─META-INF
│ ├─maven
│ ├─app.properties
│ ├─MANIFEST.MF
└─org
└─springframework
└─boot
└─loader
├─archive
├─data
├─jar
└─util
复制代码
也就是说想要知道fat jar
是如何生成的,就必须知道spring-boot-maven-plugin
工做机制,而spring-boot-maven-plugin
属于自定义插件,所以咱们又必须知道,Maven的自定义插件是如何工做的github
Maven 拥有三套相互独立的生命周期: clean、default 和 site, 而每一个生命周期包含一些phase阶段, 阶段是有顺序的, 而且后面的阶段依赖于前面的阶段。生命周期的阶段phase与插件的目标goal相互绑定,用以完成实际的构建任务。web
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
复制代码
repackage
目标对应的将执行到org.springframework.boot.maven.RepackageMojo#execute
,该方法的主要逻辑是调用了org.springframework.boot.maven.RepackageMojo#repackage
spring
private void repackage() throws MojoExecutionException {
//获取使用maven-jar-plugin生成的jar,最终的命名将加上.orignal后缀
Artifact source = getSourceArtifact();
//最终文件,即Fat jar
File target = getTargetFile();
//获取从新打包器,将从新打包成可执行jar文件
Repackager repackager = getRepackager(source.getFile());
//查找并过滤项目运行时依赖的jar
Set<Artifact> artifacts = filterDependencies(this.project.getArtifacts(),
getFilters(getAdditionalFilters()));
//将artifacts转换成libraries
Libraries libraries = new ArtifactsLibraries(artifacts, this.requiresUnpack,
getLog());
try {
//提供Spring Boot启动脚本
LaunchScript launchScript = getLaunchScript();
//执行从新打包逻辑,生成最后fat jar
repackager.repackage(target, libraries, launchScript);
}
catch (IOException ex) {
throw new MojoExecutionException(ex.getMessage(), ex);
}
//将source更新成 xxx.jar.orignal文件
updateArtifact(source, target, repackager.getBackupFile());
}
复制代码
咱们关心一下org.springframework.boot.maven.RepackageMojo#getRepackager
这个方法,知道Repackager
是如何生成的,也就大体可以推测出内在的打包逻辑。json
private Repackager getRepackager(File source) {
Repackager repackager = new Repackager(source, this.layoutFactory);
repackager.addMainClassTimeoutWarningListener(
new LoggingMainClassTimeoutWarningListener());
//设置main class的名称,若是不指定的话则会查找第一个包含main方法的类,repacke最后将会设置org.springframework.boot.loader.JarLauncher
repackager.setMainClass(this.mainClass);
if (this.layout != null) {
getLog().info("Layout: " + this.layout);
//重点关心下layout 最终返回了 org.springframework.boot.loader.tools.Layouts.Jar
repackager.setLayout(this.layout.layout());
}
return repackager;
}
复制代码
/** * Executable JAR layout. */
public static class Jar implements RepackagingLayout {
@Override
public String getLauncherClassName() {
return "org.springframework.boot.loader.JarLauncher";
}
@Override
public String getLibraryDestination(String libraryName, LibraryScope scope) {
return "BOOT-INF/lib/";
}
@Override
public String getClassesLocation() {
return "";
}
@Override
public String getRepackagedClassesLocation() {
return "BOOT-INF/classes/";
}
@Override
public boolean isExecutable() {
return true;
}
}
复制代码
layout
咱们能够将之翻译为文件布局,或者目录布局,代码一看清晰明了,同时咱们须要关注,也是下一个重点关注对象org.springframework.boot.loader.JarLauncher
,从名字推断,这极可能是返回可执行jar
文件的启动类。springboot
Manifest-Version: 1.0
Implementation-Title: oneday-auth-server
Implementation-Version: 1.0.0-SNAPSHOT
Archiver-Version: Plexus Archiver
Built-By: oneday
Implementation-Vendor-Id: com.oneday
Spring-Boot-Version: 2.1.3.RELEASE
Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: com.oneday.auth.Application
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Created-By: Apache Maven 3.3.9
Build-Jdk: 1.8.0_171
复制代码
repackager
生成的MANIFEST.MF文件为以上信息,能够看到两个关键信息Main-Class
和Start-Class
。咱们能够进一步,程序的启动入口并非咱们SpringBoot中定义的main
,而是JarLauncher#main
,而再在其中利用反射调用定义好的Start-Class
的main
方法bash
java.util.jar.JarFile
JDK工具类提供的读取jar
文件org.springframework.boot.loader.jar.JarFile
Springboot-loader 继承JDK提供JarFile
类java.util.jar.JarEntry
DK工具类提供的``jar```文件条目org.springframework.boot.loader.jar.JarEntry
Springboot-loader 继承JDK提供JarEntry
类org.springframework.boot.loader.archive.Archive
Springboot抽象出来的统一访问资源的层
JarFileArchive
jar包文件的抽象ExplodedArchive
文件目录 这里重点描述一下JarFile
的做用,每一个JarFileArchive
都会对应一个JarFile
。在构造的时候会解析内部结构,去获取jar
包里的各个文件或文件夹类。咱们能够看一下该类的注释。app
/* Extended variant of {@link java.util.jar.JarFile} that behaves in the same way but
* offers the following additional functionality.
* <ul>
* <li>A nested {@link JarFile} can be {@link #getNestedJarFile(ZipEntry) obtained} based
* on any directory entry.</li>
* <li>A nested {@link JarFile} can be {@link #getNestedJarFile(ZipEntry) obtained} for
* embedded JAR files (as long as their entry is not compressed).</li>
**/ </ul>
复制代码
jar
里的资源分隔符是!/
,在JDK提供的JarFile
URL只支持一个’!/‘,而Spring boot扩展了这个协议,让它支持多个’!/‘,就能够表示jar in jar、jar in directory、fat jar的资源了。maven
首先须要关注双亲委派机制很重要的一点是,若是一个类能够被委派最基础的ClassLoader加载,就不能让高层的ClassLoader加载,这样是为了范围错误的引入了非JDK下可是类名同样的类。其二,若是在这个机制下,因为fat jar
中依赖的各个第三方jar
文件,并不在程序本身classpath
下,也就是说,若是咱们采用双亲委派机制的话,根本获取不到咱们所依赖的jar包,所以咱们须要修改双亲委派机制的查找class的方法,自定义类加载机制。
先简单的介绍Springboot2中LaunchedURLClassLoader
,该类继承了java.net.URLClassLoader
,重写了java.lang.ClassLoader#loadClass(java.lang.String, boolean)
,而后咱们再探讨他是如何修改双亲委派机制。
在上面咱们讲到Spring boot支持多个’!/‘以表示多个jar,而咱们的问题在于,如何解决查找到这多个jar包。咱们看一下LaunchedURLClassLoader
的构造方法。
public LaunchedURLClassLoader(URL[] urls, ClassLoader parent) {
super(urls, parent);
}
复制代码
urls
注释解释道the URLs from which to load classes and resources
,即fat jar包依赖的全部类和资源,将该urls
参数传递给父类java.net.URLClassLoader
,由父类的java.net.URLClassLoader#findClass
执行查找类方法,该类的查找来源即构造方法传递进来的urls参数
//LaunchedURLClassLoader的实现
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException {
Handler.setUseFastConnectionExceptions(true);
try {
try {
//尝试根据类名去定义类所在的包,即java.lang.Package,确保jar in jar里匹配的manifest可以和关联 //的package关联起来
definePackageIfNecessary(name);
}
catch (IllegalArgumentException ex) {
// Tolerate race condition due to being parallel capable
if (getPackage(name) == null) {
// This should never happen as the IllegalArgumentException indicates
// that the package has already been defined and, therefore,
// getPackage(name) should not return null.
//这里异常代表,definePackageIfNecessary方法的做用其实是预先过滤掉查找不到的包
throw new AssertionError("Package " + name + " has already been "
+ "defined but it could not be found");
}
}
return super.loadClass(name, resolve);
}
finally {
Handler.setUseFastConnectionExceptions(false);
}
}
复制代码
方法super.loadClass(name, resolve)
实际上会回到了java.lang.ClassLoader#loadClass(java.lang.String, boolean)
,遵循双亲委派机制进行查找类,而Bootstrap ClassLoader
和Extension ClassLoader
将会查找不到fat jar依赖的类,最终会来到Application ClassLoader
,调用java.net.URLClassLoader#findClass
Springboot2和Springboot1的最大区别在于,Springboo1会新起一个线程,来执行相应的反射调用逻辑,而SpringBoot2则去掉了构建新的线程这一步。方法是org.springframework.boot.loader.Launcher#launch(java.lang.String[], java.lang.String, java.lang.ClassLoader)
反射调用逻辑比较简单,这里就再也不分析,比较关键的一点是,在调用main
方法以前,将当前线程的上下文类加载器设置成LaunchedURLClassLoader
protected void launch(String[] args, String mainClass, ClassLoader classLoader) throws Exception {
Thread.currentThread().setContextClassLoader(classLoader);
createMainMethodRunner(mainClass, args, classLoader).run();
}
复制代码
public static void main(String[] args) throws ClassNotFoundException, MalformedURLException {
JarFile.registerUrlProtocolHandler();
// 构造LaunchedURLClassLoader类加载器,这里使用了2个URL,分别对应jar包中依赖包spring-boot-loader和spring-boot,使用 "!/" 分开,须要org.springframework.boot.loader.jar.Handler处理器处理
LaunchedURLClassLoader classLoader = new LaunchedURLClassLoader(
new URL[] {
new URL("jar:file:/E:/IdeaProjects/oneday-auth/oneday-auth-server/target/oneday-auth-server-1.0.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-loader-1.2.3.RELEASE.jar!/")
, new URL("jar:file:/E:/IdeaProjects/oneday-auth/oneday-auth-server/target/oneday-auth-server-1.0.0-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-2.1.3.RELEASE.jar!/")
},
Application.class.getClassLoader());
// 加载类
// 这2个类都会在第二步本地查找中被找出(URLClassLoader的findClass方法)
classLoader.loadClass("org.springframework.boot.loader.JarLauncher");
classLoader.loadClass("org.springframework.boot.SpringApplication");
// 在第三步使用默认的加载顺序在ApplicationClassLoader中被找出
classLoader.loadClass("org.springframework.boot.autoconfigure.web.DispatcherServletAutoConfiguration");
// SpringApplication.run(Application.class, args);
}
复制代码
<!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-loader -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-loader</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>2.1.3.RELEASE</version>
</dependency>
复制代码
对于源码分析,此次的较大收获则是不能一会儿去追求弄懂源码中的每一步代码的逻辑,即使我知道该方法的做用。咱们须要搞懂的是关键代码,以及涉及到的知识点。我从Maven的自定义插件开始进行追踪,巩固了对Maven的知识点,在这个过程当中甚至了解到JDK对jar的读取是有提供对应的工具类。最后最重要的知识点则是自定义类加载器。整个代码下来并非说代码究竟有多优秀,而是要学习他因何而优秀。
做者:plz叫我红领巾
本博客欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面明显位置给出原文链接,不然保留追究法律责任的权利。码字不易,您的点赞是我写做的最大动力。