【死磕JVM】五年 整整五年了 該知道JVM載入機制了!

牧小農發表於2021-02-28
JVM

類載入

Java虛擬機器類載入過程是把Class類檔案載入到記憶體，並對Class檔案中的資料進行校驗、轉換解析和初始化，最終形成可以被虛擬機器直接使用的java型別的過程

和那些編譯時需要連線工作的語言不同，在Java語言裡，型別的載入，連線和初始化過程都是在程式 執行期間完成的，這種策略雖然會令類載入時稍微增加一些效能開銷，但是會為java應用程式提供比較高的靈活性。

當我們使用到某個類的時候，如果這個類還未從磁碟上載入到記憶體中，JVM就會通過三步走策略（載入、連線、初始化）來對這個類進行初始化，JVM完成這三個步驟的名稱，就叫做類載入或者類初始化

在這裡插入圖片描述

類載入的時機

什麼情況下需要開始類載入的第一個階段——載入 ，在Java虛擬機器規範中沒有進行強制約束，而是交給虛擬機器的具體實現來進行把握，但是對於初始化階段，虛擬機器規範嚴格規定了 “有且只有” 五種情況必須立即對類進行初始化（而載入、驗證、準備自然需要在此之前開始），具體情況如下所示：

class檔案的載入時機：

序號 內容
1 遇到 new、getstatic、putstatic、或invokestatic這四條位元組碼指令
2 使用 java.lang.reflect 包的方法對類進行反射呼叫的時候
3 初始化類時，父類沒有被初始化，先初始化父類
4 虛擬機器啟動時，使用者指定的主類(包含main()的那個類)
5 當使用JDK1.7動態語言支援的時，如果一個java.lang.invoke.MethodHandle 例項最後解析的結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法控制程式碼，並且這個方法控制程式碼鎖對應的類沒有進行過初始化時

關於序號1的詳細解釋：

  1. 使用 new 關鍵字例項化物件時
  2. 讀取類的靜態變數時（被 final修飾，已在編譯期把結果放入常量池的靜態欄位除外）
  3. 設定類的靜態變數時
  4. 呼叫一個類的靜態方法時

注意： newarray指令觸發的只是陣列型別本身的初始化，而不會導致其相關型別的初始化，比如，new String[]只會直接觸發 String[] 類的初始化，也就是觸發對類[Ljava.lang.String的初始化，而直接不會觸發String類的初始化。

生成這四條指令最常見的Java程式碼場景是：

對於這5種會觸發類進行初始化的場景，虛擬機器規範中使用了一個很強烈的限定語：“有且只有”，這5種場景中的行為稱為對一個類進行主動引用。除此之外，所有引用類的方式都不會觸發初始化，稱為 被動引用。

需要特別指出的是，類的例項化和類的初始化是兩個完全不同的概念：

  • 類的例項化是指建立一個類的例項(物件)的過程；
  • 類的初始化是指為類各個成員賦初始值的過程，是類生命週期中的一個階段；

被動引用的三個場景：

  1. 通過子類引用父類的靜態欄位，不會導致子類初始化
/**
 * @program: jvm
 * @ClassName Test1
 * @Description：通過子類引用父類的靜態欄位，不會導致子類初始化
 * @author: 牧小農
 * @create: 2021-02-27 11:42
 * @Version 1.0
 **/
public class Test1 {

    static {
        System.out.println("Init Superclass!!!");
    }

    public static void main(String[] args) {
                 int x = Son.count;
    }

}

class Father extends Test1{
    static int count = 1;
    static {
        System.out.println("Init father!!!");
    }
}

class Son extends Father{
    static {
        System.out.println("Init son!!!");
    }
}

輸出：

Init Superclass!!!
Init father!!!

對於靜態欄位，只有直接定義這個欄位的類才會被初始化，因此通過其子類來引用父類中定義的靜態欄位，只會觸發父類的初始化而不會觸發子類的初始化。至於是否要觸發子類的載入和驗證，在虛擬機器中並未明確規定，這點取決於虛擬機器的具體實現。對於Sun HotSpot虛擬機器來說，可通過-XX:+TraceClassLoading引數觀察到此操作會導致子類的載入。

上面的案例中，由於count欄位是在Father類中定義的，因此該類會被初始化，此外，在初始化類Father的時候，虛擬機器發現其父類Test1 還沒被初始化，因此虛擬機器將先初始化其父類Test1 ，然後初始化子類Father，而Son始終不會被初始化；

  1. 通過陣列定義來引用類，不會觸發此類的初始化
/**
 * @program: jvm
 * @ClassName Test2
 * @description:
 * @author: muxiaonong
 * @create: 2021-02-27 12:03
 * @Version 1.0
 **/
public class Test2 {

    public static void main(String[] args) {
        M[] m = new M[8];
    }

}

class M{
    static {
        System.out.println("Init M!!!");
    }
}

執行之後我們會發現沒有輸出 "Init M!!!"，說明沒有觸發類的初始化階段

  1. 常量在編譯階段會存入呼叫類的常量池中，本質上並沒有直接引用到定義常量的類，因此不會觸發定義常量的類的初始化
/**
 * @program: jvm
 * @ClassName Test3
 * @description:
 * @author: muxiaonong
 * @create: 2021-02-27 12:05
 * @Version 1.0
 **/
public class Test3 {

    public static void main(String[] args) {
        System.out.println(ConstClass.COUNT);
    }

}

class ConstClass{
    static final int COUNT = 1;
    static{
        System.out.println("Init ConstClass!!!");
    }
}

上面程式碼執行後也沒有輸出 Init ConstClass!!!，這是因為雖然在Java原始碼中引用了ConstClass 類中的常量COUNT ，但其實在編譯階段通過常量傳播優化，已經將常量的值 "1"儲存到Test3 常量池中了，對常量ConstClass.COUNT的引用實際都被轉化為Test3 類對自身常量池的引用了，也就是說，實際上Test3 的Class檔案之中並沒有ConstClass類的符號引用入口，這兩個類在編譯為Class檔案之後就不存在關係

類載入過程

有一個名叫Class檔案，它靜靜的躺在了硬碟上，吃香的喝辣的，他究竟需要一個怎麼樣的過程經歷了什麼，才能夠從舒服的硬碟中到記憶體中呢？class進入記憶體總共有三大步。

  • 載入(Loading)
  • 連線(Linking)
  • 初始化(Initlalizing)

1、載入

載入 是 類載入(Class Loading) 過程的一個階段，載入 是 類載入(Class Loading) 過程的一個階段，載入是指將當前類的class檔案讀入記憶體中，並且建立一個 java.lang.Class的物件，也就是說，當程式中使用任何類的時候，系統都會建立一個叫 java.lang.Class物件

在載入階段，虛擬機器需要完成以下三個事情：

  1. 通過一個類的全限定名類獲取定義此類的二進位制位元組流(沒有指明只能從一個Class檔案中獲取，可以從其他渠道，如：網路、動態生成、資料庫等)
  2. 將這個位元組流所代表的靜態儲存結構轉化為方法區的執行時資料結構
  3. 在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口

類載入器通常無須等到“首次使用”該類時才載入該類，Java虛擬機器規範允許系統預先載入某些類。載入階段與連線階段的部分內容是交叉進行的，載入階段尚未完成，連線階段可能已經開始，但這些夾在夾在階段之中進行的動作，仍然屬於連線階段的內容，這兩個階段的開始時間仍然保持著固定的先後順序。

2、連線

當類被載入之後，系統會生成一個對應的Class物件，就會進入 連線階段，連線階段負責把類的二進位制資料合併到JRE中，連線階段又分為三個小階段

1.1 驗證

驗證是連線階段的第一步，這一階段的主要目的是為了確保Class檔案的位元組流中包含的資訊符合當前虛擬機器的要求，並且不會危害虛擬機器自身的安全。Java語言相對於 C/C++ 來說本身是相對安全的語言，驗證階段是非常重要的，這個階段是否嚴謹，決定了Java虛擬機器能不能承受惡意程式碼的攻擊，當驗證輸入的位元組流不符合Class檔案格式的約束時，虛擬機器會丟擲一個 java.lang.VerifyError異常或者子類異常，從大體來說驗證主要分為四個校驗動作：檔案格式驗證、後設資料驗證、位元組碼驗證、符號引用驗證

檔案格式驗證： 主要驗證位元組流是否符合Class檔案格式的規範，並且能被當前版本的虛擬機器處理。主要包含以下幾個方面：

  • 檔案格式是否以 CAFEBABE開頭
  • 主次版本是否在虛擬機器處理的範圍內
  • 常量池的常量是否有不被支援的常量型別
  • 指向常量的各種索引值是否有指向不存在的常量或者不符合型別的常量
  • CONSTANT_Utf8_info 型的常量是否有不符合UTF8編碼的資料
  • Class檔案中各個部分及檔案本身是否有被刪除的活附件的資訊

後設資料驗證： 主要是對位元組碼描述的資訊進行語義分析，主要目的是對類的後設資料進行語義校驗，分析是否符合Java的 語言語法的規範，保證不存在不符合Java語言的規範的後設資料的資訊，該階段主要驗證的方面包含以下幾個方面：

  • 這個類是否有父類(除java.lang.Object)
  • 這個類的父類是否繼承了不允許被繼承的類(被final 修飾的類)
  • 如果這個類不是抽象類，是否實現了父類或介面之中要求的所有方法
  • 類中的欄位、方法是否和父類產生矛盾

位元組碼驗證： 最重要也是最複雜的校驗環節，通過資料流和控制流分析程式語義是否合法、符合邏輯的。主要針對類的方法體進行校驗分析，保證被校驗的類在執行時不會危害虛擬機器安全的事情

  • 保證任何時候運算元棧的資料型別和指令程式碼序列都能配合工作（例如在操作棧上有一個int型別的資料，保證不會在使用的時候按照long型別來載入到本地變數表中）
  • 跳轉指令不會條狀到方法體以外的位元組碼指令上
  • 保證方法體中的資料轉換是有效的，例如可以把一個子類物件賦值給父類資料型別，但是不能把父類賦值給子類資料型別

符號引用驗證： 針對符號引用轉換直接引用的時候，這個裝換工作會在第三階段（位元組碼驗證）解析階段中發生。主要是保證引用一定會被訪問到，不會出現類無法訪問的問題。

1.2 準備

為類變數 分配記憶體並設定類變數初始值的階段，這些變數所使用的記憶體都會在方法區進行分配，在準備階段是把class檔案靜態變數賦預設值，注意：不是賦初始值，比如我們 public static int i = 8 ，在這個步驟 並不是把 i 賦值成8 ，而是先賦值為0

基本型別的預設值：

資料型別 預設值
int 0
long 0L
short (short)0
char '\u0000'
byte (byte)0
boolean false
float 0.0f
double 0.0d
reference null

在通常情況下初始值是0，但是如果我們把上面的常量加一個final 類修飾的話，那麼這個時候初始值就會程式設計我們指定的值 public static final int i = 8
編譯的時候Javac會把i的初始值變為8，

1.3 解析

把class檔案常量池裡面用到的符號引用轉換為直接記憶體地址，直接可以訪問到的內容
符號引用：以一組符號來描述所引用的目標，符號可以是任何字面形式的字面量，只要不會出現衝突能夠定位到就可以
直接引用：可以是直接指向目標的指標、相對偏移量或是一個能間接定位到目標的控制程式碼，如果有了直接引用，那引用的目標必定已經在記憶體中存在了

3、初始化

初始化是給類的靜態變數賦正確的初始值，剛才我們有講到準備階段是複製預設值，而初始化是給靜態變數賦值初始值，看下面的語句：
public static int i = 8

首先位元組碼檔案被載入到記憶體後，先進行連線驗證，通過準備階段，給i分配記憶體，因為是static，所以這個時候i 等於int型別的預設初始值是0，所以i 現在是 0，到了初始化的時候，才會真正把i 賦值為8

類載入器

類載入器負責載入所有的類，並且為載入記憶體中的類生成一個 java.lang.Class例項物件，如果一個類被載入到JVM中後，同一個類不會再次被載入，就像物件有一個唯一的標識，同樣載入的JVM的類也有一個唯一的標識。JVM本身有一個類載入器的層次，這個類載入器本身就是一個普通的Class，所有的Class都是被類載入器載入到記憶體中，我們可以稱之為ClassLoader，一個頂級的父類，也是一個abstract抽象類。
在這裡插入圖片描述
Bootstrap： 類載入器的載入過程，分成不同的層次來進行載入，不同的類載入器載入不同的Class，作為最頂層的Bootstrap，它載入lib裡JDK最核心的內容，比如說rt.jar charset.jar等核心類，當我們呼叫getClassLoader()拿到這個載入器結果是一個Null的時候，代表我們已經達到了最頂層的載入器

Extension： Extension載入器擴充套件類，載入擴充套件包裡的各種各樣的檔案，這些擴充套件包在JDK安裝目錄 jre/lib/ext下的jar

App： 就是我們平時用到的application ，用來載入classpath指定的內容

Custom ClassLoader： 自定義ClassLoader，載入自己自定義的載入器 Custom ClassLoader 的父類載入器是 application 的父類載入器是 Extension的父類載入器是Bootstrap

注意：他們不是繼承關係，而是委託關係

public class ClassLoaderTest {
    public static void main(String[] args) {
        // 檢視是誰Load到記憶體的，執行結果是null，因為Bootstrap使用C++實現的
        // 在Java裡面沒有class和它對應
        System.out.println(String.class.getClassLoader());

        //這個是核心類庫某個包裡的類執行，執行結果是Null，因為該類也是被Bootstrap載入的
        System.out.println(sun.awt.HKSCS.class.getClassLoader());

        //這個類是位於ext目錄下某個jar檔案裡面，當我們呼叫他執行結果就是sun.misc.Launcher$ExtClassLoader@a09ee92
        System.out.println(sun.net.spi.nameservice.dns.DNSNameService.class.getClassLoader());

        // 這個是我們自己寫的ClassLoad載入器，由sun.misc.Launcher$AppClassLoader@18b4aac2載入
        System.out.println(ClassLoaderTest.class.getClassLoader());

        // 是Exe的ClassLoader 呼叫它的getclass()，它本身也是一個class，呼叫它的getClassLoader，他的ClassLoader的ClassLoader就是我們的Bootstrap所以結果為Null
        System.out.println(sun.net.spi.nameservice.dns.DNSNameService.class.getClassLoader().getClass().getClassLoader());
        
    }
}

類載入器繼承關係
在這裡插入圖片描述
這個圖講的是ClassLoader從語法上是從誰繼承的，這個圖只是單純的一個語法關係，不是繼承關係，大家可以記住，和上面的類載入沒有一點關係，過分的大家其實可以忽略這個圖

雙親委派

父載入器： 父載入器不是"類載入器的載入器"，也不是"類載入器的父類載入器"
雙親委派是一個孩子向父親的方向，然後父親向孩子方向的雙親委派過程

當一個類載入器收到了類載入請求時候，他會先嚐試從自定義裡面去找，同時它內部還維護了快取，如果在快取中找到了就直接返回結果，如果沒有找到，就向父類進行委託，父類再去快取中找，一直到最頂級的父類，如果這個時候還沒有從快取中獲取到我們想要的結果，這個時候父親就說我你這個事情，我辦不了，你要自己動，然後兒子就自己去查詢對應的class類並載入，如果到了最小的一個兒子還是沒有找到對應的類，就會丟擲異常 Class Not Found Exception

在這裡插入圖片描述
為什麼要弄雙親委派？

這個是類載入器必問的一個面試題。

主要為了安全，如果任何一個Class都可以把他load到記憶體中的話，那麼我寫一個 java.lang.String，如果我寫入了有危險的程式碼，是不是就會發生安全問題，並且可以保證Java核心api中定義的型別不會被隨意替換，可以防止API內庫被隨意更改，其次是效率問題，如果有快取在，直接從快取裡面拿，就不用一遍一遍的去遍歷查詢我們的父類或者子類了。

原創不易，一鍵三連是個好習慣！

我是牧小農，怕什麼真理無窮，進一步有進一步的歡喜，大家加油！！！

相關文章