前面在 WebMvc 的部分咱有解析过，打war包运行，使用外部Servlet容器启动 SpringBoot 应用时，需要一个 ServletInitializer 来引导启动 SpringBoot 应用。那在使用jar包启动时，咱只是知道会走主启动类的 main 方法，但那是在开发时直接指定走主启动类的 main 方法，在jar包启动时是另一种方式。咱这最后一篇就来看看jar包启动 SpringBoot 应用的原理。
翻开打好的jar包，会发现3个文件夹：
BOOT-INF：存放自己编写并编译好的 .class 文件和静态资源文件、配置文件等
META-INF：有一个 MANIFEST.MF 的文件
org：spring-boot-loader 的一些 .class 文件
其中，org.springframework.boot.loader 里开始能找到 .class 文件了。
翻看 META-INF 下面的 MANIFEST.MF 文件，发现里面的内容如下：
Manifest-Version: 1.0
Implementation-Title: demo
Implementation-Version: 0.0.1-SNAPSHOT
Start-Class: com.example.demo.DemoApplication
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Build-Jdk-Spec: 1.8
Spring-Boot-Version: 2.1.9.RELEASE
Created-By: Maven Archiver 3.4.0
Main-Class:org.springframework.boot.loader.JarLauncher
这个文件中有两个值得关注的：
在 Start-Class 中注明了 SpringBoot 的主启动类
在 Main-Class 中注明了一个类： JarLauncher
如果能靠 SpringBoot 的主启动类完成应用的启动，那为什么还要标注下面的那个 JarLauncher 呢？
1. JarLauncher是什么东西
public class JarLauncher extends ExecutableArchiveLauncher {
static final String BOOT_INF_CLASSES = "BOOT-INF/classes/";
static final String BOOT_INF_LIB = "BOOT-INF/lib/";
public JarLauncher() {
}
protected JarLauncher(Archive archive) {
super(archive);
}
@Override
protected boolean isNestedArchive(Archive.Entry entry) {
if (entry.isDirectory()) {
return entry.getName().equals(BOOT_INF_CLASSES);
}
return entry.getName().startsWith(BOOT_INF_LIB);
}
public static void main(String[] args) throws Exception {
new JarLauncher().launch(args);
}
}
发现有个 main 方法！而且上面定义了两个常量，恰好就是在jar包中 BOOT-INF 里面的两个部分：自己的源码，和第三方jar包。
2. 测试直接启动两个带main方法的类
2.1 SpringBootApplication
错误: 找不到或无法加载主类 **com.example.demo.DemoApplication**
发现启动失败，根本就找不到这个类。
2.2 JarLauncher
能正常启动，打印 Banner 等。
3. 【拓展】主启动类无法正常引导启动的原理
用正常的指令启动时，java 指令没有指定 classpath，而当前 SpringBoot 应用依赖的jar包均放在 BOOT-INF/lib 下，这部分无法被识别。
3.1 标准jar包的启动规范
在可执行jar包中，有一个规范：被标记为Main-Class的类必须连同自己的包，直接放在jar包的最外层（没有额外的文件夹包含）。
SpringBootApplication 的位置："BOOT-INF/classes/com.example.demo.DemoApplication.class"
JarLauncher 的位置："org.springframework.boot.loader.JarLauncher"
所以 JarLauncher 能引导成功，而直接运行主启动类却无法成功启动。
这也解释了另外一个现象：
SpringBoot 在打jar包时，没有直接将 spring-boot-loader 包直接依赖到lib目录，而是将这个包下面的所有 .class 文件都复制到要打的jar包中。
3.2 标准jar包的内嵌jar规范
可执行jar包中还有一个规范：jar包中原则上不允许嵌套jar包。
传统的打jar包的方式是将所有依赖的jar包都复制到一个新的jar包中。这样会出现一个致命问题：
如果两个不同的jar包中有一个全限定类名相同的文件，会出现覆盖现象。
SpringBoot 使用自定义的 ClassLoader，可以解决这个问题，具体的部分要剖析源码才能看到实现机制。
4. JarLauncher的main方法都做了什么
public static void main(String[] args) throws Exception {
new JarLauncher().launch(args);
}
只有这一句，而且从上面的源码中可以发现，调用的空参数构造方法没有任何实际作用，也没有调父类的构造方法。
那一切的功能都在 launch 方法中。launch 方法不在 JarLauncher 里，在父类的 Launcher 内有定义：
// 这个方法是一个入口点，且应该被一个public static void main(String[] args)调用
protected void launch(String[] args) throws Exception {
//注册URL协议并清除应用缓存
JarFile.registerUrlProtocolHandler();
//设置类加载路径
ClassLoader classLoader = createClassLoader(getClassPathArchives());
//执行main方法
launch(args, getMainClass(), classLoader);
}
从文档注释可以发现，这个方法必须被 main 方法调用，这跟上面的 JarLauncher 中 main 方法直接调用一致。
4.1 registerUrlProtocolHandler
private static final String MANIFEST_NAME = "META-INF/MANIFEST.MF";
private static final String PROTOCOL_HANDLER = "java.protocol.handler.pkgs";
private static final String HANDLERS_PACKAGE = "org.springframework.boot.loader";
public static void registerUrlProtocolHandler() {
String handlers = System.getProperty(PROTOCOL_HANDLER, "");
System.setProperty(PROTOCOL_HANDLER,
("".equals(handlers) ? HANDLERS_PACKAGE : handlers + "|" + HANDLERS_PACKAGE));
resetCachedUrlHandlers();
}
// 重置任何缓存的处理程序，以防万一已经使用了jar协议。
// 我们通过尝试设置null URLStreamHandlerFactory来重置处理程序，除了清除处理程序缓存之外，它应该没有任何效果。
private static void resetCachedUrlHandlers() {
try {
URL.setURLStreamHandlerFactory(null);
}
catch (Error ex) {
// Ignore
}
}
先设置当前系统的一个变量 **java.protocol.handler.pkgs**，而这个变量的作用，是设置 URLStreamHandler 实现类的包路径。
之后要重置缓存，目的是清除之前启动的残留（文档注释已标明）。
4.2 createClassLoader
它要来创建 ClassLoader，而创建之前先调了 getClassPathArchives 方法来取一些 Archive 对象。
protected ClassLoader createClassLoader(List<Archive> archives) throws Exception {
List<URL> urls = new ArrayList<>(archives.size());
for (Archive archive : archives) {
urls.add(archive.getUrl());
}
return createClassLoader(urls.toArray(new URL[0]));
}
4.2.1 getClassPathArchives
protected List<Archive> getClassPathArchives() throws Exception {
List<Archive> archives = new ArrayList<>(this.archive.getNestedArchives(this::isNestedArchive));
postProcessClassPathArchives(archives);
return archives;
}
从最后看起，isNestedArchive 方法在调用时要传入 Archive.Entry，而这个参数的来源尚不明确，先搁置一边。
往前看，有一个 this.archive，而这个 archive 的成员属性是在这个类创建时被调用的。
private final Archive archive;
public ExecutableArchiveLauncher() {
try {
this.archive = createArchive();
}
catch (Exception ex) {
throw new IllegalStateException(ex);
}
}
protected final Archive createArchive() throws Exception {
ProtectionDomain protectionDomain = getClass().getProtectionDomain();
CodeSource codeSource = protectionDomain.getCodeSource();
URI location = (codeSource != null) ? codeSource.getLocation().toURI() : null;
String path = (location != null) ? location.getSchemeSpecificPart() : null;
if (path == null) {
throw new IllegalStateException("Unable to determine code source archive");
}
File root = new File(path);
if (!root.exists()) {
throw new IllegalStateException("Unable to determine code source archive from " + root);
}
return (root.isDirectory() ? new ExplodedArchive(root) : new JarFileArchive(root));
}
Archive 对象最终创建在下面的 createArchive 方法。
到 File root = new File 之前的部分，这段代码都是在找当前类的所在jar包的绝对路径
之后下面把这个文件创建出来，并以此创建一个 JarFileArchive 对象。
而这个 JarFileArchive 是 Archive 的子类，这个 Archive 就可以被 Launcher 启动。文档注释和类定义：
/**
* An archive that can be launched by the Launcher
*/
public interface Archive extends Iterable<Archive.Entry>
恰巧从 Archive 中得到一个意外收获：Archive 里的 Archive.Entry 可以被迭代！
跟前面的那个方法引用刚好能对应上了。
isNestedArchive 方法传入的参数就是 archive 对象中的那一组 Entry 对象（一个 Entry 相当于一个 "File"）。
4.2.2 getNestedArchives
public List<Archive> getNestedArchives(EntryFilter filter) throws IOException {
List<Archive> nestedArchives = new ArrayList<>();
for (Entry entry : this) {
if (filter.matches(entry)) {
nestedArchives.add(getNestedArchive(entry));
}
}
return Collections.unmodifiableList(nestedArchives);
}
archive 对象要执行 getNestedArchives 时，会传入一个 EntryFilter，以此来获取一组被嵌套的 Archive 。
而这个 EntryFilter 的工作机制就是上面的 isNestedArchive 方法，在 JarLauncher 中也有定义：
protected boolean isNestedArchive(Archive.Entry entry) {
if (entry.isDirectory()) {
return entry.getName().equals(BOOT_INF_CLASSES);
}
return entry.getName().startsWith(BOOT_INF_LIB);
}
很明显，看看是不是 BOOT-INF/lib 开头的jar包，如果不是，看看是不是 BOOT-INF/classes 文件夹。
这部分的意义正好跟前面测试主启动类与 JarLauncher 的启动相呼应：
位于 BOOT-INF/classes 的启动类需要后续被扫描到，才能被处理。
由此可见，得到的 archives 集合就是 **BOOT-INF/classes** 与 **BOOT-INF/lib** 下面的所有文件。
4.2.3 postProcessClassPathArchives
// 在使用之前调用后处理存档条目。实现可以添加和删除Entry。
protected void postProcessClassPathArchives(List<Archive> archives) throws Exception {
}
这个后置处理的方法是空的，且没有子类重写，说明默认就是拿 **BOOT-INF/classes** 与 **BOOT-INF/lib** 下面的文件了。
4.3 createClassLoader
// 为指定的归档文件创建一个类加载器
protected ClassLoader createClassLoader(List<Archive> archives) throws Exception {
List<URL> urls = new ArrayList<>(archives.size());
for (Archive archive : archives) {
urls.add(archive.getUrl());
}
return createClassLoader(urls.toArray(new URL[0]));
}
protected ClassLoader createClassLoader(URL[] urls) throws Exception {
return new LaunchedURLClassLoader(urls, getClass().getClassLoader());
}
上面部分的源码很容易可以看出是将每个 Archive 的绝对路径保存到一个 List 中，之后调用下面的 createClassLoader 方法。
下面直接创建了一个 LaunchedURLClassLoader，传入的 ClassLoader 很明显是默认的，也就是 AppClassLoader 。
4.3.1 构造方法
public LaunchedURLClassLoader(URL[] urls, ClassLoader parent) {
super(urls, parent);
}
很简单，直接调用父类的构造方法（指定 ClassLoader 是双亲委托机制）
而 LaunchedURLClassLoader 的父类是： java.net.URLClassLoader ，是jdk内部的 ClassLoader，不再深入描述。
4.4 launch
launch(args, getMainClass(), classLoader);
调用 launch 之前会先调用 getMainClass 方法获取主启动类。
protected String getMainClass() throws Exception {
Manifest manifest = this.archive.getManifest();
String mainClass = null;
if (manifest != null) {
mainClass = manifest.getMainAttributes().getValue("Start-Class");
}
if (mainClass == null) {
throw new IllegalStateException("No 'Start-Class' manifest entry specified in " + this);
}
return mainClass;
}
它要从 Launcher 类的成员 archive 中获取 Manifest 文件，这个文件就是之前在 META-INF 下面的 MANIFEST.MF 文件。
之后从这个文件中取出 Start-Class 的值，这个值就是主启动类的全限定类名。
之后调用 launch 方法：
// 根据一个Archive文件和一个完全配置好的ClassLoader启动应用。
protected void launch(String[] args, String mainClass, ClassLoader classLoader) throws Exception {
Thread.currentThread().setContextClassLoader(classLoader);
createMainMethodRunner(mainClass, args, classLoader).run();
}
先设置当前线程的上下文类加载器为新的类加载器，也就是 LaunchedURLClassLoader （默认为 AppClassLoader）。
之后要开始创建 main 方法的运行器，并运行。
4.5 mainMethodRunner.run
protected MainMethodRunner createMainMethodRunner(String mainClass, String[] args, ClassLoader classLoader) {
return new MainMethodRunner(mainClass, args);
}
简单的创建了 MainMethodRunner 的对象，之后上面会调用 run 方法。
MainMethodRunner 的结构：
// 用于Launcher调用main方法的辅助类。使用当前线程上下文类加载器加载包含main方法的类。
public class MainMethodRunner {
private final String mainClassName;
private final String[] args;
public MainMethodRunner(String mainClass, String[] args) {
this.mainClassName = mainClass;
this.args = (args != null) ? args.clone() : null;
}
public void run() throws Exception {
Class<?> mainClass = Thread.currentThread().getContextClassLoader().loadClass(this.mainClassName);
Method mainMethod = mainClass.getDeclaredMethod("main", String[].class);
mainMethod.invoke(null, new Object[] { this.args });
}
}
核心是 run 方法。
先拿到当前线程的上下文类加载器，就是 LaunchedURLClassLoader 。
之后用这个 ClassLoader 加载主启动类，之后运行 main 方法。
这也解释了为什么 SpringBoot 应用在开发期间只需要写 main 方法，引导启动即可。
