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指針
• 在堆中開闢一塊空間，放這個對象的實例
• 將指針指向堆里對象的地址，完工！

本文由傳智教育博學谷教研團隊發佈。

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

轉載請註明出處！