虛擬機類載入機制

一、類載入的階段和時機

　　1.階段

　　　　　　整個生命周期包括：載入（Loading）、驗證（Verification）、準備（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸載（Unloading）7個階段。

　　　　　　其中驗證、準備、解析3個部分統稱為連接（Linking），

　　2.類載入時機

　　　　　　1）遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化。

　　　　　　　　常用：使用new關鍵字實例化對象的時候、讀取或設置一個類的靜態欄位（被final修飾、已在編譯期把結果放入常量池的靜態欄位除外）的時候，以及調用一個類的靜態方法的時候。

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

　　　　　　3）當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化（介面除外）。

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

　　　　　　5）當使用JDK 1.7的動態語言支持時，如果一個java.lang.invoke.MethodHandle實例最後的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，並且這個方法句柄所對應的類沒有進行過初始化，則需要先觸發其初始化

　　　　例子

　　　　　　1.對於靜態欄位，只有直接定義這個欄位的類才會被初始化，因此通過其子類來引用父類中定義的靜態欄位，只會觸發父類的初始化而不會觸發子類的初始化

package org.fenixsoft.classloading；
/**
*被動使用類欄位演示一：
*通過子類引用父類的靜態欄位，不會導致子類初始化
**/
public class SuperClass{
    static{
        System.out.println（"SuperClass init！"）；
    }
    public static int value=123；
}

public class SubClass extends SuperClass{
    static{
        System.out.println（"SubClass init！"）；
    }
}
/*
**
*非主動使用類欄位演示
**/
public class NotInitialization{
    public static void main（String[]args）{
        System.out.println（SubClass.value）；
    }
}

　　　　　　2.類的數組類型

package org.fenixsoft.classloading；
/**
*被動使用類欄位演示二：
*通過數組定義來引用類，不會觸發此類的初始化
*虛擬機會初始化一個[SuperClass的數組類，由虛擬機自動產生，通過執行newarray位元組碼
**/
public class NotInitialization{
    public static void main（String[]args）{
        SuperClass[]sca=new SuperClass[10]；
    }
}    

　　　　　　3.常量欄位(static final)

package org.fenixsoft.classloading；
/**
*被動使用類欄位演示三：
*常量在編譯階段會存入調用類的常量池中，本質上並沒有直接引用到定義常量的類，因此不會觸發定義常量的類的初始化。
**/
public class ConstClass{
    static{
        System.out.println（"ConstClass init！"）；
    }
    public static final String HELLOWORLD="hello world"；
}
/*
**
*非主動使用類欄位演示
**/
public class NotInitialization{
    public static void main（String[]args）{
        System.out.println（ConstClass.HELLOWORLD）；
    }
}

二、類載入過程

　　1.載入

　　　　　　1）通過一個類的全限定名來獲取定義此類的二進位位元組流。

　　　　　　2）將這個位元組流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

　　　　　　3）在記憶體中生成一個代表這個類的java.lang.Class對象，作為方法區這個類的各種數據的訪問入口。

　　　　數組的載入：

　　　　　　數組的元素類型是基本類型：引導類載入器

　　　　　　數組的元素類型是引用類型：遞歸父類載入

　　2.驗證：-Xverify:none取消

　　　　　　1）文件格式驗證：驗證class文件格式，並能被當前虛擬機處理

　　　　　　2）元數據驗證：位元組碼描敘信息進行語義分析，如：類是否有父類，是否與父類欄位衝突

　　　　　　3）位元組碼驗證：確定程式的語義合乎邏輯

　　　　　　4）符號引用驗證：符號引用所引用的字元串的驗證，如：全限定名能否找到對應的類，類、欄位、方法的訪問性

　　3.準備

　　　　為類變數分配記憶體並設置類變數初始值的階段，這些變數所使用的記憶體都將在方法區中進行分配

　　　　註意：類變數（static）、初始值為類型的初值，而並不是“=”號賦予的值；如：int初值為0等；但是static fianl常量除外（欄位表中ConstantValue屬性指定的值）

　　4.解析

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

　　　　　　1）符號引用（Symbolic References）：符號引用以一組符號來描述所引用的目標，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標即可。

　　　　　　　　符號引用與虛擬機實現的記憶體佈局無關，引用的目標並不一定已經載入到記憶體中。

　　　　　　　　各種虛擬機實現的記憶體佈局可以各不相同，但是它們能接受的符號引用必須都是一致的，因為符號引用的字面量形式明確定義在Java虛擬機規範的Class文件格式中。

　　　　　　2）直接引用（Direct References）：直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。

　　　　　　　　直接引用是和虛擬機實現的記憶體佈局相關的，同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同。

　　　　　　　　如果有了直接引用，那引用的目標必定已經在記憶體中存在。

　　　　　　解析的類型：類或介面、欄位、類方法、介面方法、方法類型、方法句柄和調用點限定符

　　　　　　1.類或介面的解析

　　　　　　　　假設當前代碼所處的類為D，如果要把一個從未解析過的符號引用N解析為一個類或介面C的直接引用，那虛擬機完成整個解析的過程需要以下3個步驟：

　　　　　　　　1）非數組類型，那虛擬機將會把代表N的全限定名傳遞給D的類載入器去載入這個類C。

　　　　　　　　2）數組類型，並且數組的元素類型為對象，也就是N的描述符會是類似“[Ljava/lang/Integer”的形式，那將會按照第1點的規則載入數組元素類型。如果N的描述符如前面所假設的形式，需要載入的元素類型就是“java.lang.Integer”，接著由虛擬機生成一個代表此數組維度和元素的數組對象。

　　　　　　　　3）如果上面的步驟沒有出現任何異常，那麼C在虛擬機中實際上已經成為一個有效的類或介面了，但在解析完成之前還要進行符號引用驗證，確認D是否具備對C的訪問許可權。如果發現不具備訪問許可權，將拋出java.lang.IllegalAccessError異常。

　　　　　　2.欄位的解析

　　　　　　　　本類----介面----父類遞歸----不存在拋出異常

　　　　　　3.類方法解析

　　　　　　　　解析出的符號引用不是類，拋出異常----本類----父類----介面（抽象方法拋異常）----不存在拋異常

　　　　　　4.介面方法解析

　　　　　　　　解析出非符號引用不是介面，拋異常----本介面----父介面----不存在拋出異常

　　4.初始化

　　　　　　初始化是執行類構造器<clinit>方法

　　　　　　＜clinit＞（）方法是由編譯器自動收集類中的所有類變數的賦值動作和靜態語句塊（static{}塊）中的語句合併產生的

　　　　　　編譯器收集的順序是由語句在源文件中出現的順序所決定的，靜態語句塊中只能訪問到定義在靜態語句塊之前的變數，定義在它之後的變數，在前面的靜態語句塊可以賦值，但是不能訪問

三、類載入器

　　比較兩個類是否“相等”：同一個類載入器，載入同一個類；才是相等

　　否則同一個Class文件，被同一個虛擬機載入，只要載入它們的類載入器不同，那這兩個類就必定不相等。

　　這裡所指的“相等”，包括代表類的Class對象的equals（）方法、isAssignableFrom（）方法、isInstance（）方法的返回結果，也包括使用instanceof關鍵字做對象所屬關係判定等情況。

　　1.類載入器

　　　　啟動類載入器：載入JAVA_HOME\lib下或-Xbootclasspath指定路徑下的指定類庫

　　　　擴展類載入器：載入ext類庫，任何類庫都行

　　　　應用程式類載入器：用戶用的最多的載入器

　　2.雙親委派模型

　　　　雙親委派模型：保證了類的相等或者說是唯一

　　　　　　如果一個類載入器收到了類載入的請求，它首先不會自己去嘗試載入這個類，而是把這個請求委派給父類載入器去完成，每一個層次的類載入器都是如此，

　　　　　　因此所有的載入請求最終都應該傳送到頂層的啟動類載入器中，只有當父載入器反饋自己無法完成這個載入請求（它的搜索範圍中沒有找到所需的類）時，子載入器才會嘗試自己去載入。

　　3.打破雙親委派模型

　　　　JNDI服務

　　　　　　JNDI提供命名服務和目錄服務，是通過啟動類載入器載入，是對資源的管理

　　　　　　但是既然是管理資源，就要載入應用程式中三方廠商提供的JNDI介面，才能對三方資源進行目錄和命名服務提供

　　　　　　而啟動類載入器是無法載入到這些應用程式中的資源

　　　　　　解決：通過一個ThreadContextClassLoader線程上下文載入器載入

 　　　　OSGi

　　　　　　熱部署，動態的增加和卸載模塊，原有的類載入機制就不合適了