Java類加載

主要參考書籍《深入理解Java虛擬機(jī)》

一、概述

虛擬機(jī)的類加載機(jī)制：Java虛擬機(jī)把描述類的數(shù)據(jù)從Class文件加載到內(nèi)存，并對數(shù)據(jù)進(jìn)行校驗、轉(zhuǎn)換解析和初始化，最終形成可以被虛擬機(jī)直接使用的Java類型，這個過程被稱作虛擬機(jī)的類加載機(jī)制

與那些在編譯時需要進(jìn)行連接的語言不同

在Java語言里面，類型的加載、連接和初始化過程都是在程序運(yùn)行期間完成的

Java天生可以動態(tài)擴(kuò)展的語言特性就是依賴運(yùn)行期動態(tài)加載和動態(tài)連接這個特點實現(xiàn)的

二、類加載時機(jī)

類的生命周期（從被加載到虛擬機(jī)內(nèi)存開始，到卸載出為止）：

1. 加載（Loading）
2. 驗證（Verification）
3. 準(zhǔn)備（Preparation）
4. 解析（Resolution）
5. 初始化（Initialization）
6. 使用（Using）
7. 卸載（Unloading）

驗證、準(zhǔn)備、解析三個部分統(tǒng)稱為連接（Linking）

加載、驗證、準(zhǔn)備、初始化和卸載這五個階段的順序是確定的，類型的加載過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以在初始化階段之后再開始，這是為了支持Java語言的運(yùn)行時綁定特性（也稱為動態(tài)綁定或晚期綁定）。

主動引用（必須初始化的場景）

1. 遇到new、getstatic、putstatic或invokestatic這四條字節(jié)碼指令時，如果類型沒有進(jìn)行過初始化，則需要先觸發(fā)其初始化階段
2. 使用java.lang.reflect包的方法對類型進(jìn)行反射調(diào)用的時候，如果類型沒有進(jìn)行過初始化，則需要先觸發(fā)其初始化
3. 當(dāng)初始化類的時候，如果發(fā)現(xiàn)其父類還沒有進(jìn)行過初始化，則需要先觸發(fā)其父類的初始化
4. 當(dāng)虛擬機(jī)啟動時，用戶需要指定一個要執(zhí)行的主類（包含main()方法的那個類），虛擬機(jī)會先初始化這個主類
5. 當(dāng)使用JDK 7新加入的動態(tài)語言支持時，如果一個java.lang.invoke.MethodHandle實例最后的解析結(jié)果為REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四種類型的方法句柄，并且這個方法句柄對應(yīng)的類沒有進(jìn)行過初始化，則需要先觸發(fā)其初始化。
6. 當(dāng)一個接口中定義了JDK 8新加入的默認(rèn)方法（被default關(guān)鍵字修飾的接口方法）時，如果有這個接口的實現(xiàn)類發(fā)生了初始化，那該接口要在其之前被初始化。

被動引用

1. 通過子類引用父類的靜態(tài)字段，不會導(dǎo)致子類初始化
   • 對于靜態(tài)字段，只有直接定義這個字段的類才會被初始化，因此通過其子類來引用父類中定義的靜態(tài)字段，只會觸發(fā)父類的初始化而不會觸發(fā)子類的初始化。
2. 通過數(shù)組定義來引用類，不會觸發(fā)此類的初始化
3. 常量在編譯階段會存入調(diào)用類的常量池中，本質(zhì)上沒有直接引用到定義常量的類，因此不會觸發(fā)定義常量的類的初始化

三、類加載的過程

加載、驗證、準(zhǔn)備、解析和初始化5個步驟

1. 加載

1）通過一個類的全限定名來獲取定義此類的二進(jìn)制字節(jié)流。 （它并沒有指明二進(jìn)制字節(jié)流必須得從某個 Class文件中獲取，確切地說是根本沒有指明要從哪里獲取、如何獲取）

2）將這個字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運(yùn)行時數(shù)據(jù)結(jié)構(gòu)。

3）在內(nèi)存（堆）中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口。

數(shù)組類型和非數(shù)組類型有區(qū)別。

image-20210427154420027

對于數(shù)組類而言，情況就有所不同，數(shù)組類本身不通過類加載器創(chuàng)建，它是由Java虛擬機(jī)直接在內(nèi)存中動態(tài)構(gòu)造出來的。但數(shù)組類與類加載器仍然有很密切的關(guān)系，因為數(shù)組類的元素類型（ElementType，指的是數(shù)組去掉所有維度的類型）最終還是要靠類加載器來完成加載，一個數(shù)組類（下面簡稱為C）創(chuàng)建過程遵循以下規(guī)則：（略）P365

加載階段結(jié)束后，Java虛擬機(jī)外部的二進(jìn)制字節(jié)流就按照虛擬機(jī)所設(shè)定的格式存儲在方法區(qū)之中了，方法區(qū)中的數(shù)據(jù)存儲格式完全由虛擬機(jī)實現(xiàn)自行定義，《Java虛擬機(jī)規(guī)范》未規(guī)定此區(qū)域的具體數(shù)據(jù)結(jié)構(gòu)。類型數(shù)據(jù)妥善安置在方法區(qū)之后，會在Java堆內(nèi)存中實例化一個java.lang.Class類的對象，這個對象將作為程序訪問方法區(qū)中的類型數(shù)據(jù)的外部接口。

3. 類 和 數(shù)組加載過程的區(qū)別？

數(shù)組也有類型，稱為“數(shù)組類型”。如：

String[] str = new String[10];

這個數(shù)組的數(shù)組類型是Ljava.lang.String，而String只是這個數(shù)組中元素的類型。

當(dāng)程序在運(yùn)行過程中遇到new關(guān)鍵字創(chuàng)建一個數(shù)組時，由JVM直接創(chuàng)建數(shù)組類，再由類加載器創(chuàng)建數(shù)組中的元素類。

而普通類的加載由類加載器完成。既可以使用系統(tǒng)提供的引導(dǎo)類加載器，也可以使用用戶自定義的類加載器。

2. 驗證

• 驗證是連接階段的第一步

• 目的：確保Class文件的字節(jié)流中包含的信息符合《Java虛擬機(jī)規(guī)范》的全部約束要求，保證這些信息被當(dāng)作代碼運(yùn)行后不會危害虛擬機(jī)自身的安全。

  • 原因：Class文件并不一定只能由Java源碼編譯而來，它可以使用包括靠鍵盤0和1直接在二進(jìn)制編輯器中敲出Class文件在內(nèi)的任何途徑產(chǎn)生。上述Java代碼無法做到的事情在字節(jié)碼層面上都是可以實現(xiàn)的，至少語義上是可以表達(dá)出來的。Java虛擬機(jī)如果不檢查輸入的字節(jié)流，對其完全信任的話，很可能會因為載入了有錯誤或有惡意企圖的字節(jié)碼流而導(dǎo)致整個系統(tǒng)受攻擊甚至崩潰，所以驗證字節(jié)碼是Java虛擬機(jī)保護(hù)自身的一項必要措施。

四個階段：

• 文件格式驗證： 要驗證字節(jié)流是否符合Class文件格式的規(guī)范，并且能被當(dāng)前版本的虛擬機(jī)處理
  • 主要目的是保證輸入的字節(jié)流能正確地解析并存儲于方法區(qū)之內(nèi)，格式上符合描述一個Java類型信息的要求。這階段的驗證是基于二進(jìn)制字節(jié)流進(jìn)行的，只有通過了這個階段的驗證之后，這段字節(jié)流才被允許進(jìn)入Java虛擬機(jī)內(nèi)存的方法區(qū)中進(jìn)行存儲，所以后面的三個驗證階段全部是基于方法區(qū)的存儲結(jié)構(gòu)上進(jìn)行的，不會再直接讀取、操作字節(jié)流了
• 元數(shù)據(jù)驗證：對字節(jié)碼描述的信息進(jìn)行語義分析，以保證其描述的信息符合《Java語言規(guī)范》的要求
  • 主要目的是對類的元數(shù)據(jù)信息進(jìn)行語義校驗，保證不存在與《Java語言規(guī)范》定義相悖的元數(shù)據(jù)信息
  • 對元數(shù)據(jù)信息中的數(shù)據(jù)類型校驗
• 字節(jié)碼驗證
  • 最復(fù)雜
  • 主要目的是通過數(shù)據(jù)流分析和控制流分析，確定程序語義是合法的、符合邏輯的
  • 對類的方法體（Class文件中的Code屬性）進(jìn)行校驗分析，保證被校驗類的方法在運(yùn)行時不會做出危害虛擬機(jī)安全的行為
• 符號引用驗證
  • 最后一個階段的校驗行為發(fā)生在虛擬機(jī)將符號引用轉(zhuǎn)化為直接引用的時候
  • 這個轉(zhuǎn)化動作將在連接的第三階段——解析階段中發(fā)生
  • 是對類自身以外（常量池中的各種符號引用）的各類信息進(jìn)行匹配性校驗
  • 主要目的是確保解析行為能正常執(zhí)行，如果無法通過符號引用驗證，Java虛擬機(jī)將會拋出一個java.lang.IncompatibleClassChangeError的子類異常

驗證階段對于虛擬機(jī)的類加載機(jī)制來說，是一個非常重要的、但卻不是必須要執(zhí)行的階段，因為驗證階段只有通過或者不通過的差別，只要通過了驗證，其后就對程序運(yùn)行期沒有任何影響了。如果程序運(yùn)行的全部代碼（包括自己編寫的、第三方包中的、從外部加載的、動態(tài)生成的等所有代碼）都已經(jīng)被反復(fù)使用和驗證過，在生產(chǎn)環(huán)境的實施階段就可以考慮使用-Xverify：none參數(shù)來關(guān)閉大部分的類驗證措施，以縮短虛擬機(jī)類加載的時間。

3. 準(zhǔn)備

準(zhǔn)備階段：正式為類中定義的靜態(tài)變量（即靜態(tài)變量，被static修飾的變量）分配內(nèi)存并設(shè)置類變量初始值的階段。

1. 為已經(jīng)在方法區(qū)中的類中的靜態(tài)成員變量分配內(nèi)存
   • 類的靜態(tài)成員變量也存儲在方法區(qū)中。
2. 為靜態(tài)成員變量設(shè)置初始值
   • 初始值為0、false、null等。
   • 如果是常量（static final），則直接賦值

（這里所說的初始值“通常情況”下是數(shù)據(jù)類型的零值。如果類字段的字段屬性表中存在ConstantValue屬性，那在準(zhǔn)備階段變量值就會被初始化為ConstantValue屬性所指定的初始值）

概念上講，這些變量所使用的內(nèi)存都應(yīng)當(dāng)在方法區(qū)中進(jìn)行分配，在JDK 7及之前，HotSpot使用永久代來實現(xiàn)方法區(qū)時，實現(xiàn)是完全符合這種邏輯概念的；

在JDK 8及之后，類變量則會隨著Class對象一起存放在Java堆中

• 準(zhǔn)備階段，進(jìn)行內(nèi)存分配的僅包括類變量，而不包括實例變量，實例變量將會在對象實例化時隨著對象一起分配在Java堆中

public static int value = 123;

那變量value在準(zhǔn)備階段過后的初始值為0而不是123，因為這時尚未開始執(zhí)行任何Java方法，而把 value賦值為123的putstatic指令是程序被編譯后，存放于類構(gòu)造器<clinit>()方法之中，所以把value賦值 為123的動作要到類的初始化階段才會被執(zhí)行

public static final int value = 123;

編譯時Javac將會為value生成ConstantValue屬性，在準(zhǔn)備階段虛擬機(jī)就會根據(jù)Con-stantValue的設(shè)置將value賦值為123。

4. 解析

解析階段：是Java虛擬機(jī)將常量池內(nèi)的符號引用替換為直接引用的過程

• 符號引用（Symbolic References）：符號引用以一組符號來描述所引用的目標(biāo)，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標(biāo)即可。符號引用與虛擬機(jī)實現(xiàn)的內(nèi)存布局無關(guān)，引用的目標(biāo)并不一定是已經(jīng)加載到虛擬機(jī)內(nèi)存當(dāng)中的內(nèi)容。各種虛擬機(jī)實現(xiàn)的內(nèi)存布局可以各不相同，但是它們能接受的符號引用必須都是一致的，因為符號引用的字面量形式明確定義在《Java虛擬機(jī)規(guī)范》的Class文件格式中。

• 直接引用（Direct References）：直接引用是可以直接指向目標(biāo)的指針、相對偏移量或者是一個能間接定位到目標(biāo)的句柄。直接引用是和虛擬機(jī)實現(xiàn)的內(nèi)存布局直接相關(guān)的，同一個符號引用在不同虛擬機(jī)實例上翻譯出來的直接引用一般不會相同。如果有了直接引用，那引用的目標(biāo)必定已經(jīng)在虛擬機(jī)的內(nèi)存中存在。

《Java虛擬機(jī)規(guī)范》之中并未規(guī)定解析階段發(fā)生的具體時間，只要求了在執(zhí)行ane-warray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invoke-special、 invokestatic、invokevirtual、ldc、ldc_w、ldc2_w、multianewarray、new、putfield和putstatic這17個用于操作符號引用的字節(jié)碼指令之前，先對它們所使用的符號引用進(jìn)行解析。

解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調(diào)用點限定符這7類符號引用進(jìn)行

（1）類或接口的解析

image-20210427190744756

（2）字段解析

前提：解析字段所屬的類或者接口的符號引用。

要解析一個未被解析過的字段符號引用，首先將會對字段表內(nèi)class_index項中索引的CONSTANT_Class_info符號引用進(jìn)行解析，也就是字段所屬的類或接口的符號引用。如果在解析這個類或接口符號引用的過程中出現(xiàn)了任何異常，都會導(dǎo)致字段符號引用解析的失敗。

java.lang.NoSuchFieldError異常

image-20210427192557687

（3）方法解析

前提：解析方法所屬的類或者接口的符號引用。是需要先解析出方法表的class_index項中索引的方法所屬的類或接口的符號引用

image-20210427193211104

java.lang.NoSuchMethodError

（4）接口方法解析

前提：解析接口方法所屬的類或者接口的符號引用。是需要先解析出接口方法表的class_index項中索引的方法所屬的類或接口的符號引用

在JDK 9之前，Java接口中的所有方法都默認(rèn)是public的，也沒有模塊化的訪問約束，所以不存在訪問權(quán)限的問題，接口方法的符號解析就不可能拋出java.lang.IllegalAccessError異常。但在JDK 9中增加了接口的靜態(tài)私有方法，也有了模塊化的訪問約束，所以從JDK 9起，接口方法的訪問也完全有可能因訪問權(quán)限控制而出現(xiàn)java.lang.IllegalAccessError異常。

5. 初始化

在編譯生成class文件時，會自動產(chǎn)生兩個方法，一個是類的初始化方法clinit（）, 另一個是實例的初始化方法init（）

clinit（）：在jvm第一次加載class文件時調(diào)用，包括靜態(tài)變量初始化語句和靜態(tài)塊的執(zhí)行

init（）：在實例創(chuàng)建出來的時候調(diào)用，包括調(diào)用new操作符；調(diào)用Class或java.lang.reflect.Constructor對象的newInstance()方法；調(diào)用任何現(xiàn)有對象的clone()方法；通過java.io.ObjectInputStream類的getObject()方法反序列化。

類的初始化階段是類加載過程的最后一個步驟，除了在加載階段用戶應(yīng)用程序可以通過自定義類加載器的方式局部參與外，其余動作都完全由Java虛擬機(jī)來主導(dǎo)控制。直到初始化階段，Java虛擬機(jī)才真正開始執(zhí)行類中編寫的Java程序代碼，將主導(dǎo)權(quán)移交給應(yīng)用程序。

進(jìn)行準(zhǔn)備階段時，變量已經(jīng)賦過一次系統(tǒng)要求的初始零值，而在初始化階段，則會根據(jù)程序員通過程序編碼制定的主觀計劃去初始化類變量和其他資源。

初始化階段就是執(zhí)行類構(gòu)造器clinit()方法的過程。clinit()并不是程序員在Java代碼中直接編寫的方法，它是Javac編譯器的自動生成物。

clinit()方法是由編譯器自動收集類中的所有類變量的賦值動作和靜態(tài)語句塊（static{}塊）中的語句合并產(chǎn)生的，編譯器收集的順序是由語句在源文件中出現(xiàn)的順序決定的，靜態(tài)語句塊中只能訪問到定義在靜態(tài)語句塊之前的變量，定義在它之后的變量，在前面的靜態(tài)語句塊可以賦值，但是不能訪問

初始化階段就是執(zhí)行類構(gòu)造器clinit（）的過程。
clinit()方法由編譯器自動產(chǎn)生，收集類中static{}代碼塊中的類變量賦值語句和類中靜態(tài)成員變量的賦值語句。在準(zhǔn)備階段，類中靜態(tài)成員變量已經(jīng)完成了默認(rèn)初始化，而在初始化階段，clinit（）方法對靜態(tài)成員變量進(jìn)行顯示初始化。？？（顯式初始化）

public class Test { 
    static { 
        i = 0; // 給變量復(fù)制可以正常編譯通過           
        System.out.print(i); // 這句編譯器會提示“非法向前引用”  
    }
   static int i = 1;
}

• <clinit>()方法與類的構(gòu)造函數(shù)（即在虛擬機(jī)視角中的實例構(gòu)造器<init>()方法）不同，它不需要顯式地調(diào)用父類構(gòu)造器，Java虛擬機(jī)會保證在子類的<clinit>()方法執(zhí)行前，父類的<clinit>()方法已經(jīng)執(zhí)行 完畢。因此在Java虛擬機(jī)中第一個被執(zhí)行的<clinit>()方法的類型肯定是java.lang.Object。

• 由于父類的<clinit>()方法先執(zhí)行，也就意味著父類中定義的靜態(tài)語句塊要優(yōu)先于子類的變量賦值操作

• <clinit>()方法對于類或接口來說并不是必需的，如果一個類中沒有靜態(tài)語句塊，也沒有對變量的賦值操作，那么編譯器可以不為這個類生成<clinit>()方法。

• 接口中不能使用靜態(tài)語句塊，但仍然有變量初始化的賦值操作，因此接口與類一樣都會生成 <clinit>()方法。但接口與類不同的是，執(zhí)行接口的<clinit>()方法不需要先執(zhí)行父接口的<clinit>()方法，因為只有當(dāng)父接口中定義的變量被使用時，父接口才會被初始化。此外，接口的實現(xiàn)類在初始化時也一樣不會執(zhí)行接口的<clinit>()方法。

• Java虛擬機(jī)必須保證一個類的<clinit>()方法在多線程環(huán)境中被正確地加鎖同步

同一個類加載器下，一個類型只會被初始化一次

四、類加載器

類加載階段：通過一個類的全限定名來獲取描述該類的二進(jìn)制字節(jié) 流。

把這個動作放到Java虛擬機(jī)外部去實現(xiàn)，以便讓應(yīng)用程序自己決定如何去獲取所需的類。實現(xiàn)這個動作的代碼被稱為“類加載器”（Class Loader）。

1. 類與類加載器

對于任意一個類，都必須由加載它的類加載器和這個類本身一起共同確立其在Java虛擬機(jī)中的唯一性，每一個類加載器，都擁有一個獨(dú)立的類名稱空間。

這句話可以表達(dá)得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類加載器加載的前提下才有意義，否則，即使這兩個類來源于同一個 Class文件，被同一個Java虛擬機(jī)加載，只要加載它們的類加載器不同，那這兩個類就必定不相等。

2. 雙親委派模型

• 啟動類加載器（Bootstrap Class Loader）
  • 器負(fù)責(zé)加載存放在 <JAVA_HOME>\lib目錄，或者被-Xbootclasspath參數(shù)所指定的路徑中存放的，而且是Java虛擬機(jī)能夠識別的（按照文件名識別，如rt.jar、tools.jar，名字不符合的類庫即使放在lib目錄中也不會被加載）類庫加載到虛擬機(jī)的內(nèi)存中。
  • 啟動類加載器無法被Java程序直接引用
• 擴(kuò)展類加載器（Extension Class Loader）
  • 負(fù)責(zé)加載<JAVA_HOME>\lib\ext目錄中，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中所有的類庫。
  • 擴(kuò)展類加載器是由Java代碼實現(xiàn)的，開發(fā)者可以直接在程序中使用擴(kuò)展類加載器來加載Class文件
• 應(yīng)用程序類加載器（Application Class Loader）：
  • 負(fù)責(zé)加載用戶類路徑（ClassPath）上所有的類庫
  • 開發(fā)者可以直接在代碼中使用這個類加載器
  • 如果應(yīng)用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認(rèn)的類加載器。

各種類加載器之間的層次關(guān)系被稱為類加載器的“雙親委派模型（Parents Delegation Model）”。雙親委派模型要求除了頂層的啟動類加載器外，其余的類加載器都應(yīng)有自己的父類加載器。不過這里類加載器之間的父子關(guān)系一般不是以繼承（Inheritance）的關(guān)系來實現(xiàn)的，而是通常使用 組合（Composition）關(guān)系來復(fù)用父加載器的代碼。

雙親委派模型的工作過程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應(yīng)該傳送到最頂層的啟動類加載器中，只有當(dāng)父加載器反饋自己無法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去完成加載

好處

• Java中的類隨著它的類加載器一起具備了一種帶有優(yōu)先級的層次關(guān)系
• 保證Java程序的穩(wěn)定運(yùn)作

雙親委派模型的實現(xiàn)：

在java.lang.ClassLoader的loadClass()方法之中

先檢查請求加載的類型是否已經(jīng)被加載過，若沒有則調(diào)用父加載器的 loadClass()方法，若父加載器為空則默認(rèn)使用啟動類加載器作為父加載器。假如父類加載器加載失敗，拋出ClassNotFoundException異常的話，才調(diào)用自己的findClass()方法嘗試進(jìn)行加載。

3. 破壞雙親委派模型

雙親委派模型并不是一個具有強(qiáng)制性約束的模型，而是Java設(shè)計者推薦給開發(fā)者們的類加載器實現(xiàn)方式。

雙親委派模型的優(yōu)點我總結(jié)得不太好，建議大家多看看其它優(yōu)秀的博客