【死磕JVM】五年 整整五年了 該知道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始終不會被初始化；

2. 經過數組定義來引用類，不會觸發此類的初始化

/** * @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!!!」 ，說明沒有觸發類的初始化階段

3. 常量在編譯階段會存入調用類的常量池中，本質上並無直接引用到定義常量的類，所以不會觸發定義常量的類的初始化

/** * @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)

一、加載

加載 是 類加載(Class Loading) 過程的一個階段，加載 是 類加載(Class Loading) 過程的一個階段，加載是指將當前類的class文件讀入內存中，而且建立一個 java.lang.Class的對象，也就是說，當程序中使用任何類的時候，系統都會建立一個叫 java.lang.Class對象

在加載階段，虛擬機須要完成如下三個事情：

1. 經過一個類的全限定名類獲取定義此類的二進制字節流(沒有指明只能從一個Class文件中獲取，能夠從其餘渠道，如：網絡、動態生成、數據庫等)
2. 將這個字節流所表明的靜態存儲結構轉化爲方法區的運行時數據結構
3. 在內存中生成一個表明這個類的java.lang.Class對象，做爲方法區這個類的各類數據的訪問入口

類加載器一般無須等到「首次使用」該類時才加載該類，Java虛擬機規範容許系統預先加載某些類。加載階段與鏈接階段的部份內容是交叉進行的，加載階段還沒有完成，鏈接階段可能已經開始，但這些夾在夾在階段之中進行的動做，仍然屬於鏈接階段的內容，這兩個階段的開始時間仍然保持着固定的前後順序。

二、鏈接

當類被加載以後，系統會生成一個對應的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文件常量池裏面用到的符號引用轉換爲直接內存地址，直接能夠訪問到的內容
符號引用：以一組符號來描述所引用的目標，符號能夠是任何字面形式的字面量，只要不會出現衝突可以定位到就能夠
直接引用：能夠是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄，若是有了直接引用，那引用的目標一定已經在內存中存在了

三、初始化

初始化是給類的靜態變量賦正確的初始值，剛纔咱們有講到準備階段是複製默認值，而初始化是給靜態變量賦值初始值，看下面的語句：
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內庫被隨意更改，其次是效率問題，若是有緩存在，直接從緩存裏面拿，就不用一遍一遍的去遍歷查詢咱們的父類或者子類了。

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

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