摘要：最終形成可以被虛擬機(jī)最直接使用的類型的過程就是虛擬機(jī)的類加載機(jī)制。即重寫一個(gè)類加載器的方法驗(yàn)證驗(yàn)證是連接階段的第一步，這一階段的目的是為了確保文件的字節(jié)流中包含的信息符合當(dāng)前虛擬機(jī)的要求，并且不會(huì)危害虛擬機(jī)自身的安全。

《深入理解Java虛擬機(jī)：JVM高級(jí)特性與最佳實(shí)踐（第二版》讀書筆記與常見相關(guān)面試題總結(jié)

本節(jié)常見面試題（推薦帶著問題閱讀，問題答案在文中都有提到）：

簡單說說類加載過程，里面執(zhí)行了哪些操作？

對(duì)類加載器有了解嗎？

什么是雙親委派模型？

雙親委派模型的工作過程以及使用它的好處。

代碼編譯的結(jié)果從本地轉(zhuǎn)換為字節(jié)碼，是存儲(chǔ)格式發(fā)展的一小步，卻是編程語言發(fā)展的一大步。

上一節(jié)我們已經(jīng)知道了類文件結(jié)構(gòu)，在class文件中描述的各種信息最終都需要加載到虛擬機(jī)中之后才能運(yùn)行和使用。

那么虛擬機(jī)是如加載這些class文件呢？class文件中的信息進(jìn)入到虛擬機(jī)后會(huì)發(fā)生什么變化呢？

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

另外需要注意的很重要的一點(diǎn)是：java語言中類型的加載連接以及初始化過程都是在程序運(yùn)行期間完成的，這種策略雖然會(huì)使類加載時(shí)稍微增加一些性能開銷，但是會(huì)為java應(yīng)用程序提供高度的靈活性。java里天生就可以動(dòng)態(tài)擴(kuò)展語言特性就是依賴運(yùn)行期間動(dòng)態(tài)加載和動(dòng)態(tài)連接這個(gè)特點(diǎn)實(shí)現(xiàn)的。比如，如果編寫一個(gè)面向接口的程序，可以等到運(yùn)行時(shí)再指定其具體實(shí)現(xiàn)類。

類從被加載到虛擬機(jī)內(nèi)存到卸出內(nèi)存為止，它的整個(gè)生命周期包括：

我們思考一下那么什么時(shí)候需要開始類加載的第一個(gè)階段：加載？

虛擬機(jī)規(guī)范嚴(yán)格規(guī)定了有且只有五種情況必須立即對(duì)類進(jìn)行“初始化”：

使用new關(guān)鍵字實(shí)例化對(duì)象的時(shí)候、讀取或設(shè)置一個(gè)類的靜態(tài)字段的時(shí)候，已經(jīng)調(diào)用一個(gè)類的靜態(tài)方法的時(shí)候。

使用java.lang.reflect包的方法對(duì)類進(jìn)行反射調(diào)用的時(shí)候，如果類沒有初始化，則需要先觸發(fā)其初始化。

當(dāng)初始化一個(gè)類的時(shí)候，如果發(fā)現(xiàn)其父類沒有被初始化就會(huì)先初始化它的父類。

當(dāng)虛擬機(jī)啟動(dòng)的時(shí)候，用戶需要指定一個(gè)要執(zhí)行的主類（就是包含main()方法的那個(gè)類），虛擬機(jī)會(huì)先初始化這個(gè)類；

使用Jdk1.7動(dòng)態(tài)語言支持的時(shí)候的一些情況。

而對(duì)于接口，當(dāng)一個(gè)接口在初始化時(shí)，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口時(shí)（如引用父接口中定義的常量）才會(huì)初始化。

所有引用類的方式都不會(huì)觸發(fā)初始化稱為被動(dòng)引用，下面是3個(gè)被動(dòng)引用例子：

①通過子類引用父類靜態(tài)字段，不會(huì)導(dǎo)致子類初始化；②通過數(shù)組定義引用類，不會(huì)觸發(fā)此類的初始化

public class SuperClass {
    static {
        System.out.println("SuperClass（父類）被初始化了。。。");
    }
    public static int value = 66;
}

public class Subclass extends SuperClass {
    static {
        System.out.println("Subclass（子類）被初始化了。。。");

    }
    
}

public class Test1 {

    public static void main(String[] args) {

        // 1:通過子類調(diào)用父類的靜態(tài)字段不會(huì)導(dǎo)致子類初始化
        // System.out.println(Subclass.value);//SuperClass（父類）被初始化了。。。66
        // 2:通過數(shù)組定義引用類，不會(huì)觸發(fā)此類的初始化
        SuperClass[] superClasses = new SuperClass[3];
        // 3:通過new 創(chuàng)建對(duì)象,可以實(shí)現(xiàn)類初始化，必須把1下面的代碼注釋掉才有效果不然經(jīng)過1的時(shí)候類已經(jīng)初始化了，下面這條語句也就沒用了。
        //SuperClass superClass = new SuperClass();
    }

}

③常量在編譯階段會(huì)存入調(diào)用類的常量池中，本質(zhì)上并沒有直接引用定義常量的類，因此不會(huì)觸發(fā)定義常量的類的初始化

public class ConstClass {
    static {
        System.out.println("ConstClass被初始化了。。。");
    }
    public static final String HELLO = "hello world";
}

public class Test2 {

    public static void main(String[] args) {
        System.out.println(ConstClass.HELLO);//輸出結(jié)果：hello world
    }

}

下面我們?cè)敿?xì)的說一下java虛擬機(jī)中類加載的全過程：加載、驗(yàn)證、準(zhǔn)備、解析和初始化這5個(gè)階段鎖執(zhí)行的具體工作。

“加載” 是 “類加載” 過程的一個(gè)階段，切不可將二者混淆。

加載階段由三個(gè)基本動(dòng)作組成：

1) 通過類型的完全限定名，產(chǎn)生一個(gè)代表該類型的二進(jìn)制數(shù)據(jù)流（根本沒有指明從哪里獲取、怎樣獲取，可以說一個(gè)非常開放的平臺(tái)了）

2) 解析這個(gè)二進(jìn)制數(shù)據(jù)流為方法區(qū)內(nèi)的運(yùn)行時(shí)數(shù)據(jù)結(jié)構(gòu)

3) 創(chuàng)建一個(gè)表示該類型的java.lang.Class類的實(shí)例，作為方法區(qū)這個(gè)類的各種數(shù)據(jù)的訪問入口。

通過類型的完全限定名，產(chǎn)生一個(gè)代表該類型的二進(jìn)制數(shù)據(jù)流的幾種常見形式：

從zip包中讀取，成為日后JAR、EAR、WAR格式的基礎(chǔ)；

從網(wǎng)絡(luò)中獲取，這種場景最典型的應(yīng)用就是Applet;

運(yùn)行時(shí)計(jì)算生成，這種場景最常用的就是動(dòng)態(tài)代理技術(shù)了；

由其他文件生成，比如我們的JSP；

注意： 非數(shù)組類加載階段既可以使用系統(tǒng)提供的類加載器來完成，也可以由用戶自定義的類加載器去完成。（即重寫一個(gè)類加載器的loadClass（）方法）

驗(yàn)證是連接階段的第一步，這一階段的目的是為了確保Class文件的字節(jié)流中包含的信息符合當(dāng)前虛擬機(jī)的要求，并且不會(huì)危害虛擬機(jī)自身的安全。

虛擬機(jī)如果不檢查輸入的字節(jié)流，并對(duì)其完全信任的話，很可能會(huì)因?yàn)檩d入了有害的字節(jié)流而導(dǎo)致系統(tǒng)崩潰，所以驗(yàn)證是虛擬機(jī)對(duì)自身保護(hù)的一項(xiàng)重要工作。這個(gè)階段是否嚴(yán)謹(jǐn)，直接決定了java虛擬機(jī)是否能承受惡意代碼的攻擊。

從整體上看，驗(yàn)證階段大致上會(huì)完成4個(gè)階段的校驗(yàn)工作：文件格式、元數(shù)據(jù)、字節(jié)碼、符號(hào)引用。

驗(yàn)證字節(jié)流是否符合Class文件格式的規(guī)范，并且能被當(dāng)前版本的虛擬機(jī)處理。該驗(yàn)證階段的主要目的是保證輸入的字節(jié)流能正確地解析并存儲(chǔ)于方法區(qū)之內(nèi)。這個(gè)階段驗(yàn)證是基于二進(jìn)制字節(jié)流進(jìn)行的，只有通過這個(gè)階段的驗(yàn)證后，字節(jié)流才會(huì)進(jìn)入內(nèi)存的方法區(qū)進(jìn)行存儲(chǔ)，所以后面的3個(gè)階段的全部是基于方法區(qū)的存儲(chǔ)結(jié)構(gòu)進(jìn)行的，不會(huì)再直接操作字節(jié)流。

該階段對(duì)字節(jié)碼描述的信息進(jìn)行語義分析，以保證其描述的信息符合Java語言規(guī)范的要求，目的是保證不存在不符合Java語言規(guī)范的元數(shù)據(jù)信息。

該階段主要工作時(shí)進(jìn)行數(shù)據(jù)流和控制流分析，保證被校驗(yàn)類的方法在運(yùn)行時(shí)不會(huì)做出危害虛擬機(jī)安全的行為。 例如，保證跳轉(zhuǎn)指令不會(huì)跳轉(zhuǎn)到方法體以外的字節(jié)碼指令上、保證方法體中的類型轉(zhuǎn)換是有效的等等。

由于數(shù)據(jù)流校驗(yàn)的高復(fù)雜性，耗時(shí)較大，所以JDK1.6之后，在Javac中引入一項(xiàng)優(yōu)化方法（可以通過參數(shù)關(guān)閉）：在方法體的Code屬性的屬性表中增加一項(xiàng)“StackMapTable”屬性，該屬性描述了方法體中所有基本塊開始時(shí)本地變量表和操作棧應(yīng)有的狀態(tài)，從而將字節(jié)碼驗(yàn)證的類型推導(dǎo)轉(zhuǎn)變?yōu)轭愋蜋z查從而節(jié)省一些時(shí)間。

注意： 如果一個(gè)方法體通過了字節(jié)碼驗(yàn)證，也不能說明其一定是安全的，因?yàn)樾ｒ?yàn)程序邏輯無法做到絕對(duì)精確。

最后一個(gè)階段的校驗(yàn)發(fā)生在虛擬機(jī)將符號(hào)引用轉(zhuǎn)化為直接引用的時(shí)候，這個(gè)轉(zhuǎn)化動(dòng)作將在連接的第三個(gè)階段——解析階段中發(fā)生。符號(hào)引用驗(yàn)證的目的是確保解析動(dòng)作能正常執(zhí)行。

驗(yàn)證的內(nèi)容主要有：

符號(hào)引用中通過字符串描述的全限定名是否能找到對(duì)應(yīng)的類；

在指定類中是否存在符號(hào)方法的字段描述及簡單名稱所描述的方法和字段；

符號(hào)引用中的類、字段和方法的訪問性（private、protected、public、default）是否可被當(dāng)前類訪問。

準(zhǔn)備階段是正式為類變量分配內(nèi)存并設(shè)置類變量初始值的階段，這些變量所使用的內(nèi)存都將在方法區(qū)中進(jìn)行分配。（備注：這時(shí)候進(jìn)行內(nèi)存分配的僅包括類變量（被static修飾的變量），而不包括實(shí)例變量，實(shí)例變量將會(huì)在對(duì)象實(shí)例化時(shí)隨著對(duì)象一起分配在Java堆中）。

初始值通常是數(shù)據(jù)類型的零值：

對(duì)于：public static int value = 123;，那么變量value在準(zhǔn)備階段過后的初始值為0而不是123，這時(shí)候尚未開始執(zhí)行任何java方法，把value賦值為123的動(dòng)作將在初始化階段才會(huì)被執(zhí)行。

一些特殊情況：

對(duì)于：public static final int value = 123;編譯時(shí)Javac將會(huì)為value生成ConstantValue屬性，在準(zhǔn)備階段虛擬機(jī)就會(huì)根據(jù)ConstantValue的設(shè)置將value賦值為123。

基本數(shù)據(jù)類型的零值：

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

那么符號(hào)引用與直接引用有什么關(guān)聯(lián)呢？

符號(hào)引用(Symbolic References)： 符號(hào)引用以一組符號(hào)來描述所引用的目標(biāo)，符號(hào)可以是符合約定的任何形式的字面量，符號(hào)引用與虛擬機(jī)實(shí)現(xiàn)的內(nèi)存布局無關(guān)，引用的目標(biāo)并不一定已經(jīng)加載到內(nèi)存中。

直接引用（Direct References）: 直接引用可以是直接指向目標(biāo)的指針、相對(duì)偏移量或是一個(gè)能間接定位到目標(biāo)的句柄。直接引用與虛擬機(jī)實(shí)現(xiàn)的內(nèi)存布局相關(guān)，引用的目標(biāo)必定已經(jīng)在內(nèi)存中存在。

虛擬機(jī)規(guī)范沒有規(guī)定解析階段發(fā)生的具體時(shí)間，虛擬機(jī)實(shí)現(xiàn)可以根據(jù)需要來判斷到底是在類被加載時(shí)解析還是等到一個(gè)符號(hào)引用將要被使用前才去解析。

同一符號(hào)引用進(jìn)行多次解析請(qǐng)求是很常見的，除invokedynamic指令以外，虛擬機(jī)實(shí)現(xiàn)可以對(duì)第一次解析結(jié)果進(jìn)行緩存，來避免解析動(dòng)作重復(fù)進(jìn)行。無論是否真正執(zhí)行了多次解析動(dòng)作，虛擬機(jī)需要保證的是在同一個(gè)實(shí)體中，如果一個(gè)引用符號(hào)之前已經(jīng)被成功解析過，那么后續(xù)的引用解析請(qǐng)求就應(yīng)當(dāng)一直成功；同樣的，如果 第一次解析失敗，那么其他指令對(duì)這個(gè)符號(hào)的解析請(qǐng)求也應(yīng)該收到相同的異常。

解析動(dòng)作主要針對(duì)類或接口、字段、類方法、接口方法、方法類型、方法句柄和調(diào)用點(diǎn)限定符7類符號(hào)引用進(jìn)行。前面四種引用的解析過程，對(duì)于后面三種，與JDK1.7新增的動(dòng)態(tài)語言支持息息相關(guān)，由于java語言是一門靜態(tài)類型語言，因此沒有介紹invokedynamic指令的語義之前，沒有辦法將他們和現(xiàn)在的java語言對(duì)應(yīng)上。

類初始化階段是類加載的最后一步，前面的類加載過程中，除了在加載階段用戶應(yīng)用程序可以通過自定義類加載器參與之外，其余動(dòng)作完全由虛擬機(jī)主導(dǎo)和控制。到了初始化階段，才真正開始執(zhí)行類中定義的java程序代碼（或者說是字節(jié)碼）。

對(duì)于任意一個(gè)類，都需要由加載它的類加載器和這個(gè)類本身一同確立其在Java虛擬機(jī)中的唯一性。如果兩個(gè)類來源于同一個(gè)Class文件，只要加載它們的類加載器不同，那么這兩個(gè)類就必定不相等。

從Java虛擬機(jī)的角度分為兩種不同的類加載器：啟動(dòng)類加載器（Bootstrap ClassLoader） 和其他類加載器。其中啟動(dòng)類加載器，使用C++語言實(shí)現(xiàn)，是虛擬機(jī)自身的一部分；其余的類加載器都由Java語言實(shí)現(xiàn)，獨(dú)立于虛擬機(jī)之外，并且全都繼承自java.lang.ClassLoader類。（這里只限于HotSpot虛擬機(jī)）。

從Java開發(fā)人員的角度來看，絕大部分Java程序都會(huì)使用到以下3種系統(tǒng)提供的類加載器。

啟動(dòng)類加載器（Bootstrap ClassLoader）：

這個(gè)類加載器負(fù)責(zé)將存放在lib目錄中的，或者被-Xbootclasspath參數(shù)所指定的路徑中的，并且是虛擬機(jī)識(shí)別的（僅按照文件名識(shí)別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會(huì)被加載）類庫加載到虛擬機(jī)內(nèi)存中。

擴(kuò)展類加載器（Extension ClassLoader）：

這個(gè)加載器由sun.misc.Launcher$ExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)加載libext目錄中的，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中的所有類庫，開發(fā)者可以直接使用擴(kuò)展類加載器。

應(yīng)用程序類加載器（Application ClassLoader）：

這個(gè)類加載器由sun.misc.Launcher$AppClassLoader實(shí)現(xiàn)。由于這個(gè)類加載器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也稱它為系統(tǒng)類加載器。它負(fù)責(zé)加載用戶類路徑（ClassPath）上所指定的類庫，開發(fā)者可以直接使用這個(gè)類加載器，如果應(yīng)用程序中沒有自定義過自己的類加載器，一般情況下這個(gè)就是程序中默認(rèn)的類加載器。

我們的應(yīng)用程序都是由這3種類加載器互相配合進(jìn)行加載的，如果有必要，還可以加入自己定義的類加載器。

雙親委派模型（Pattern Delegation Model）,要求除了頂層的啟動(dòng)類加載器外，其余的類加載器都應(yīng)該有自己的父類加載器。這里父子關(guān)系通常是子類通過組合關(guān)系而不是繼承關(guān)系來復(fù)用父加載器的代碼。

雙親委派模型的工作過程： 如果一個(gè)類加載器收到了類加載的請(qǐng)求，先把這個(gè)請(qǐng)求委派給父類加載器去完成（所以所有的加載請(qǐng)求最終都應(yīng)該傳送到頂層的啟動(dòng)類加載器中），只有當(dāng)父加載器反饋?zhàn)约簾o法完成加載請(qǐng)求時(shí)，子加載器才會(huì)嘗試自己去加載。

使用雙親委派模型來組織類加載器之間的關(guān)系，有一個(gè)顯而易見的好處就是java類隨著它的類加載器一起具備了一種帶有優(yōu)先級(jí)的層次關(guān)系。

注意：雙親委派模型是Java設(shè)計(jì)者們推薦給開發(fā)者們的一種類加載器實(shí)現(xiàn)方式，并不是一個(gè)強(qiáng)制性 的約束模型。在java的世界中大部分的類加載器都遵循這個(gè)模型，但也有例外。

雙親委派模型主要出現(xiàn)過3次較大規(guī)?！氨黄茐摹钡那闆r。

第一次破壞是因?yàn)轭惣虞d器和抽象類java.lang.ClassLoader在JDK1.0就存在的，而雙親委派模型在JDK1.2之后才被引入，為了兼容已經(jīng)存在的用戶自定義類加載器，引入雙親委派模型時(shí)做了一定的妥協(xié)：在java.lang.ClassLoader中引入了一個(gè)findClass()方法，在此之前，用戶去繼承java.lang.Classloader的唯一目的就是重寫loadClass()方法。JDK1.2之后不提倡用戶去覆蓋loadClass()方法，而是把自己的類加載邏輯寫到findClass()方法中，如果loadClass()方法中如果父類加載失敗，則會(huì)調(diào)用自己的findClass()方法來完成加載，這樣就可以保證新寫出來的類加載器是符合雙親委派模型規(guī)則的。

第二次破壞是因?yàn)槟Ｐ妥陨淼娜毕?，現(xiàn)實(shí)中存在這樣的場景：基礎(chǔ)的類加載器需要求調(diào)用用戶的代碼，而基礎(chǔ)的類加載器可能不認(rèn)識(shí)用戶的代碼。為此，Java設(shè)計(jì)團(tuán)隊(duì)引入的設(shè)計(jì)時(shí)“線程上下文類加載器（Thread Context ClassLoader）”。這樣可以通過父類加載器請(qǐng)求子類加載器去完成類加載動(dòng)作。已經(jīng)違背了雙親委派模型的一般性原則。

第三次破壞 是由于用戶對(duì)程序動(dòng)態(tài)性的追求導(dǎo)致的。這里所說的動(dòng)態(tài)性是指：“代碼熱替換”、“模塊熱部署”等等比較熱門的詞。說白了就是希望應(yīng)用程序能夠像我們的計(jì)算機(jī)外設(shè)一樣，接上鼠標(biāo)、U盤不用重啟機(jī)器就能立即使用。OSGi是當(dāng)前業(yè)界“事實(shí)上”的Java模塊化標(biāo)準(zhǔn)，OSGi實(shí)現(xiàn)模塊化熱部署的關(guān)鍵是它自定義的類加載器機(jī)制的實(shí)現(xiàn)。每一個(gè)程序模塊（OSGi中稱為Bundle）都有一個(gè)自己的類加載器，當(dāng)需要更換一個(gè)Bundle時(shí)，就把Bundle連同類加載器一起換掉以實(shí)現(xiàn)代碼的熱替換。在OSGi環(huán)境下，類加載器不再是雙親委派模型中的樹狀結(jié)構(gòu)，而是進(jìn)一步發(fā)展為更加復(fù)雜的網(wǎng)狀結(jié)構(gòu)。

本節(jié)主要介紹了類加載過程中：“加載”、“驗(yàn)證”、“準(zhǔn)備”、“解析”、“初始化”這5個(gè)階段中虛擬機(jī)進(jìn)行了了那些動(dòng)作，還介紹了類加載器的工作原理及對(duì)虛擬機(jī)的意義。

歡迎關(guān)注我的微信公眾號(hào):"Java面試通關(guān)手冊(cè)"（一個(gè)有溫度的微信公眾號(hào)，期待與你共同進(jìn)步~~~堅(jiān)持原創(chuàng)，分享美文，分享各種Java學(xué)習(xí)資源）：

引用文字