你瞭解SpringBoot java -jar 的啓動原理嗎？

時間 2020-06-14

標籤瞭解 springboot java jar 啓動原理欄目 Spring 简体版

原文原文鏈接

電話面試中，面試官問了一個問題：你知道 java -jar 啓動 Spring Boot 項目，和傳統的 jar 有什麼不同的嗎？java

問題大概是這樣，當時不太清楚怎麼回答，面試結束以後知道面試估計是掛了，請教了一下面試官這個問題應該從哪方面去考慮呢？nginx

大概記得面試官說，... 自定義類加載器知道嗎？ ...（中間一些內容就沒聽進去了）git

我：原來是從這方面去考慮呀，感謝面試官的指點！github

過後趕忙學了學，也走讀了下啓動過程的源碼，終於知道他說的自定義類加載器了，也就知道他問這個問題的目的所在了。面試

凡是你接觸過一點點 Spring Boot 項目，你必定知道經過 java -jar xxx.jar 命令便能把一個 Spring Boot 服務啓動起來。（若是你還沒接觸過，這裏的內容能夠往後再看，先輕微瞭解一下 Spring Boot 項目的玩法）spring

一個看似簡陋的 java -jar 究竟幹了什麼，就把我們手寫的應用（我們的項目可能叫 XXXApplication.java）啓動了呢？segmentfault

這就是本文的目的，解讀一下 java -jar 都作了什麼。數組

至少面試的時候能搭上話，能說兩句，不會像我同樣只能哦哦哦的。。。springboot

先有個概覽

瞭解一個技術點，直接扎到源碼堆裏，雲裏霧裏，很難受，容易讓人望而生畏。
這時候能夠先從總體或者非源碼的角度瞭解一下它的運做機制，內心有個底，若是再感興趣，就能夠找一些細節，慢慢擊破，可能效果更好，更能讓人堅持下去。app

這也是我後面準備學習源碼的思路，就寫一下。

雖然也是這樣勸本身，但是仍是看不懂，尷尬了，哈哈哈...

我們就先拿這個java -jar xxx.jar來講：

Spring Boot 在可執行 Fat jar 包中定義了本身的一套規則，好比第三方依賴 jar 包在 /lib目錄下，jar 包的 URL 路徑使用自定義的規則而且這個規則須要使用 org.springframework.boot.loader.jar.Handler 處理器處理。

Fat jar 的 Main-Class 使用 org.springframework.boot.loader.JarLauncher，也就是執行java -jar xxx.jar首先會觸發 JarLauncher的main方法的執行，而不是我們的應用的xxx.xxx.xxx.XXXApplication。

不過不用急，JarLauncher#main 會執行一些邏輯，作一些物料準備，最終會觸發我們的 XXXApplication#main 啓動應用。

先看個啓動過程概覽，往後研究不會慌！

還不會畫時序圖，不搞個呢又感受少了些直觀的東西，就勉強搞了個，這張圖的主要目的是提供啓動過程的調用關係。

怕時序圖表達不夠完善，再把簡要代碼貼一下，哈哈。。。

提示：後面的東西須要一些耐心。

瞭解一些 Spring Boot 的抽象概念

瞭解一下 Spring Boot Loader 所抽象出來的一些概念，對走讀 Spring Boot loader 源碼有些幫助

Launcher：各類 Launcher 的基礎抽象類，用於啓動應用程序，跟Archive配合使用。

目前有3種實現，分別是

JarLauncher
WarLauncher
PropertiesLauncher

繼承關係以下

Archive：歸檔文件的基礎抽象類。

JarFileArchive 就是 jar 包文件的抽象。
它提供了一些方法好比 getUrl 會返回這個 Archive 對應的 URL。getManifest 方法會得到 Manifest 數據等。
ExplodedArchive 是文件目錄的抽象。

JarFile：對 jar 包的封裝，每一個 JarFileArchive 都會對應一個 JarFile。JarFile 被構造的時候會解析內部結構，去獲取 jar 包裏的各個文件或文件夾，這些文件或文件夾會被封裝到 Entry 中，也存儲在 JarFileArchive 中。若是 Entry 是個jar，會解析成 JarFileArchive。

JarFile是Springboot-loader 繼承 JDK JarFile提供的類。

好比一個 JarFileArchive 對應的URL爲：

jar:file:C:\Users\Administrator\Desktop\demo\demo\target\jarlauncher-0.0.1-SNAPSHOT.jar!/

它對應的 JarFile 爲：

C:\Users\Administrator\Desktop\demo\demo\target\jarlauncher-0.0.1-SNAPSHOT.jar

這個 JarFile 有不少Entry，好比：

META-INF/
META-INF/MANIFEST.MF
......
BOOT-INF/lib/spring-boot-starter-1.5.10.RELEASE.jar
BOOT-INF/lib/spring-boot-1.5.10.RELEASE.jar
...

JarFileArchive 內部的一些依賴 jar 對應的 URL

（SpringBoot 使用 org.springframework.boot.loader.jar.Handler 處理器來處理這些URL）

jar:file:C:/Users/Administrator/Desktop/demo/demo/target/jarlauncher-0.0.1-SNAPSHOT.jar!/lib/spring-boot-1.5.10.RELEASE.jar!/

jar:file:C:/Users/Administrator/Desktop/demo/demo/target/jarlauncher-0.0.1-SNAPSHOT.jar!/lib/spring-boot-1.5.10.RELEASE.jar!/org/springframework/boot/loader/JarLauncher.class

咱們看到若是有 jar 包中包含 jar，或者 jar 包中包含 jar 包裏面的 class 文件，那麼會使用 !/ 分隔開，這種方式只有 org.springframework.boot.loader.jar.Handler 能處理，它是 SpringBoot 內部擴展出來一種URL協議（其實這個很是重要，對於後面說的自定義加載器，拓展URL協議是基石）。

可執行 jar 目錄結構

注意：我們以 Spring Boot 1.5.10 版原本分析

原本想直接用 Spring Boot 2.3.x 做爲 debug 環境的，也看了一圈網文，發現比 2.3.x 比 1.x 版本多了一些概念，好比分層的JarModel，本身又不會，弄過來直接搪塞過去也不太好，就先放棄了，最終使用不算太老的 1.5.10 版本。

SpringBoot 提供了一個插件 spring-boot-maven-plugin 用於把程序打包成一個可執行的jar包。

在 pom 文件里加入這個插件便可：

<build>
    <plugins>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

而後咱們在 Terminal 執行 maven package 打包完生成的 jarlauncher-0.0.1-SNAPSHOT.jar （咱們稱之爲 Fat jar）內部的結構以下：

├─BOOT-INF
│  ├─classes
│  │  └─application.properties
│  │  └─com
│  │      └─example
│  │          └─jarlauncher
│  │              └─JarlauncherApplication.class
│  └─lib
│      ├─spring-boot-1.5.10.RELEASE.jar
│      ├─spring-boot-loader-1.5.10.RELEASE.jar
│      ├─.......
├─META-INF
│  └─MANIFEST.MF
│  └─maven
│      └─com.example
│          └─demo
│              ├─pom.properties
│              ├─pom.xml
└─org
    └─springframework
        └─boot
            └─loader
                ├─ExecutableArchiveLauncher.class
                ├─JarLauncher.class
                ├─LaunchedURLClassLoader.class
                ├─Launcher.class
                ├─MainMethodRunner.class
            └─......

打包出來 fat jar 內部有三個文件夾：

META-INF 文件夾：程序入口，其中 MANIFEST.MF（資源清單）用於描述 jar 包的信息
BOOT-INF 目錄：放置咱們的程序代碼和第三方依賴的jar包
org目錄：Spring Boot loader 相關的源代碼，咱們程序啓動就靠他了

MANIFEST.MF文件的內容：

Manifest-Version: 1.0
Implementation-Title: demo
Implementation-Version: 0.0.1-SNAPSHOT
Archiver-Version: Plexus Archiver
Built-By: Administrator
Implementation-Vendor-Id: com.example
Spring-Boot-Version: 1.5.10.RELEASE
Implementation-Vendor: Pivotal Software, Inc.
Main-Class: org.springframework.boot.loader.JarLauncher
Start-Class: com.example.jarlauncher.JarlauncherApplication
Spring-Boot-Classes: BOOT-INF/classes/
Spring-Boot-Lib: BOOT-INF/lib/
Created-By: Apache Maven 3.5.2
Build-Jdk: 1.8.0_162
Implementation-URL: http://projects.spring.io/spring-boot/demo/

咱們看到，它的 Main-Class 是 org.springframework.boot.loader.JarLauncher，當咱們使用 java -jar 執行jar包的時候會調用 JarLauncher 的main方法，而不是調用咱們編寫的 com.example.jarlauncher.JarlauncherApplication。

接下來我們走讀一下代碼，看看實際怎麼運行的吧！

JarLauncher的執行過程

提示：走讀的時候時不時結合概覽中的時序圖，可能好些。

JarLauncher 的 main 方法：

public static void main(String[] args) {
    // 構造JarLauncher，而後調用它的launch方法
    new JarLauncher().launch(args);
}

JarLauncher 被構造的時候會調用父類 ExecutableArchiveLauncher 的構造方法。

ExecutableArchiveLauncher 的構造方法內部會去構造 Archive，這裏構造了 JarFileArchive。構造JarFileArchive的過程當中還會構造不少東西，好比JarFile，Entry …

public abstract class ExecutableArchiveLauncher extends Launcher {
    private final Archive archive;
    // 構造器會初始化表明 fat jar 的 Archive
    public ExecutableArchiveLauncher() {
        this.archive = createArchive();
    }
    // 由父類 Launcher 實現
    protected final Archive createArchive() throws Exception {
        ProtectionDomain protectionDomain = getClass().getProtectionDomain();
        CodeSource codeSource = protectionDomain.getCodeSource();
        URI location = (codeSource == null ? null : codeSource.getLocation().toURI());
        String path = (location == null ? null : location.getSchemeSpecificPart());
        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);
        }
        // 最終會 new 一個 Arichive，內部生產的 JarFile-->這個逼對FatJar資源加載很是重要
        return (root.isDirectory() ? new ExplodedArchive(root)
                : new JarFileArchive(root));
    }
    
    @Override
    protected List<Archive> getClassPathArchives() throws Exception {
        List<Archive> archives = new ArrayList<Archive>(
            // 獲取內部全部有的 Arichive
            this.archive.getNestedArchives(new EntryFilter() {
                @Override
                public boolean matches(Entry entry) {
                    return isNestedArchive(entry);
                }
            }));
        // 空實現，沒用
        postProcessClassPathArchives(archives);
        return archives;
    }

}

JarLauncher 的 launch方法：

protected void launch(String[] args) {
  try {
// 在系統屬性中設置註冊了自定義的URL協議處理器：org.springframework.boot.loader.jar.Handler。
// 初始化URL的時候，若是URL中沒有指定處理器，會去系統屬性中查詢
    JarFile.registerUrlProtocolHandler();
// getClassPathArchives方法會去找lib目錄下對應的第三方依賴JarFileArchive，同時也會找項目自身的JarFileArchive
// 根據getClassPathArchives獲得的JarFileArchive集合去建立類加載器ClassLoader。這裏會構造一個LaunchedURLClassLoader類加載器，這個類加載器繼承URLClassLoader，並使用這些JarFileArchive集合的URL構形成URLClassPath
// 多說兩句句，
// 1.URLClassPath這個屬性很重要，自定義ClassLoader，findClass就靠它了！
// 2.能夠關注一下構造LaunchedURLClassLoader時，archive.getUrl方法，這裏就涉及到自定義URL協議處理器了，JarFile等。畢竟實現jar in jar功能靠他們這些小羅羅。
    ClassLoader classLoader = createClassLoader(getClassPathArchives());
// getMainClass方法會去項目自身的Archive中的Manifest中找出key爲Start-Class的類
// 調用重載方法launch
    launch(args, getMainClass(), classLoader);
  }
  catch (Exception ex) {
    ex.printStackTrace();
    System.exit(1);
  }
}

// Archive的getMainClass方法，不過由ExecutableArchiveLauncher實現
// 這裏會找出Start-Class標識的com.example.jarlauncher.JarlauncherApplication這個類
public String getMainClass() throws Exception {
    Manifest manifest = 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;
}

// launch重載方法
protected void launch(String[] args, String mainClass, ClassLoader classLoader)
    throws Exception {
    // 設置 LaunchedURLClassLoader 爲線程上下文加載器
    Thread.currentThread().setContextClassLoader(classLoader);
    // 建立一個MainMethodRunner 並運行
    createMainMethodRunner(mainClass, args, classLoader).run();
}

MainMethodRunner 的 run 方法：

public void run() throws Exception {
    // 使用線程上下文類加載器加載主類
    Class<?> mainClass = Thread.currentThread().getContextClassLoader()
    .loadClass(this.mainClassName);
    // 反射執行，至此我們的應用程序就啓動起來啦，good，啓動流程走讀結束，開心！能夠跟面試官扯些了
    Method mainMethod = mainClass.getDeclaredMethod("main", String[].class);
    mainMethod.invoke(null, new Object[] { this.args });
}

Start-Class的main方法調用以後，內部會構造Spring容器，啓動內置Servlet容器等過程（後面的就不說了，不是本文關注的點，何況也沒細研究呢😂）

好了，到這裏我們已經把 java -jar 的啓動過程總體瞭解了一遍，開心吧！

關於自定義的類加載器

看看傳說中的 LaunchedURLClassLoader有什麼神奇的

LaunchedURLClassLoader 重寫了 loadClass 方法，走讀一下

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
    Handler.setUseFastConnectionExceptions(true);
    try {
        try {
            // 在調用 findClass 以前定義 package，確保嵌套JAR清單與包相關聯
            definePackageIfNecessary(name);
        }
        catch (IllegalArgumentException ex) {
            if (getPackage(name) == null) {
                throw new AssertionError("Package " + name + " has already been "
                        + "defined but it could not be found");
            }
        }
        // 調用 父類 loadClass 走正常的加載委派流程
        return super.loadClass(name, resolve);
    }
    finally {
        Handler.setUseFastConnectionExceptions(false);
    }
}

其實只看上面 1.5.10 版本的 loadClass 實現，毫無亮點，基本就是普通的雙親委派過程。
並且 LaunchedURLClassLoader 使用的 findClass 是從父類 URLClassLoader 繼承的。

最終 loadClass 會走到 LaunchedURLClassLoader 的父類 URLClassLoader#findClass

protected Class<?> findClass(final String name)
        throws ClassNotFoundException
{
    final Class<?> result;
    try {
        result = AccessController.doPrivileged(
                new PrivilegedExceptionAction<Class<?>>() {
                    public Class<?> run() throws ClassNotFoundException {
// 把類名解析成路徑並加上.class後綴                         
                        String path = name.replace('.', '/').concat(".class");
// 基於以前獲得的第三方jar包依賴以及本身的jar包獲得URL數組，進行遍歷找出對應類名的資源
// 好比path是org/springframework/boot/loader/JarLauncher.class，它在jar:file:/Users/Format/Develop/gitrepository/springboot-analysis/springboot-executable-jar/target/executable-jar-1.0-SNAPSHOT.jar!/lib/spring-boot-loader-1.3.5.RELEASE.jar!/中被找出
// 那麼找出的資源對應的URL爲jar:file:/Users/Format/Develop/gitrepository/springboot-analysis/springboot-executable-jar/target/executable-jar-1.0-SNAPSHOT.jar!/lib/spring-boot-loader-1.3.5.RELEASE.jar!/org/springframework/boot/loader/JarLauncher.class                        
                    // 加載fatjar class的關鍵部分！！！
                    Resource res = ucp.getResource(path, false);
                    if (res != null) { // 找到了資源
                        try {
                            return defineClass(name, res);
                        } catch (IOException e) {
                            throw new ClassNotFoundException(name, e);
                        }
                    } else {
                        throw new ClassNotFoundException(name);
                    }
                }
            }, acc);
    } catch (java.security.PrivilegedActionException pae) {
        throw (ClassNotFoundException) pae.getException();
    }
    if (result == null) {
        throw new ClassNotFoundException(name);
    }
    return result;
}

上面的findClass 的過程，都是在關鍵代碼 Resource res = ucp.getResource(path, false); 這裏完成的。

ucp 也即 JDK 提供的 sun.misc.URLClassPath

又畫了個圖，能夠看到URLClassPath#getResource涉及哪些基礎組件支持。

會用到 URL，URLStreamHandler，org.springframework.boot.loader.jar.Handler，最終獲取到 Resource，完成 class load。

因此，
我的結論：LaunchedURLClassLoader 是藉助他山之力，關鍵還在於 Spring Boot 對 URL jar 協議的拓展，Archeive，JarFile 的抽象

LaunchedURLClassLoader 加載測試

我們手動模擬一下 JarLauncher 的加載過程，建立 LaunchedURLClassLoader，而後加載個類試試好很差使？

public class LaunchedURLClassLoaderTest {
    public static void main(String[] args) throws Exception {
        // 註冊org.springframework.boot.loader.jar.Handler URL協議處理器
        JarFile.registerUrlProtocolHandler();
        // 構造LaunchedURLClassLoader類加載器，這裏使用了1個URL，對應jar包中依賴包spring-boot-loader       
        // 會使用 org.springframework.boot.loader.jar.Handler 處理器處理
        LaunchedURLClassLoader classLoader = new LaunchedURLClassLoader(
                new URL[]{
                        new URL("jar:file:C:/Users/Administrator/Desktop/demo/demo/target/jarlauncher-0.0.1-SNAPSHOT.jar!/BOOT-INF/lib/spring-boot-loader-1.5.10.RELEASE.jar!/")
                },
                DemoApplication.class.getClassLoader());
        // 加載類
        classLoader.loadClass("org.springframework.boot.loader.JarLauncher");
    }
}

把這個 case 跑通以後，JarLauncher 的啓動流程就沒啥問題了吧？

贈送一個 IDEA Debug Fat Jar 啓動的環境

說了這麼多啓動流程，如何才能直觀的 debug 到 Spring Boot Loader 的執行過程呢？

下面我們就來作這事，很簡單，幾分鐘搞定。

代碼準備

直接在 start.spring.io 初始化一個的 SpringBoot 應用就行，版本改爲 1.5.10。

我這給個 Git 代碼模板吧，點擊去克隆

注意一點，maven 要添加 spring-boot-loader 的依賴，一塊兒打到 jar 裏去。

<!-- Spring Boot loader        -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-loader</artifactId>
</dependency>

而後 mvn package，把應用打包成可執行 jar。