第四章虛擬機類加載機制-有解無憂

　　Java虛擬機把描述類的資料從Class檔案加載到記憶體，并對資料進行校驗、轉換決議和初始化，最終形成可以被虛擬機直接使用的Java型別，這個程序稱為虛擬機的類加載機制，

　　Java語言里面，型別的加載、連接和初始化程序都是在程式運行期間完成的，這種策略雖然會令類加載時稍微增加一些性能開銷，但是會為Java應用程式提供高度的靈活性，Java里天生可以動態擴展的語言特性就是依賴運行期動態加載和動態連接這個特點實作的，例如，如果撰寫一個面向介面的應用程式，可以等到運行時再指定其實際的實作類；用戶可以通過Java預定義的和自定義類加載器，讓一個本地的應用程式可以在運行時從網路或其他地方加載一個二進制流作為程式代碼的一部分，這種組裝應用程式的方式目前已廣泛應用于Java程式之中，從最基礎的Applet、JSP到相對復雜的OSGi技術，都使用了Java語言運行期類加載的特性，

　　1. 類加載時機

　　圖7-1中，加載、驗證、準備、初始化和卸載這5個階段的順序是確定的，類的加載程序必須按照這種順序按部就班地開始，而決議階段則不一定：它在某些情況下可以在初始化階段之后再開始，這是為了支持Java語言的運行時系結（也稱為動態系結或晚期系結），
　　

　　虛擬機規范則是嚴格規定了有且只有6種情況必須立即對類進行“ 初始化” （而加載、驗證、準備自然需要在此之前開始）：

　　1）遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化，生成這4條指令的最常見的Java代碼場景是：

使用new關鍵字實體化物件的時候
讀取或設定一個類的靜態欄位（被final修飾、已在編譯期把結果放入常量池的靜態欄位除外）的時候
呼叫一個類的靜態方法的時候，

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

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

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

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

　　6）當一個介面中定義了JDK8新加入的默認方法（被default關鍵字修飾的介面方法）時，如果這個介面的實作類發生了初始化，該介面要在其之前被初始化，

　　除此之外，所有參考型別的方式都不會觸發初始化，稱為被動參考，　　

package org.fenixsoft.classloading;
/**
* 被動使用類欄位演示一：
* 通過子類參考父類的靜態欄位， 不會導致子類初始化
**/
public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    } 
    public static int value = https://www.cnblogs.com/muxianbai/p/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);
    }
}

　　上述代碼運行后，除value值外，只會輸出“SuperClass init!”，對于靜態欄位，只有直接定義這個欄位的類才會被初始化，因此通過其子類來參考父類中定義的靜態欄位，只會觸發父類的初始化，

package org.fenixsoft.classloading;
/**
* 被動使用類欄位演示二：
* 通過陣列定義來參考類， 不會觸發此類的初始化
**/

public class SuperClass {
    static {
        System.out.println("SuperClass init!");
    } 
    public static int value = https://www.cnblogs.com/muxianbai/p/123;
} 

public class NotInitialization {

public static void main(String[] args) {
        SuperClass[] sca = new SuperClass[10];
    }
}

　　上述代碼運行后，并不會輸出“SuperClass init!”，通過陣列定義來參考類，不會觸發此類的初始化，

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);
    }
}

　　第三章提到過，static final修飾的常量會存入呼叫類的常量池中，沒有直接參考到定義常量的類，因此不會觸發定義常量的類的初始化，

　　2. 類加載程序

　　2.1 加載

　　在加載階段，Java虛擬機完成三件事情：

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

　　2）將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構，

　　3）在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料的訪問入口，

　　由于并沒有明確定義從哪里以及如何獲取此類的二進制位元組流，出現了各種各樣的獲取方式，很多重要的java基于建立在這一基礎之上，例如：

從ZIP壓縮包中讀取，這很常見，最終成為日后JAR、EAR、WAR格式的基礎，
從網路中獲取，這種場景最典型的應用就是Web Applet，
運行時計算生成，這種場景使用得最多的就是動態代理技術，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass()來為特定介面生成形式為“*$Proxy”的代理類的二進制位元組流，
由其他檔案生成，典型場景是JSP應用，由JSP檔案生成對應的Class檔案，
從資料庫中讀取，這種場景相對少見些，例如有些中間件服務器（如SAP Netweaver）可以選擇把程式安裝到資料庫中來完成程式代碼在集群間的分發，
可以從加密檔案中獲取，這是典型的防Class檔案被反編譯的保護措施，通過加載時解密Class檔案來保障程式運行邏輯不被窺探，

　　2.2 驗證

　　驗證是連接階段的第一步，這一階段的目的是確保Class檔案的位元組流中包含的資訊符合《Java虛擬機規范》的全部約束要求，Class檔案并不一定只能由Java原始碼編譯而來，在二進制編輯器中敲出的偽Class檔案也可以通過Java虛擬機加載，為了避免載入有錯誤或有惡意企圖的位元組碼流而導致整個系統受攻擊甚至崩潰，Java虛擬機會對位元組碼進行驗證，

　　1）檔案格式驗證驗證位元組流是否符合Class檔案格式的規范，并且能被當前版本的虛擬機處理，

　　2）元資料驗證對位元組碼描述的資訊進行語意分析，

　　3）位元組碼驗證通過資料流分析和控制流分析，確定程式語意是合法的、符合邏輯的，

　　4）符號參考驗證該類是否缺少或者被禁止訪問它依賴的某些外部類、方法、欄位等資源，

　　2.3 準備

　　準備階段正式為類中定義的變數（靜態變數）分配記憶體并設定類變數初始值的階段，通常情況下，靜態變數的初始值為零值，如果是final修飾的靜態變數，如 public static final int value = https://www.cnblogs.com/muxianbai/p/123，類欄位的欄位屬性表中存在ConstantValue屬性，那在準備階段變數值就會被初始化為ConstantValue屬性所指定的初始值，

　　2.4 決議

　　決議階段是Java虛擬機將常量池內的符號參考替換為直接參考的程序，符號參考以一組符號來描述所參考的目標；直接參考是可以直接指向目標的指標、相對偏移量或者是一個能間接定位到目標的句柄，

　　2.5 初始化

　　初始化時機在第一章，序言介紹過，這里不再贅述，

　　3. 類加載器

　　Java虛擬機設計團隊有意把類加載階段中的“通過一個類的全限定名來獲取描述該類的二進制位元組流”這個動作放到Java虛擬機外部去實作，以便讓應用程式自己決定如何去獲取所需的類，實作這個動作的代碼被稱為“類加載器”（Class Loader），

　　3.1 類與類加載器

　　對于任意一個類，都必須由加載它的類加載器和這個類本身一起共同確立其在Java虛擬機中的唯一性，

　　3.2 雙親委派模型

　　JDK 9 之前的類加載器雙親委派模型如下圖所示：　　

啟動類加載器（Bootstrap Class Loader）：這個類加載器負責加載存放在<JAVA_HOME>\lib目錄，或者被-Xbootclasspath引數所指定的路徑中存放的，而且是Java虛擬機能夠識別的（按照檔案名識別，如rt.jar、tools.jar，名字不符合的類別庫即使放在lib目錄中也不會被加載）類別庫加載到虛擬機的記憶體中，
擴展類加載器（Extension Class Loader）：負責加載<JAVA_HOME>\lib\ext目錄中，或者被java.ext.dirs系統變數所指定的路徑中所有的類別庫，是一種Java系統類別庫的擴展機制，JDK的開發團隊允許用戶將具有通用性的類別庫放置在ext目錄里以擴展Java SE的功能，在JDK9之后，這種擴展機制被模塊化帶來的天然的擴展能力所取代，
應用程式類加載器（Application Class Loader）：這個類加載器由sun.misc.Launcher$AppClassLoader來實作，它負責加載用戶類路徑（ClassPath）上所有的類別庫，開發者同樣可以直接在代碼中使用這個類加載器，如果應用程式中沒有自定義過自己的類加載器，一般情況下這個就是程式中默認的類

　　雙親委派模型要求除了頂層的啟動類加載器外，其余的類加載器都應有自己的父類加載器，不過這里類加載器之間的父子關系一般不是以繼承（Inheritance）的關系來實作的，而是通常使用組合（Composition）關系來復用父加載器的代碼，

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

　　使用雙親委派模型的一個好處是Java中的類隨著它的類加載器一起具備了一種帶有優先級的層次關系，例如類java.lang.Object，存放在rt.jar中，無論哪個類加載器要加載這個類，都是委派給最頂端的啟動類加載器進行加載，因此Object類在程式中的各種類加載器環境中都能保證是一個類，

　　雙親委派很好地解決了各個類加載器協作時基礎型別的一致性問題（越基礎的類由越上層的加載器進行加載），基礎型別之所以被稱為“基礎”，是因為它們總是作為被用戶代碼繼承、呼叫的API存在，可是如果有基礎型別需要呼叫用戶代碼，該怎么辦呢？

　　一個典型的例子便是JNDI服務，JNDI現在已經是Java的標準服務，它的代碼由啟動類加載器來完成加載（在JDK 1.3時加入到rt.jar的），肯定屬于Java中很基礎的型別了，但JNDI存在的目的就是對資源進行查找和集中管理，它需要呼叫由其他廠商實作并部署在應用程式的ClassPath下的JNDI服務提供者介面（Service Provider Interface，SPI）的代碼，啟
動類加載器是絕不可能認識、加載這些代碼的，JDK提供了java.util.ServiceLoader類，以META-INF/services中的配置資訊，輔以責任鏈模式，給SPI的加載提供了一種解決方案，

　　4. Java模塊化系統

　　在JDK 9中引入的Java模塊化系統（Java Platform Module System，JPMS）不僅僅像之前的JAR包那樣只是簡單地充當代碼的容器，除了代碼外，Java的模塊定義還包含以下內容：

依賴其它模塊的串列
匯出的包串列，即其他模塊可以使用的串列
開放的包串列，即其他模塊可反射訪問模塊的串列
使用的服務串列
提供服務的實作串列

　　JAR檔案在類路徑的訪問規則：所有類路徑下的JAR檔案及其他資源檔案，都被視為自動打包在一個匿名模塊（Unnamed Module）里，它可以看到和使用類路徑上所有的包、JDK系統模塊中所有的匯出包，以及模塊路徑上所有模塊中匯出的包，

　　模塊在模塊路徑的訪問規則： 模塊路徑下的具名模塊（Named Module）只能訪問到它依賴定義中列明依賴的模塊和包，具名模塊看不見傳統JAR包的內容，

　　JAR檔案在模塊路徑的訪問規則： 如果把一個傳統的、不包含模塊定義的JAR檔案放置到模塊路徑中，它就會變成一個自動模塊（Automatic Module），盡管不包含module-info.class，但自動模塊將默認依賴于整個模塊路徑中的所有模塊，因此可以訪問到所有模塊匯出的包，自動模塊也默認匯出自己所有的包，

　　JDK 9中雖然仍然維持著三層類加載器和雙親委派的架構，但類加載的委派關系也發生了變動，當平臺及應用程式類加載器收到類加載請求，在委派給父加載器加載前，要先判斷該類是否能夠歸屬到某一個系統模塊中，如果可以找到這樣的歸屬關系，就要優先委派給負責那個模塊的加載器完成加載，

　　　

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/298567.html

標籤：其他

上一篇：第三章類檔案結構

下一篇：各大安卓模擬器的adb埠和使用對比

第四章 虛擬機類加載機制

1. 類加載時機

2. 類加載程序

3. 類加載器

4. Java模塊化系統

第四章虛擬機類加載機制

　　1. 類加載時機

　　2. 類加載程序

　　3. 類加載器

　　4. Java模塊化系統