從 1 開始學 JVM 系列

類載入器，對於很多人來說並不陌生。我自己第一次聽到這個概念時覺得有點“高大上”，覺得只有深入 JDK 原始碼才會觸碰到 ClassLoader，平時都是傳聞中的東西。

今天，就讓我們一起來探索一下這”傳聞“中的類載入器，看看它是何方神聖。

類生命週期

在正式聊類載入器之前，我們先正本清源，看看類的生命週期是什麼樣的。

為了方便後續解讀，下面我貼了一張圖展示了類的生命週期的 7 個步驟。

對於前 5 步，簡單來說就是載入、連結、初始化，這是一個類最關鍵的載入步驟。

對照著上圖，我們逐一來解釋一下。

  1. 載入(Loading)：找 Class 檔案
  2. 驗證(Verification)：驗證格式、依賴
  3. 準備(Preparation)：靜態欄位、方法表
  4. 解析(Resolution)：符號解析為引用
  5. 初始化(Initialization)：構造器、靜態變數賦值、靜態程式碼塊
  6. 使用(Using)
  7. 解除安裝(Unloading)

1.載入

所謂的載入，就是查詢位元組流，並根據位元組流建立類的過程。

  • 對於陣列類，它沒有對應的位元組流，是由 Java 虛擬機器直接生成的。
  • 對於其他的類，Java 虛擬機器需要藉助類載入器來完成查詢位元組流的過程。

以蓋房子為例，Jack 想要要蓋個房子，按照流程他要先找個建築師，跟他說想要設計一個房型，比如說“一房一廳兩衛”。這裡的房型就相當於類，而建築師就相當於類載入器。

啟動類載入器

建築界有許多的建築師，他們等級分明，但都有著共同的祖師爺，叫「啟動類載入器（boot class loader）」。由於啟動類載入器是由 C++ 實現的，沒有對應的 Java 物件，因此在 Java 中只能用 null 來指代。

// jdk中 BootstrapClass 是 native 實現

private native Class<?> findBootstrapClass(String name);

但是，祖師爺不喜歡像 Jack 這樣的小角色來打擾他，所以誰也沒有祖師爺的聯絡方式，也就相當於 null 指代。

除了啟動類載入器之外，其他的類載入器都是 java.lang.ClassLoader 的子類，有對應的 Java 物件。這些類載入器需要先由另一個類載入器，比如說啟動類載入器，載入至 Java 虛擬機器中，方能執行類載入。

雙親委派模型

建築師界有個潛規則：接到單子後自己不能著手幹，得先給師傅過過目。師傅不接手的情況下，才能自己來。即等級高的師傅有優先選擇權。

在 Java 虛擬機器中，這個潛規則就是「雙親委派模型」。每當一個類載入器接收到載入請求時，它會先將請求轉發給父類載入器。在父類載入器沒有找到請求的類時，這個類載入器才會嘗試去載入。

載入器型別

載入器型別(Java 9 之前) 作用 載入路徑
啟動類載入器 負責載入最為基礎、最為重要的類 比如存放在 JRE 的 lib 目錄下 jar 包中的類（以及由虛擬機器引數 -Xbootclasspath 指定的類）
擴充套件類載入器 （extension class loader） 父類載入器是啟動類載入器。它負責載入相對次要、但又通用的類 比如存放在 JRE 的 lib/ext 目錄下 jar 包中的類（以及由系統變數 java.ext.dirs 指定的類）
應用類載入器 （application class loader） 父類載入器則是擴充套件類載入器。它負責載入應用程式路徑下的類。 預設情況下，應用程式中包含的類便是由應用類載入器載入的 這裡的應用程式路徑，便是指虛擬機器引數 -cp/-classpath、系統變數 java.class.path 或環境變數 CLASSPATH 所指定的路徑。

Java 9 引入了模組系統，並且略微更改了上述的類載入器。擴充套件類載入器被改名為「平臺類載入器（platform class loader）」。Java SE 中除了少數幾個關鍵模組，比如說 java.base 是由啟動類載入器載入之外，其他的模組均由平臺類載入器所載入。

除了由 Java 核心類庫提供的類載入器外，我們還可以加入「自定義類載入器」，實現特殊的載入方式。

舉個例子，我們可以對 class 檔案進行加密，載入時再利用自定義類載入器對其解密。

類載入器的名稱空間

除了載入功能之外，類載入器還提供了「名稱空間」的作用。

打個比方，假設建築界不講版權，如果某個人剽竊了另一個建築師的設計作品，只要你標上自己的名字，這兩個房型就是不同的。

在 Java 虛擬機器中，類的唯一性是由類載入器例項以及類的全名一同確定的。即便是同一串位元組流，經由不同的類載入器載入，也會得到兩個不同的類。

在大型應用中，我們往往藉助這一特性，來運行同一個類的不同版本。

2.連結

連結，是指將建立好的類合併至 Java 虛擬機器中，使之能夠執行的過程。它可分為驗證、準備以及解析三個階段。

    1. 「驗證」階段的目的，在於確保被載入類能夠滿足 Java 虛擬機器的約束條件。

    這就好比 Jack 需要將設計好的房型提交給市政部門稽核。只有當稽核通過，才能繼續下面的建造工作。

    通常而言，Java 編譯器生成的類檔案必然滿足 Java 虛擬機器的約束條件。

  • 2.「準備」階段的目的，則是為被載入類的靜態欄位分配記憶體。Java 程式碼中對靜態欄位的具體初始化，則會在稍後的初始化階段中進行。

    過了這個階段，算是蓋好了毛坯房。雖然結構已經完整，但沒有裝修之前不能住人。

    除了分配記憶體外，部分 Java 虛擬機器會在此階段構造其他跟類層次相關的資料結構，比如說用來實現虛方法的動態繫結的方法表。

    在 class 檔案被載入至 Java 虛擬機器之前，這個類無法知道其他類及其方法、欄位所對應的具體地址，甚至不知道自己方法、欄位的地址。因此，每當需要引用這些成員時，Java 編譯器會生成一個「符號引用」。在執行階段，這個符號引用一般都能夠無歧義地定位到具體目標上。

    舉個例子，對於一個方法呼叫，編譯器會生成一個包含目標方法所在類的名字、目標方法的名字、接收引數型別以及返回值型別的符號引用，來指代所要呼叫的方法。（即方法簽名）

  • 3.「解析」階段的目的，正是將這些符號引用解析成為實際引用。

    如果符號引用指向一個未被載入的類，或者未被載入類的欄位或方法，那麼解析將觸發這個類的載入（但未必觸發這個類的連結以及初始化。）

    • 符號引用就好比“Jack 的房子”這種說法，不管它存在不存在，我們可以用這種說法指代 Jack 的房子。

    • 實際引用則好比實際的通訊地址，如果我們想要與 Jack 通訊，則需要啟動蓋房子的過程。

    Java 虛擬機器規範並沒有要求在連結過程中完成解析。它僅規定了：如果某些位元組碼使用了符號引用，那麼在執行這些位元組碼之前，需要完成對這些符號引用的解析。

3.初始化

靜態欄位的賦值

Java 中如果要初始化一個靜態欄位，我們可以在宣告時直接賦值，也可以在靜態程式碼塊中對其賦值。

  • 如果直接賦值的靜態欄位被 final 所修飾，並且它的型別是基本型別或字串時，那麼該欄位便會被 Java 編譯器標記成「常量值（ConstantValue）」，其初始化直接由 Java 虛擬機器完成。
  • 除此之外的直接賦值操作，以及所有靜態程式碼塊中的程式碼，則會被 Java 編譯器置於同一方法中，並把它命名為 < clinit >。

初始化

類載入的最後一步是初始化，便是為標記為常量值的欄位賦值和執行 < clinit > 方法的過程。Java 虛擬機器會通過加鎖來確保類的 < clinit > 方法僅被執行一次。

只有當初始化完成之後，類才正式成為可執行的狀態。

在蓋房子的例子中，相當於房子裝修好了，Jack 可以真正拎包入住了。

那麼，類的初始化何時會被觸發呢？

JVM 規範枚舉了下述多種觸發情況：

  1. 當虛擬機器啟動時，初始化使用者指定的主類，就是啟動執行的 main 方法所在的類；

  2. 當遇到用以新建目標類例項的 new 指令時，初始化 new 指令的目標類；

  3. 當遇到呼叫靜態方法的指令時，初始化該靜態方法所在的類；

  4. 當遇到訪問靜態欄位的指令時，初始化該靜態欄位所在的類；

  5. 子類的初始化會觸發父類的初始化；

  6. 如果一個介面定義了 default 方法，那麼直接實現或者間接實現該介面的類的初始化，會觸發該介面的初始化；

    和繼承類似(5、6 條都是面向物件)

  7. 使用反射 API 對某個類進行反射呼叫時，初始化這個類；

  8. 當初次呼叫 MethodHandle 例項時，初始化該 MethodHandle 指向的方法所在的類。

    和反射類似(7、8 條都是反射相關)

// 單例延遲初始化例子

public class Singleton {

  private Singleton() {}

  private static class LazyHolder {

    static final Singleton INSTANCE = new Singleton();

  }

  public static Singleton getInstance() {

    return LazyHolder.INSTANCE;

  }

}

只有當呼叫 Singleton.getInstance 時，程式才會訪問 LazyHolder.INSTANCE，才會觸發對 LazyHolder 的初始化（對應第 4 種情況），繼而新建一個 Singleton 的例項。

由於類的初始化執行緒安全，並且僅被執行一次，因此程式可以確保多執行緒環境下有且僅有一個 Singleton 例項。

那麼，什麼時候不會初始化，但可能會載入？

  1. 通過子類引用父類的靜態欄位，只會觸發父類的初始化，而不會觸發子類的初始化。

  2. 定義物件陣列，不會觸發該類的初始化。

    直到 new 才觸發

  3. 常量在編譯期間會存入呼叫類的常量池中，本質上並沒有直接引用定義常量的類，不會觸發定義常量所在的類。

    常量不是變數

  4. 通過類名獲取 Class 物件，不會觸發類的初始化，Hello.class 不會讓 Hello 類初始化。

  5. 通過 Class.forName 載入指定類時，如果指定引數 initialize 為 false 時，也不會觸發類初始化，其實這個引數是告訴虛擬機器，是否要對類進行初始化。Class.forName (“jvm.Hello”)預設會載入 Hello 類。

  6. 通過 ClassLoader 預設的 loadClass 方法，也不會觸發初始化動作(載入了，但不初始化)。

流程概覽

為了方便檢視，我畫了一張流程圖演示上面的步驟。

END

如果你覺得有用，歡迎關注 「小尹探世界」 微信公眾號，希望我們一起打造一個有知識、有溫度、有趣點、有價值的頻道，探索技術之外的廣袤世界。