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

《深入理解Java虛擬機：JVM高級特性與最佳實踐（第二版》讀書筆記與常見相關面試題總結

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

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

對類加載器有了解嗎？

什么是雙親委派模型？

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

代碼編譯的結果從本地轉換為字節碼，是存儲格式發展的一小步，卻是編程語言發展的一大步。

上一節我們已經知道了類文件結構，在class文件中描述的各種信息最終都需要加載到虛擬機中之后才能運行和使用。

那么虛擬機是如加載這些class文件呢？class文件中的信息進入到虛擬機后會發生什么變化呢？

虛擬機把描述類的數據從class文件加載到內存，并對數據進行校驗、轉換解析和初始化。最終形成可以被虛擬機最直接使用的java類型的過程就是虛擬機的類加載機制。

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

類從被加載到虛擬機內存到卸出內存為止，它的整個生命周期包括：

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

虛擬機規范嚴格規定了有且只有五種情況必須立即對類進行“初始化”：

使用new關鍵字實例化對象的時候、讀取或設置一個類的靜態字段的時候，已經調用一個類的靜態方法的時候。

使用java.lang.reflect包的方法對類進行反射調用的時候，如果類沒有初始化，則需要先觸發其初始化。

當初始化一個類的時候，如果發現其父類沒有被初始化就會先初始化它的父類。

當虛擬機啟動的時候，用戶需要指定一個要執行的主類（就是包含main()方法的那個類），虛擬機會先初始化這個類；

使用Jdk1.7動態語言支持的時候的一些情況。

而對于接口，當一個接口在初始化時，并不要求其父接口全部都完成了初始化，只有在真正使用到父接口時（如引用父接口中定義的常量）才會初始化。

所有引用類的方式都不會觸發初始化稱為被動引用，下面是3個被動引用例子：

①通過子類引用父類靜態字段，不會導致子類初始化；②通過數組定義引用類，不會觸發此類的初始化

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:通過子類調用父類的靜態字段不會導致子類初始化
        // System.out.println(Subclass.value);//SuperClass（父類）被初始化了。。。66
        // 2:通過數組定義引用類，不會觸發此類的初始化
        SuperClass[] superClasses = new SuperClass[3];
        // 3:通過new 創建對象,可以實現類初始化，必須把1下面的代碼注釋掉才有效果不然經過1的時候類已經初始化了，下面這條語句也就沒用了。
        //SuperClass superClass = new SuperClass();
    }

}

③常量在編譯階段會存入調用類的常量池中，本質上并沒有直接引用定義常量的類，因此不會觸發定義常量的類的初始化

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);//輸出結果：hello world
    }

}

下面我們詳細的說一下java虛擬機中類加載的全過程：加載、驗證、準備、解析和初始化這5個階段鎖執行的具體工作。

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

加載階段由三個基本動作組成：

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

2) 解析這個二進制數據流為方法區內的運行時數據結構

3) 創建一個表示該類型的java.lang.Class類的實例，作為方法區這個類的各種數據的訪問入口。

通過類型的完全限定名，產生一個代表該類型的二進制數據流的幾種常見形式：

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

從網絡中獲取，這種場景最典型的應用就是Applet;

運行時計算生成，這種場景最常用的就是動態代理技術了；

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

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

驗證是連接階段的第一步，這一階段的目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。

虛擬機如果不檢查輸入的字節流，并對其完全信任的話，很可能會因為載入了有害的字節流而導致系統崩潰，所以驗證是虛擬機對自身保護的一項重要工作。這個階段是否嚴謹，直接決定了java虛擬機是否能承受惡意代碼的攻擊。

從整體上看，驗證階段大致上會完成4個階段的校驗工作：文件格式、元數據、字節碼、符號引用。

驗證字節流是否符合Class文件格式的規范，并且能被當前版本的虛擬機處理。該驗證階段的主要目的是保證輸入的字節流能正確地解析并存儲于方法區之內。這個階段驗證是基于二進制字節流進行的，只有通過這個階段的驗證后，字節流才會進入內存的方法區進行存儲，所以后面的3個階段的全部是基于方法區的存儲結構進行的，不會再直接操作字節流。

該階段對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言規范的要求，目的是保證不存在不符合Java語言規范的元數據信息。

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

由于數據流校驗的高復雜性，耗時較大，所以JDK1.6之后，在Javac中引入一項優化方法（可以通過參數關閉）：在方法體的Code屬性的屬性表中增加一項“StackMapTable”屬性，該屬性描述了方法體中所有基本塊開始時本地變量表和操作棧應有的狀態，從而將字節碼驗證的類型推導轉變為類型檢查從而節省一些時間。

注意： 如果一個方法體通過了字節碼驗證，也不能說明其一定是安全的，因為校驗程序邏輯無法做到絕對精確。

最后一個階段的校驗發生在虛擬機將符號引用轉化為直接引用的時候，這個轉化動作將在連接的第三個階段——解析階段中發生。符號引用驗證的目的是確保解析動作能正常執行。

驗證的內容主要有：

符號引用中通過字符串描述的全限定名是否能找到對應的類；

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

符號引用中的類、字段和方法的訪問性（private、protected、public、default）是否可被當前類訪問。

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

初始值通常是數據類型的零值：

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

一些特殊情況：

對于：public static final int value = 123;編譯時Javac將會為value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設置將value賦值為123。

基本數據類型的零值：

解析階段是虛擬機將常量池內的符號引用替換為直接引用的過程。

那么符號引用與直接引用有什么關聯呢？

符號引用(Symbolic References)： 符號引用以一組符號來描述所引用的目標，符號可以是符合約定的任何形式的字面量，符號引用與虛擬機實現的內存布局無關，引用的目標并不一定已經加載到內存中。

直接引用（Direct References）: 直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用與虛擬機實現的內存布局相關，引用的目標必定已經在內存中存在。

虛擬機規范沒有規定解析階段發生的具體時間，虛擬機實現可以根據需要來判斷到底是在類被加載時解析還是等到一個符號引用將要被使用前才去解析。

同一符號引用進行多次解析請求是很常見的，除invokedynamic指令以外，虛擬機實現可以對第一次解析結果進行緩存，來避免解析動作重復進行。無論是否真正執行了多次解析動作，虛擬機需要保證的是在同一個實體中，如果一個引用符號之前已經被成功解析過，那么后續的引用解析請求就應當一直成功；同樣的，如果 第一次解析失敗，那么其他指令對這個符號的解析請求也應該收到相同的異常。

解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。前面四種引用的解析過程，對于后面三種，與JDK1.7新增的動態語言支持息息相關，由于java語言是一門靜態類型語言，因此沒有介紹invokedynamic指令的語義之前，沒有辦法將他們和現在的java語言對應上。

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

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

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

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

啟動類加載器（Bootstrap ClassLoader）：

這個類加載器負責將存放在lib目錄中的，或者被-Xbootclasspath參數所指定的路徑中的，并且是虛擬機識別的（僅按照文件名識別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會被加載）類庫加載到虛擬機內存中。

擴展類加載器（Extension ClassLoader）：

這個加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載libext目錄中的，或者被java.ext.dirs系統變量所指定的路徑中的所有類庫，開發者可以直接使用擴展類加載器。

應用程序類加載器（Application ClassLoader）：

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

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

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

雙親委派模型的工作過程： 如果一個類加載器收到了類加載的請求，先把這個請求委派給父類加載器去完成（所以所有的加載請求最終都應該傳送到頂層的啟動類加載器中），只有當父加載器反饋自己無法完成加載請求時，子加載器才會嘗試自己去加載。

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

注意：雙親委派模型是Java設計者們推薦給開發者們的一種類加載器實現方式，并不是一個強制性 的約束模型。在java的世界中大部分的類加載器都遵循這個模型，但也有例外。

雙親委派模型主要出現過3次較大規模“被破壞”的情況。

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

第二次破壞是因為模型自身的缺陷，現實中存在這樣的場景：基礎的類加載器需要求調用用戶的代碼，而基礎的類加載器可能不認識用戶的代碼。為此，Java設計團隊引入的設計時“線程上下文類加載器（Thread Context ClassLoader）”。這樣可以通過父類加載器請求子類加載器去完成類加載動作。已經違背了雙親委派模型的一般性原則。

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

本節主要介紹了類加載過程中：“加載”、“驗證”、“準備”、“解析”、“初始化”這5個階段中虛擬機進行了了那些動作，還介紹了類加載器的工作原理及對虛擬機的意義。

歡迎關注我的微信公眾號:"Java面試通關手冊"（一個有溫度的微信公眾號，期待與你共同進步~~~堅持原創，分享美文，分享各種Java學習資源）：

引用文字