摘要：驗證驗證階段的主要目的是為了確保文件的字節流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。不同的虛擬機對類驗證的實現可能會有所不同，但大致都會完成以下四個階段的驗證文件格式的驗證元數據的驗證字節碼驗證和符號引用驗證。

原文地址

虛擬機把描述類的數據從Class文件加載到內存，并對數據進行校驗，轉換解析和初始化，最終形成可以被虛擬機直接使用的Java類型，This
is the class loading mechanism of the virtual machine

本文基于HotSpot虛擬機

類從被加載到虛擬機內存開始，到卸載出內存為止，整個過程包括加載（Loading）、驗證（Verification）、準備(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸載(Unloading)7個階段。其中驗證、準備、解析3部分統稱為連接。

其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中，加載、驗證、準備和初始化這四個階段發生的順序是確定的，而解析階段則不一定，它在某些情況下可以在初始化階段之后開始，這是為了支持Java語言的運行時綁定（也成為動態綁定或晚期綁定）。另外注意這里的幾個階段是按順序開始，而不是按順序進行或完成，因為這些階段通常都是互相交叉地混合進行的，通常在一個階段執行的過程中調用或激活另一個階段。

關于靜態綁定和動態綁定：

靜態綁定（前期綁定）是指：在程序運行前就已經知道方法是屬于那個類的，在編譯的時候就可以連接到類的中，定位到這個方法。

在Java中，final、private、static修飾的方法以及構造函數都是靜態綁定的，不需程序運行，不需具體的實例對象就可以知道這個方法的具體內容。

動態綁定（后期綁定）是指：在程序運行過程中，根據具體的實例對象才能具體確定是哪個方法。

動態綁定是多態性得以實現的重要因素，它通過方法表來實現：每個類被加載到虛擬機時，在方法區保存元數據，其中，包括一個叫做 方法表（method table）的東西，表中記錄了這個類定義的方法的指針，每個表項指向一個具體的方法代碼。如果這個類重寫了父類中的某個方法，則對應表項指向新的代碼實現處。從父類繼承來的方法位于子類定義的方法的前面。

加載是“類加載”過程的一個階段，這個階段需要完成以下3件事情：

通過一個類的全限定名來獲取定義此類的二進制字節流

將這個字節流所代表的靜態儲存儲結構轉化為方法區的運行時數據結構 （將類信息、靜態變量、字節碼、常量這些.class文件中的內容放入方法區中）

在內存中生成一個代表這個類的java.lang.Class對象，作為方法區這個類的各種數據的訪問入口

關于獲取類的二進制字節流的方法，虛擬機并沒有指明要從哪里獲取，如何獲取。

在Java的發展歷程中，主要出現了以下幾種方法

從ZIP包中讀取

從網絡獲取（例如：Applet）

運行時計算生成（例如：動態代理）

有其他文件生成（例如：JSP應用）

從數據庫中讀取

相對于類加載的其他階段而言，加載階段（準確地說，是加載階段獲取類的二進制字節流的動作）是可控性最強的階段，因為開發人員既可以使用系統提供的類加載器來完成加載，也可以自定義自己的類加載器來完成加載。

加載階段完成后，虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區之中，而且在Java堆中也創建一個java.lang.Class類的對象，這樣便可以通過該對象訪問方法區中的這些數據。

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

危險因素的來源：

Java語言本身是安全的，但是由于Class文件并不一定由Java源代碼編譯而來。所以很可能會載入有害的字節流而導致系統崩潰。

不同的虛擬機對類驗證的實現可能會有所不同，但大致都會完成以下四個階段的驗證：文件格式的驗證、元數據的驗證、字節碼驗證和符號引用驗證。

主要驗證字節流是否符合Class文件格式的規范，并且能夠被當前版本的虛擬機處理。主要包括以下這些驗證點：

是否以魔數0xCAFEBABE開頭

主，次版本號是否在當前虛擬機處理范圍之內

常量池的常量中是否有不被支持的常量類型（檢查常量tag標志）

指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。

CONSTANT_Utf8_info型的常量中是否有不符合UTF8編碼的數據

Class文件中各個部分及文件本身是否有被刪除或附加的其他信息

魔數的概念：很多類型的文件，其起始的幾個字節的內容是固定的（或是有意填充，或是本就如此）。根據這幾個字節的內容就可以確定文件類型，因此這幾個字節的內容被稱為魔數 (magic number)。

class文件魔數CAFEBABE的由來

這個階段的驗證是基于二進制字節流進行的，之后的3個驗證階段全部基于方法區的存儲結構進行的，不會在直接操作字節流。

對字節碼描述的信息進行語義分析（其實就是對類中的各數據類型進行語法校驗），以保證其描述的信息符合Java語言的規范要求。

這個類是否有父類

這個類的父類是否繼承了不允許被繼承的類

如果這個類不是抽象類，是否實現了其父類或接口之中要求實現的所有方法。

類中的字段，方法是否與父類長生矛盾

。。。

該階段驗證的主要工作是進行數據流和控制流分析，對類的方法體進行校驗分析，以保證被校驗的類的方法在運行時不會做出危害虛擬機安全的行為。

這是最后一個階段的驗證，它發生在虛擬機將符號引用轉化為直接引用的時候（解析階段中發生該轉化，后面會有講解），主要是對類自身以外的信息（常量池中的各種符號引用）進行匹配性的校驗。通常要校驗以下內容：

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

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

符合引用中的類，字段，方法的訪問性是否可以被當前類訪問

準備階段是正式為類變量分配內存并設置類變量初始值的階段，這些變量所使用的內存都將在方法區中進行分配。這時候進行內存分配的僅包括類變量（被static修飾的變量），而不包括實例變量，實例變量將會在對象實例化時隨著對象一起分配在堆中。其次，這里所說的初始值“通常情況”下是數據類型的零值

假設一個類變量的定義為：

public static int value = 10；

那么變量value在準備階段過后的初始值為0，而不是10，因為這時候尚未開始執行任何Java方法，而把value賦值為3的putstatic指令是在程序編譯后，存放于類構造器（）方法之中的，所以把value賦值為10的動作將在初始化階段才會執行。

基本數據類型的零值如下：

這一階段還需要注意如下幾點：

對基本數據類型來說，對于類變量（static）和全局變量，如果不顯式地對其賦值而直接使用，則系統會為其賦予默認的零值，而對于局部變量來說，在使用前必須顯式地為其賦值，否則編譯時不通過。

對于同時被static和final修飾的常量，必須在聲明的時候就為其顯式地賦值，否則編譯時不通過；而只被final修飾的常量則既可以在聲明時顯式地為其賦值，也可以在類初始化時顯式地為其賦值，總之，在使用前必須為其顯式地賦值，系統不會為其賦予默認零值。

對于引用數據類型reference來說，如數組引用、對象引用等，如果沒有對其進行顯式地賦值而直接使用，系統都會為其賦予默認的零值，即null。

如果在數組初始化時沒有對數組中的各元素賦值，那么其中的元素將根據對應的數據類型而被賦予默認的零值。

如果類字段的字段屬性表中存在ConstantValue屬性，即同時被final和static修飾，那么在準備階段變量value就會被初始化為ConstValue屬性所指定的值。

假設上面的類變量value被定義為：

public static final int value = 10；

編譯時Javac將會為value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設置將value賦值為10。

static final常量在編譯期就將其結果放入了調用它的類的常量池中。

例如：

public class Test {

    public static int value = 10;
    
    public Test() {
        System.out.println("This is Test Class");
    }
}

public class Main {

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

}

以上代碼只會打印10，不會打印This is Test Class

解析階段是虛擬機將常量池中的符號引用轉化為直接引用的過程。

符號引用，以一組符號來描述所引用的目標，符號可以是任意形式的字面量，只要使用時可以無歧義的定位到目標即可。與虛擬機的內存布局無關，引用的目標不一定已經加載到內存中

直接引用，可以是直接指向目標的指針，相對偏移量或是一個能間接定位到目標的句柄。與虛擬機的內存布局有關，同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不相同。如果有直接引用，那么引用的目標必定在內存中存在。

對同一個符號引用進行多次解析請求時很常見的事情，虛擬機實現可能會對第一次解析的結果進行緩存（在運行時常量池中記錄直接引用，并把常量標示為已解析狀態），從而避免解析動作重復進行。

解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。

判斷所要轉化成的直接引用是對數組類型，還是普通的對象類型的引用，從而進行不同的解析。

對字段進行解析時，會先在本類中查找是否包含有簡單名稱和字段描述符都與目標相匹配的字段，如果有，則查找結束；如果沒有，則會按照繼承關系從上往下遞歸搜索該類所實現的各個接口和它們的父接口，還沒有，則按照繼承關系從上往下遞歸搜索其父類，直至查找結束。

class Super{
    public static int m = 11;
    static{
        System.out.println("執行了super類靜態語句塊");
    }
}


class Father extends Super{
    public static int m = 33;
    static{
        System.out.println("執行了父類靜態語句塊");
    }
}

class Child extends Father{
    static{
        System.out.println("執行了子類靜態語句塊");
    }
}

public class StaticTest{
    public static void main(String[] args){
        System.out.println(Child.m);
    }
}

執行結果如下：
    執行了super類靜態語句塊
    執行了父類靜態語句塊
    33
如果注釋掉Father類中對m定義的那一行，則輸出結果如下：
    執行了super類靜態語句塊
    11

static變量發生在靜態解析階段，也即是初始化之前，此時已經將字段的符號引用轉化為了內存引用，也便將它與對應的類關聯在了一起，由于在子類中沒有查找到與m相匹配的字段，那么m便不會與子類關聯在一起，因此并不會觸發子類的初始化。

理論上是按照上述順序進行搜索解析，但在實際應用中，虛擬機的編譯器實現可能要比上述規范要求的更嚴格一些。如果有一個同名字段同時出現在該類的接口和父類中，或同時在自己或父類的接口中出現，編譯器可能會拒絕編譯。

對類方法的解析與對字段解析的搜索步驟差不多，只是多了判斷該方法所處的是類還是接口的步驟，而且對類方法的匹配搜索，是先搜索父類，再搜索接口。

與類方法解析步驟類似，知識接口不會有父類，因此，只遞歸向上搜索父接口就行了。

初始化階段是類加載過程的最后一步，初始化階段是真正執行類中定義的Java程序代碼（或者說是字節碼）的過程。初始化過程是一個執行類構造器()方法的過程，根據程序員通過程序制定的主觀計劃去初始化類變量和其它資源。把這句話說白一點，其實初始化階段做的事就是給static變量賦予用戶指定的值以及執行靜態代碼塊。

Java虛擬機規范嚴格規定了有且只有5種場景必須立即對類進行初始化：

使用new關鍵字實例化對象、讀取或者設置一個類的靜態字段（被final修飾的靜態字段除外）、調用一個類的靜態方法的時候

使用java.lang.reflect包中的方法對類進行反射調用的時候

初始化一個類，發現其父類還沒有初始化過的時候

虛擬機啟動的時候，虛擬機會先初始化用戶指定的包含main()方法的那個類

當使用jdk1.7動態語言支持時，如果一個java.lang.invoke.MethodHandle實例最后的解析結果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且這個方法句柄所對應的類沒有進行初始化，則需要先出觸發其初始化。(沒理解是什么意思)

class Father{
    public static int a = 1;
    static{
        a = 2;
    }
}

class Child extends Father{
    public static int b = a;
}

public class ClinitTest{
    public static void main(String[] args){
        System.out.println(Child.b);
    }
}

執行上面的代碼，會打印出2，也就是說b的值被賦為了2。

我們來看得到該結果的步驟。首先在準備階段為類變量分配內存并設置類變量初始值，這樣A和B均被賦值為默認值0，而后再在調用（）方法時給他們賦予程序中指定的值。當我們調用Child.b時，觸發Child的（）方法，根據規則2，在此之前，要先執行完其父類Father的（）方法，又根據規則1，在執行（）方法時，需要按static語句或static變量賦值操作等在代碼中出現的順序來執行相關的static語句，因此當觸發執行Father的（）方法時，會先將a賦值為1，再執行static語句塊中語句，將a賦值為2，而后再執行Child類的（）方法，這樣便會將b的賦值為2.

如果我們顛倒一下Father類中“public static int a = 1;”語句和“static語句塊”的順序，程序執行后，則會打印出1。很明顯是根據規則1，執行Father的（）方法時，根據順序先執行了static語句塊中的內容，后執行了“public static int a = 1;”語句。

另外，在顛倒二者的順序之后，如果在static語句塊中對a進行訪問（比如將a賦給某個變量），在編譯時將會報錯，因為根據規則1，它只能對a進行賦值，而不能訪問。

類加載器雖然只用于實現類的加載動作，但它在Java程序中起到的作用卻遠遠不限于類的加載階段。對于任意一個類，都需要由它的類加載器和這個類本身一同確定其在就Java虛擬機中的唯一性，也就是說，即使兩個類來源于同一個Class文件，只要加載它們的類加載器不同，那這兩個類就必定不相等。這里的“相等”包括了代表類的Class對象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回結果，也包括了使用instanceof關鍵字對對象所屬關系的判定結果。

從Java虛擬機的角度來講，只存在兩種不同的類加載器：

啟動類加載器：它使用C++實現（這里僅限于Hotspot，也就是JDK1.5之后默認的虛擬機，有很多其他的虛擬機是用Java語言實現的），是虛擬機自身的一部分。

所有其他的類加載器：這些類加載器都由Java語言實現，獨立于虛擬機之外，并且全部繼承自抽象類java.lang.ClassLoader，這些類加載器需要由啟動類加載器加載到內存中之后才能去加載其他的類。

從Java開發人員的角度來看，類加載器可以大致劃分為以下三類：

啟動類加載器：Bootstrap ClassLoader，跟上面相同。它負責加載存放在JDKjrelib(JDK代表JDK的安裝目錄，下同)下，或被-Xbootclasspath參數指定的路徑中的，并且能被虛擬機識別的類庫（如rt.jar，所有的java.*開頭的類均被Bootstrap ClassLoader加載）。啟動類加載器是無法被Java程序直接引用的。

擴展類加載器：Extension ClassLoader，該加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載JDKjrelibext目錄中，或者由java.ext.dirs系統變量指定的路徑中的所有類庫（如javax.*開頭的類），開發者可以直接使用擴展類加載器。

應用程序類加載器：Application ClassLoader，該類加載器由sun.misc.Launcher$AppClassLoader來實現，它負責加載用戶類路徑（ClassPath）所指定的類，開發者可以直接使用該類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

應用程序都是由這三種類加載器互相配合進行加載的，如果有必要，我們還可以加入自定義的類加載器。因為JVM自帶的ClassLoader只是懂得從本地文件系統加載標準的java class文件，因此如果編寫了自己的ClassLoader，便可以做到如下幾點：

在執行非置信代碼之前，自動驗證數字簽名。

動態地創建符合用戶特定需要的定制化構建類。

從特定的場所取得java class，例如數據庫中和網絡中。

事實上當使用Applet的時候，就用到了特定的ClassLoader，因為這時需要從網絡上加載java class，并且要檢查相關的安全信息，應用服務器也大都使用了自定義的ClassLoader技術。

如上圖展示的類加載之間的這種層次關系，稱為類加載器的雙親委派模型 我們把每一層上面的類加載器叫做當前層類加載器的父加載器，當然，它們之間的父子關系并不是通過繼承關系來實現的，而是使用組合關系來復用父加載器中的代碼。該模型在JDK1.2期間被引入并廣泛應用于之后幾乎所有的Java程序中，但它并不是一個強制性的約束模型，而是Java設計者們推薦給開發者的一種類的加載器實現方式。

雙親委派模型的工作流程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把請求委托給父加載器去完成，依次向上，因此，所有的類加載請求最終都應該被傳遞到頂層的啟動類加載器中，只有當父加載器在它的搜索范圍中沒有找到所需的類時，即無法完成該加載，子加載器才會嘗試自己去加載該類。

使用雙親委派模型來組織類加載器之間的關系，有一個很明顯的好處，就是Java類隨著它的類加載器（說白了，就是它所在的目錄）一起具備了一種帶有優先級的層次關系，這對于保證Java程序的穩定運作很重要。例如，類java.lang.Object類存放在JDKjrelib下的rt.jar之中，因此無論是哪個類加載器要加載此類，最終都會委派給啟動類加載器進行加載，這邊保證了Object類在程序中的各種類加載器中都是同一個類。