JVM(二):JVM類加載機制

如下圖所示,JVM類加載機制分爲五個部分:加載,驗證,準備,解析,初始化,下面我們就分別來看一下這五個過程。

 

加載

加載是類加載過程中的一個階段,這個階段會在內存中生成一個代表這個類的java.lang.Class對象,作爲方法區這個類的各種數據的入口。注意這裏不一定非得要從一個Class文件獲取,這裏既可以從ZIP包中讀取(比如從jar包和war包中讀取),也可以在運行時計算生成(動態代理),也可以由其它文件生成(比如將JSP文件轉換成對應的Class類)。

驗證

這一階段的主要目的是爲了確保Class文件的字節流中包含的信息是否符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。

準備

準備階段是正式爲類變量分配內存並設置類變量的初始值階段,即在方法區中分配這些變量所使用的內存空間。注意這裏所說的初始值概念,比如一個類變量定義爲:

1

public static int v = 8080;

實際上變量v在準備階段過後的初始值爲0而不是8080,將v賦值爲8080的putstatic指令是程序被編譯後,存放於類構造器<clinit>方法之中,這裏我們後面會解釋。

但是注意如果聲明爲:

1

public static final int v = 8080;

在編譯階段會爲v生成ConstantValue屬性,在準備階段虛擬機會根據ConstantValue屬性將v賦值爲8080。

解析

解析階段是指虛擬機將常量池中的符號引用替換爲直接引用的過程。符號引用就是class文件中的:

  • CONSTANT_Class_info

  • CONSTANT_Field_info

  • CONSTANT_Method_info

等類型的常量。

下面我們解釋一下符號引用和直接引用的概念:

  • 符號引用與虛擬機實現的佈局無關,引用的目標並不一定要已經加載到內存中。各種虛擬機實現的內存佈局可以各不相同,但是它們能接受的符號引用必須是一致的,因爲符號引用的字面量形式明確定義在Java虛擬機規範的Class文件格式中。

  • 直接引用可以是指向目標的指針,相對偏移量或是一個能間接定位到目標的句柄。如果有了直接引用,那引用的目標必定已經在內存中存在。

初始化

初始化階段是類加載最後一個階段,前面的類加載階段之後,除了在加載階段可以自定義類加載器以外,其它操作都由JVM主導。到了初始階段,纔開始真正執行類中定義的Java程序代碼。

初始化階段是執行類構造器<clinit>方法的過程。<clinit>方法是由編譯器自動收集類中的類變量的賦值操作和靜態語句塊中的語句合併而成的。虛擬機會保證<clinit>方法執行之前,父類的<clinit>方法已經執行完畢。p.s: 如果一個類中沒有對靜態變量賦值也沒有靜態語句塊,那麼編譯器可以不爲這個類生成<clinit>()方法。

  • 遇到new,getstatic, putstatic, 或者 invokestatic 這4條字節碼指令時,如果沒有進行過初始化,則需要先觸發其初始化。常見場景有使用new實例化對象,讀取或設置一個類的靜態字段,調用一個類的靜態方法。

  • 使用java.lang.reflect包的方法隊裏進行反射調用的時候,如果沒有進行過初始化,則需先觸發其初始化。

  • 當初始化一個類的時候,發現其父類沒有進行初始化,則先觸發其父類的初始化。

  • 當虛擬機啓動的時候,用戶需要指定一個需要執行的主類(包含main()方法的那個類),虛擬機會先初始化這個主類

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

只有上述五種情況會觸發初始化,也稱爲對一個類進行主動引用,除此以外,所有其他方式都不會觸發初始化,稱爲被動引用。

public class NotInitialization
{
    public static void main(String[] args)
    {
        System.out.println(SubClass.value);
    }
}
​
class SuperClass
{
    public static int value = 123;
    static
    {
        System.out.println("super class init");
    }
}
​
class SubClass extends SuperClass
{
    static
    {
        System.out.println("sub class init");
    }
}

輸出結果:

super class init
123
  • <clinit>()方法是由編譯器自動收集類中的所有變量的賦值動作和靜態語句塊中的語句合併產生的,他按照代碼中出現的順序收集,靜態語句塊中只能訪問到定義在靜態語句塊之前的變量,定義在他之後的,在靜態語句塊中只能賦值不能訪問

  • <clinit>()方法在執行之前必須保證自己父類的類構造器方法已經執行完畢,因此在虛擬機中第一個被執行的<clinit>()方法的類肯定是java.lang.Object

  • 由於父類的<clinit>()方法優先執行,意味着父類中定義的靜態語句塊要優先於子類的變量賦值操作

  • <clinit>()並不是必須的,如果一個類中沒有靜態語句塊,也沒有對變量的賦值操作,那麼編譯器可以不爲這個類生成<clinit>()方法。

  • 接口中不能使用靜態語句塊,但仍然有變量初始化的賦值操作,因此接口與類一樣都會生成<clinit>()方法,但是接口與類不同的是,執行接口的<clinit>()方法不需要先執行父類接口的<clinit>()方法,只有父類接口中定義的變量使用時父類接口才會初始化,另外接口實現類在初始化時也一樣不會執行接口的<clinit>()方法

  • 虛擬機會保證一個類的<clinit>()方法在多線程環境中被正確的加鎖,同步

 

類加載器與雙親委派模型

虛擬機設計團隊把加載動作放到JVM外部實現,以便讓應用程序決定如何獲取所需的類,JVM提供了3種類加載器:

  • 啓動類加載器(Bootstrap ClassLoader):負責加載存放在JDK\jre\lib(JDK代表JDK的安裝目錄,下同)下,或被-Xbootclasspath參數指定的路徑中的,並且能被虛擬機識別的類庫(如rt.jar,所有的java.*開頭的類均被Bootstrap ClassLoader加載)。啓動類加載器是無法被Java程序直接引用的。

  • 擴展類加載器(Extension ClassLoader):該加載器由sun.misc.Launcher$ExtClassLoader實現,它負責加載DK\jre\lib\ext目錄中,或者由java.ext.dirs系統變量指定的路徑中的所有類庫(如javax.*開頭的類),開發者可以直接使用擴展類加載器。

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

JVM通過雙親委派模型進行類的加載,當然我們也可以通過繼承java.lang.ClassLoader實現自定義的類加載器。

當一個類加載器收到類加載任務,會先交給其父類加載器去完成,因此最終加載任務都會傳遞到頂層的啓動類加載器,只有當父類加載器無法完成加載任務時,纔會嘗試執行加載任務。

採用雙親委派的一個好處是比如加載位於rt.jar包中的類java.lang.Object,不管是哪個加載器加載這個類,最終都是委託給頂層的啓動類加載器進行加載,這樣就保證了使用不同的類加載器最終得到的都是同樣一個Object對象。

在有些情境中可能會出現要我們自己來實現一個類加載器的需求,由於這裏涉及的內容比較廣泛,我想以後單獨寫一篇文章來講述,不過這裏我們還是稍微來看一下。我們直接看一下jdk中的ClassLoader的源碼實現:

protected synchronized Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
    // First, check if the class has already been loaded
    Class c = findLoadedClass(name);
    if (c == null) {
        try {
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClass0(name);
            }
        } catch (ClassNotFoundException e) {
            // If still not found, then invoke findClass in order
            // to find the class.
            c = findClass(name);
        }
    }
    if (resolve) {
        resolveClass(c);
    }
    return c;
}
  • 首先通過Class c = findLoadedClass(name);判斷一個類是否已經被加載過。

  • 如果沒有被加載過執行if (c == null)中的程序,遵循雙親委派的模型,首先會通過遞歸從父加載器開始找,直到父類加載器是Bootstrap ClassLoader爲止。

  • 最後根據resolve的值,判斷這個class是否需要解析。

而上面的findClass()的實現如下,直接拋出一個異常,並且方法是protected,很明顯這是留給我們開發者自己去實現的,這裏我們以後我們單獨寫一篇文章來講一下如何重寫findClass方法來實現我們自己的類加載器。

protected Class<?> findClass(String name) throws ClassNotFoundException {
    throw new ClassNotFoundException(name);
}

JVM類加載機制

•全盤負責,當一個類加載器負責加載某個Class時,該Class所依賴的和引用的其他Class也將由該類加載器負責載入,除非顯示使用另外一個類加載器來載入

•雙親委派,先讓父類加載器試圖加載該類,只有在父類加載器無法加載該類時才嘗試從自己的類路徑中加載該類

•緩存機制,緩存機制將會保證所有加載過的Class都會被緩存,當程序中需要使用某個Class時,類加載器先從緩存區尋找該Class,只有緩存區不存在,系統纔會讀取該類對應的二進制數據,並將其轉換成Class對象,存入緩存區。這就是爲什麼修改了Class後,必須重啓JVM,程序的修改纔會生效

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章