TMD，JVM類加載原來是這樣的！！！！

接上篇：

通過位元組碼，我們了解了class檔案的結構

通過運行資料區，我們了解了jvm內部的記憶體劃分及結構

接下來，讓我們看看，位元組碼怎么進入jvm的記憶體空間，各自進入那個空間，以及怎么跑起來，

4.1 加載

4.1.1 概述

類的加載就是將class檔案中的二進制資料讀取到記憶體中，然后將該位元組流所代表的靜態資料結構轉化為方法區中運行的資料結構，并且在堆記憶體中生成一個java.lang.Class物件作為訪問方法區資料結構的入口，

注意：

• 加載的位元組碼來源，不一定非得是class檔案，可以是符合位元組碼規范的任意地方，甚至二進制流等
• 從位元組碼到記憶體，是由加載器（ClassLoader）完成的，下面我們詳細看一下加載器相關內容

4.1.2 系統加載器

jvm提供了3個系統加載器，分別是Bootstrp loader、ExtClassLoader 、AppClassLoader

這三個加載器互相成父子繼承關系

1）Bootstrp loader

Bootstrp加載器是用C++語言寫的，它在Java虛擬機啟動后初始化

它主要負責加載以下路徑的檔案：

• %JAVA_HOME%/jre/lib/*.jar

• %JAVA_HOME%/jre/classes/*

• -Xbootclasspath引數指定的路徑

System.out.println(System.getProperty("sun.boot.class.path"));

2）ExtClassLoader

ExtClassLoader是用Java寫的，具體來說就是 sun.misc.Launcher$ExtClassLoader

ExtClassLoader主要加載：

• %JAVA_HOME%/jre/lib/ext/*
• ext下的所有classes目錄
• java.ext.dirs系統變數指定的路徑中類別庫

System.getProperty("java.ext.dirs")

3）AppClassLoader

AppClassLoader也是用Java寫成的，它的實作類是 sun.misc.Launcher$AppClassLoader，另外我們知道ClassLoader中有個getSystemClassLoader方法，此方法回傳的就是它，

• 負責加載 -classpath 所指定的位置的類或者是jar檔案
• 也是Java程式默認的類加載器

System.getProperty("java.class.path")

4）驗證

很簡單，使用一段代碼列印對應的property資訊就可以查到當前三個類加載器所加載的目錄

package com.itheima.jvm.load;

public class SystemLoader {
    public static void main(String[] args) {
        String[] bootstrap = System.getProperty("sun.boot.class.path").split(":");
        String[] ext = System.getProperty("java.ext.dirs").split(":");
        String[] app = System.getProperty("java.class.path").split(":");

        System.out.println("bootstrap:");
        for (String s : bootstrap) {
            System.out.println(s);
        }

        System.out.println();

        System.out.println("ext:");
        for (String s : ext) {
            System.out.println(s);
        }

        System.out.println();

        //app是默認加載器，注意啟動控制臺的 -classpath 選項
        System.out.println("app:");
        for (String s : app) {
            System.out.println(s);
        }

    }
}

4.1.3 自定義加載器

除了上面的系統提供的3種loader，jvm允許自己定義類加載器，典型的在tomcat上：

拓展：感興趣的同學也可以自己寫一下，繼承ClassLoader這個抽象類，并覆寫對應的findClass方法即可

接下來我們看一個重點：雙親委派

4.1.4 雙親委派

1）概述

類加載器加載某個類的時候，因為有多個加載器，甚至可以有各種自定義的，他們呈父子繼承關系，

這給人一種印象，子類的加載會覆寫父類，其實恰恰相反！

與普通類繼承屬性不同，類加載器會優先調父類的load方法，如果父類能加載，直接用父類的，否則最后一步才是自己嘗試加載，從源代碼上可以驗證，

ClassLoader.loadClass()方法：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) { 
          	// 首先，檢測是否已經加載 
            Class<?> c = findLoadedClass(name);
            if (c == null) {
              	//如果沒有加載，開始按如下規則執行：
                long t0 = System.nanoTime();
                try {
                    if (parent != null) { 
                      	//重點！父加載器不為空則呼叫父加載器的loadClass 
                        c = parent.loadClass(name, false);
                    } else { 
                      	//父加載器為空則呼叫Bootstrap Classloader 
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) { 
                }
                if (c == null) {
                    long t1 = System.nanoTime(); 
                  	//父加載器沒有找到，則呼叫findclass，自己查找并加載
                    c = findClass(name); 
                }
            }
            if (resolve) { 
                resolveClass(c);
            }
            return c;
        }
    }

2）為什么這么設計呢？

避免重復加載、 避免核心類篡改

采用雙親委派模式的是好處是Java類隨著它的類加載器一起具備了一種帶有優先級的層次關系，通過這種層級關可以避免類的重復加載，當父親已經加載了該類時，就沒有必要子ClassLoader再加載一次，

其次是考慮到安全因素，java核心api中定義型別不會被隨意替換，假設通過網路傳遞一個名為java.lang.Integer的類，通過雙親委托模式傳遞到啟動類加載器，而啟動類加載器在核心Java，

API發現這個名字的類，發現該類已被加載，并不會重新加載網路傳遞的過來的java.lang.Integer，而直接回傳已加載過的Integer.class

即便是父類沒加載，也會優先讓父類去加載特定系統目錄里的class，你獲取到的依然是jvm內的核心類，而不是你胡亂改寫的，這樣便可以防止核心API庫被隨意篡改，

4.2 驗證

加載完成后，class里定義的類結構就進入了記憶體的方法區，

而接下來，驗證是連接階段的第一步，實際上，驗證和上面的加載是互動進行的（比如class檔案格式驗證），

而之所以把驗證放在加載的后面，是因為除了基本的class檔案格式，還需要其他很多驗證，我們逐個來看：

4.2.1 檔案格式驗證

這個好理解，就是驗證加載的位元組碼是不是符合規范

• 是不是CAFEBABYE開頭
• 主次版本號是否在當前jvm虛擬機可運行的范圍內
• 常量池型別對不對
• 有沒有其他不可識別的資訊
• ……等

總之，根據我們上節講的位元組碼分析，要滿足合法的位元組碼約束

4.2.2 元資料驗證

到java語法級別了，這個階段主要驗證屬性、欄位、類關系、方法等是否合規

• 是否有父類？除了Object其他類必須有
• 是否繼承了不該被繼承的類，比如final
• 是不是抽象類，是的話，方法都完備了沒
• 欄位有沒問題？是不是覆寫了父類里的final
• ……等

總之，經過這個階段，你的類物件結構是ok的了

4.2.3 位元組碼驗證

最復雜的一個階段，

等等，位元組碼前面不是驗證過了嗎？咋還要驗證？

上面的驗證是基本位元組表格式驗證，而這里主要驗證class里定義的方法，看方法內部的code是否合法，

• 型別轉換是不是有問題？
• 指令是否跳到了方法外的位元組碼上？
• ……

經過本階段，可以確保你的代碼執行時，不會發生大的意外

注意！不是完全不會發生，比如你寫了一段代碼，jvm只會知道你的方法執行時符合系統規則，

它也不知道你會不會執行很長很長時間導致系統卡死

4.2.4 符號參考驗證

最后一個階段，

這個階段也好理解，我們上面的位元組碼解讀時，知道位元組碼里有的是直接參考，有的是指向了其他的位元組碼地址，

而符號參考驗證的就是，這些參考的對應的內容是否合法，

• utf8里記了某個類的名字，這個類存在不？
• 方法或欄位參考，這些方法在對應的類里存在不存在？
• 類、欄位、方法等上面的可見性是否合法
• ……

4.3 準備

這個階段為class中定義的各種類變數分配記憶體，并賦初始值，

所做的事情好理解，但是要注意幾點：

4.3.1 變數型別

注意是類變數，也就是類里的靜態變數，而不是new的那些實體變數，new的在下面的初始化階段

• 類變數 = 靜態變數
• 實體變數 = 實體化new出來的那些

4.3.2 存盤位置

理論上這些值都在方法區里，但是注意，方法區本身就是一個邏輯概念，

1.6里，在永久代

1.8以后，靜態類變數如果是一個物件，其實它在堆里，這個上面我們講方法區的時候驗證過，

4.3.3 初始化值

這個值進入了記憶體，那到底記憶體里放的value是啥？

注意！

即便是static變數，它在這個階段初始化進記憶體的依然是它的初始值！

而不是你想要什么就是什么，

看下面兩個實體：

//普通類變數：在準備階段為它開了記憶體空間，但是它的value是int的初始值，也就是 0！
//而真正的123賦值，是在類構造器，也就是下面的初始化階段
public static int a = 123;

//final修飾的類變數，編譯成位元組碼后，是一個ConstantValue型別
//這種型別，在準備階段，直接給定值123，后期也沒有二次初始化一說
public static final int b = 123;

4.4 決議

決議階段開始決議類之間的關系，需要關聯的類被加載，

這涉及到：

• 類或介面的決議：類相關的父子繼承，實作的介面都有哪些型別？
• 欄位的決議：欄位對應的型別？
• 方法的決議：方法的引數、回傳值、關聯了哪些型別
• 介面方法的決議：介面上的型別？

經過決議后，當前class里的方法欄位父子繼承等物件級別的關系決議完成，

這些操作上相關的類資訊也被加載，

4.4 初始化

4.4.1 概述

最后一個步驟，經過這個步驟后，類資訊完全進入了jvm記憶體，直到它被垃圾回收器回收，

前面幾個階段都是虛擬機來搞定的，我們也干涉不了，從代碼上只能遵從它的語法要求，

而這個階段，是賦值，才是我們應用程式中撰寫的有主導權的地方

在準備階段，jvm已經初始化了對應的記憶體空間，final也有了自己的值，但是其他類變數，是在這里賦值完成的，

也就是我們說的：

public static int a = 123;  

這行代碼的123才真正賦值完成，

4.4.2 兩個初始化

1）類變數與實體變數的區分

注意一件事情！

這里所說的初始化是一個class類加載到記憶體的程序，所謂的初始化值得是類里定義的類變數，也就是靜態變數，

這個初始化要和new一個類區分開來，new的是實體變數，是在執行階段才創建的，

2）實體變數創建的程序

當我們在方法里寫了一段代碼，執行程序中，要new一個類的時候，會發生以下事情：

• 在方法區中找到對應型別的類資訊
• 在當前方法堆疊幀的本地變數表中放置一個reference指標
• 在堆中開辟一塊空間，放這個物件的實體
• 將指標指向堆里物件的地址，完工！

本文由傳智教育博學谷教研團隊發布，

如果本文對您有幫助，歡迎關注和點贊；如果您有任何建議也可留言評論或私信，您的支持是我堅持創作的動力，

轉載請注明出處！

標籤：Java

上一篇：重新認識下JVM級別的本地快取框架Guava Cache(2)——深入解讀其容量限制與資料淘汰策略

下一篇：java 基礎——陣列