02.22 直擊面試——JVM“解毒”——類加載子系統

2020-02-22 15:47:44 追逐仰望星空

直擊面試

看你簡歷寫得熟悉JVM，那你說說類的加載過程吧？
我們可以自定義一個String類來使用嗎？
什麼是類加載器，類加載器有哪些？
多線程的情況下，類的加載為什麼不會出現重複加載的情況？
什麼是雙親委派機制？它有啥優勢？可以打破這種機制嗎？

類加載子系統

類加載機制概念

Java虛擬機把描述類的數據從Class文件加載到內存，並對數據進行校驗、轉換解析和初始化，最終形成可以被虛擬機直接使用的Java類型，這就是虛擬機的加載機制。Class文件由類裝載器裝載後，在JVM中將形成一份描述Class結構的元信息對象，通過該元信息對象可以獲知Class的結構信息：如構造函數，屬性和方法等，Java允許用戶藉由這個Class相關的元信息對象間接調用Class對象的功能,這裡就是我們經常能見到的Class類。

類加載子系統作用

類加載子系統負責從文件系統或者網絡中加載class文件，class文件在文件開頭有特定的文件標識（0xCAFEBABE）
ClassLoader只負責class文件的加載。至於它是否可以運行，則由Execution Engine決定
加載的類信息存放於一塊稱為方法區的內存空間。除了類的信息外，方法區中還存放運行時常量池信息，可能還包括字符串字面量和數字常量（這部分常量信息是class文件中常量池部分的內存映射）
Class對象是存放在堆區的

類加載器ClassLoader角色

class file存在於本地硬盤上，可以理解為設計師畫在紙上的模板，而最終這個模板在執行的時候是要加載到JVM當中來根據這個文件實例化出n個一模一樣的實例
class file加載到JVM中，被稱為DNA元數據模板，放在方法區
在.calss文件 -> JVM -> 最終成為元數據模板，此過程就要一個運輸工具（類裝載器），扮演一個快遞員的角色

類加載過程

類從被加載到虛擬機內存中開始，到卸載出內存為止，它的整個生命週期包括：加載、驗證、準備、解析、初始化、使用和卸載七個階段。(驗證、準備和解析又統稱為連接，為了支持Java語言的運行時綁定，所以解析階段也可以是在初始化之後進行的。以上順序都只是說開始的順序，實際過程中是交叉的混合式進行的，加載過程中可能就已經開始驗證了)

1. 加載（Loading）：

通過一個類的全限定名獲取定義此類的二進制字節流
將這個字節流所代表的的靜態存儲結構轉化為方法區的運行時數據結構
在內存中生成一個代表這個類的 java.lang.Class 對象，作為方法區這個類的各種數據的訪問入口

加載 .calss 文件的方式

從本地系統中直接加載
通過網絡獲取，典型場景：Web Applet
從zip壓縮文件中讀取，成為日後jar、war格式的基礎
運行時計算生成，使用最多的是：動態代理技術
由其他文件生成，比如 JSP 應用
從專有數據庫提取.class 文件，比較少見
從加密文件中獲取，典型的防 Class 文件被反編譯的保護措施

2. 連接（Linking）

驗證（Verify）

目的在於確保Class文件的字節流中包含信息符合當前虛擬機要求，保證被加載類的正確性，不會危害虛擬機自身安全
主要包括四種驗證，文件格式驗證，元數據驗證，字節碼驗證，符號引用驗證

準備（Prepare）

為類變量分配內存並且設置該類變量的默認初始值，即零值

這裡不包含用final修飾的static，因為final在編譯的時候就會分配了，準備階段會顯示初始化
這裡不會為實例變量分配初始化，類變量會分配在方法區中，而實例變量是會隨著對象一起分配到Java堆中 private static int i = 1; //變量i在準備階只會被賦值為0，初始化時才會被賦值為1 private final static int j = 2; //這裡被final修飾的變量j，直接成為常量，編譯時就會被分配為2 複製代碼

解析（Resolve）

將常量池內的符號引用轉換為直接引用的過程
事實上，解析操作往往會伴隨著JVM在執行完初始化之後再執行
符號引用就是一組符號來描述所引用的目標。符號引用的字面量形式明確定義在《Java虛擬機規範》的Class文件格式中。直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄
解析動作主要針對類或接口、字段、類方法、接口方法、方法類型等。對應常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等

3. 初始化（Initialization）

初始化階段就是執行類構造器方法<clinit>()的過程/<clinit>
此方法不需要定義，是javac編譯器自動收集類中的所有類變量的賦值動作和靜態代碼塊中的語句合併而來
構造器方法中指令按語句在源文件中出現的順序執行
<clinit>()不同於類的構造器（構造器是虛擬機視角下的<init>()）/<init>/<clinit>
若該類具有父類，JVM會保證子類的<clinit>()執行前，父類的<clinit>()已經執行完畢/<clinit>/<clinit>
虛擬機必須保證一個類的<clinit>()方法在多線程下被同步加鎖/<clinit>

<code>public class ClassInitTest{
  private static int num1 = 30;
  static{
    num1 = 10;
    num2 = 10;     //num2寫在定義變量之前，為什麼不會報錯呢？？
    System.out.println(num2);   //這裡直接打印可以嗎？ 報錯，非法的前向引用，可以賦值，但不可調用
  }
  private static int num2 = 20;  //num2在準備階段就被設置了默認初始值0，初始化階段又將10改為20
  public static void main(String[] args){
    System.out.println(num1);  //10
    System.out.println(num2);   //20
  } 

}/<code>

類的主動使用和被動使用

Java程序對類的使用方式分為：主動使用和被動使用。虛擬機規範規定有且只有5種情況必須立即對類進行“初始化”，即類的主動使用。

創建類的實例、訪問某個類或接口的靜態變量，或者對該靜態變量賦值、調用類的靜態方法（即遇到new、getstatic、putstatic、invokestatic這四條字節碼指令時）
反射
初始化一個類的子類
Java虛擬機啟動時被標明為啟動類的類
JDK7 開始提供的動態語言支持：java.lang.invoke.MethodHandle實例的解析結果，REF_getStatic、REF_putStatic、REF_invokeStatic句柄對應的類沒有初始化，則初始化

除以上五種情況，其他使用Java類的方式被看作是對類的被動使用，都不會導致類的初始化。

eg:

<code>public class NotInitialization {
    public static void main(String[] args) { 
        //只輸出SupperClass int 123,不會輸出SubClass init
        //對於靜態字段，只有直接定義這個字段的類才會被初始化
        System.out.println(SubClass.value); 
    }
}

class SuperClass {
    static {
        System.out.println("SupperClass init");
    }
    public static int value = 123;
}

class SubClass extends SuperClass {
    static {
        System.out.println("SubClass init");
    }
}/<code>

類加載器

JVM支持兩種類型的類加載器，分別為引導類加載器（Bootstrap ClassLoader）和自定義類加載器（User-Defined ClassLoader）
從概念上來講，自定義類加載器一般指的是程序中由開發人員自定義的一類類加載器，但是Java虛擬機規範卻沒有這麼定義，而是將所有派生於抽象類ClassLoader的類加載器都劃分為自定義類加載器

啟動類加載器（引導類加載器，Bootstrap ClassLoader）

這個類加載使用C/C++ 語言實現，嵌套在JVM 內部
它用來加載Java的核心庫（JAVA_HOME/jre/lib/rt.jar、resource.jar或sun.boot.class.path路徑下的內容），用於提供JVM自身需要的類
並不繼承自 java.lang.ClassLoader，沒有父加載器
加載擴展類和應用程序類加載器，並指定為他們的父類加載器
出於安全考慮，Boostrap 啟動類加載器只加載名為java、Javax、sun等開頭的類

擴展類加載器（Extension ClassLoader）

java語言編寫，由sun.misc.Launcher$ExtClassLoader實現
派生於 ClassLoader
父類加載器為啟動類加載器
從java.ext.dirs系統屬性所指定的目錄中加載類庫，或從JDK的安裝目錄的jre/lib/ext 子目錄（擴展目錄）下加載類庫。如果用戶創建的JAR 放在此目錄下，也會自動由擴展類加載器加載

應用程序類加載器（也叫系統類加載器，AppClassLoader）

java語言編寫，由 sun.misc.Lanucher$AppClassLoader 實現
派生於 ClassLoader
父類加載器為擴展類加載器
它負責加載環境變量classpath或系統屬性java.class.path 指定路徑下的類庫
該類加載是程序中默認的類加載器，一般來說，Java應用的類都是由它來完成加載的
通過 ClassLoader#getSystemClassLoader() 方法可以獲取到該類加載器

<code>public class ClassLoaderTest {
    public static void main(String[] args) {
        //獲取系統類加載器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //獲取其上層：擴展類加載器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader);  //sun.misc.Launcher$ExtClassLoader@2503dbd3

        //再獲取其上層：獲取不到引導類加載器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader);     //null

        //對於用戶自定義類來說，默認使用系統類加載器進行加載，輸出和systemClassLoader一樣
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader);  //sun.misc.Launcher$AppClassLoader@135fbaa4

        //String 類使用引導類加載器進行加載。Java的核心類庫都使用引導類加載器進行加載，所以也獲取不到 

        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1);  //null

        //獲取BootstrapClassLoader可以加載的api的路徑
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }
    }
}/<code>

用戶自定義類加載器

在Java的日常應用程序開發中，類的加載幾乎是由3種類加載器相互配合執行的，在必要時，我們還可以自定義類加載器，來定製類的加載方式

為什麼要自定義類加載器？

隔離加載類
修改類加載的方式
擴展加載源（可以從數據庫、雲端等指定來源加載類）
防止源碼洩露（Java代碼容易被反編譯，如果加密後，自定義加載器加載類的時候就可以先解密，再加載）

用戶自定義加載器實現步驟

開發人員可以通過繼承抽象類 java.lang.ClassLoader 類的方式，實現自己的類加載器，以滿足一些特殊的需求
在JDK1.2之前，在自定義類加載器時，總會去繼承ClassLoader類並重寫loadClass()方法，從而實現自定義的類加載類，但是JDK1.2之後已經不建議用戶去覆蓋loadClass()方式，而是建議把自定義的類加載邏輯寫在findClass()方法中
編寫自定義類加載器時，如果沒有太過於複雜的需求，可以直接繼承URLClassLoader類，這樣就可以避免自己去編寫findClass()方法及其獲取字節碼流的方式，使自定義類加載器編寫更加簡潔

ClassLoader常用方法

ClassLoader類，是一個抽象類，其後所有的類加載器都繼承自ClassLoader（不包括啟動類加載器）

對類加載器的引用

JVM必須知道一個類型是由啟動加載器加載的還是由用戶類加載器加載的。如果一個類型是由用戶類加載器加載的，那麼JVM會將這個類加載器的一個引用作為類型信息的一部分保存在方法區中。當解析一個類型到另一個類型的引用的時候，JVM需要保證這兩個類型的類加載器是相同的。

雙親委派機制

Java虛擬機對class文件採用的是按需加載的方式，也就是說當需要使用該類的時候才會將它的class文件加載到內存生成class對象。而且加載某個類的class文件時，Java虛擬機採用的是雙親委派模式，即把請求交給父類處理，它是一種任務委派模式。

工作過程

如果一個類加載器收到了類加載請求，它並不會自己先去加載，而是把這個請求委託給父類的加載器去執行；
如果父類加載器還存在其父類加載器，則進一步向上委託，依次遞歸，請求最終將到達頂層的啟動類加載器；
如果父類加載器可以完成類加載任務，就成功返回，倘若父類加載器無法完成此加載任務，子加載器才會嘗試自己去加載，這就是雙親委派模式

優勢

避免類的重複加載，JVM中區分不同類，不僅僅是根據類名，相同的class文件被不同的ClassLoader加載就屬於兩個不同的類（比如，Java中的Object類，無論哪一個類加載器要加載這個類，最終都是委派給處於模型最頂端的啟動類加載器進行加載，如果不採用雙親委派模型，由各個類加載器自己去加載的話，系統中會存在多種不同的Object類）
保護程序安全，防止核心API被隨意篡改，避免用戶自己編寫的類動態替換 Java的一些核心類，比如我們自定義類：java.lang.String

在JVM中表示兩個class對象是否為同一個類存在兩個必要條件：

類的完成類名必須一致，包括包名
加載這個類的ClassLoader（指ClassLoader實例對象）必須相同

沙箱安全機制

如果我們自定義String類，但是在加載自定義String類的時候會率先使用引導類加載器加載，而引導類加載器在加載的過程中會先加載jdk自帶的文件（rt.jar包中java\\lang\\String.class），報錯信息說沒有main方法就是因為加載的是rt.jar包中的String類。這樣就可以保證對java核心源代碼的保護，這就是簡單的沙箱安全機制。

破壞雙親委派模型

雙親委派模型並不是一個強制性的約束模型，而是Java設計者推薦給開發者的類加載器實現方式，可以“被破壞”，只要我們自定義類加載器，重寫loadClass()方法
，指定新的加載邏輯就破壞了，重寫findClass()方法不會破壞雙親委派。
雙親委派模型有一個問題：頂層ClassLoader，無法加載底層ClassLoader的類。典型例子JNDI、JDBC，所以加入了線程上下文類加載器（Thread Context ClassLoader）,可以通過Thread.setContextClassLoaser()設置該類加載器，然後頂層ClassLoader再使用Thread.getContextClassLoader()獲得底層的ClassLoader進行加載。
Tomcat中使用了自定ClassLoader，並且也破壞了雙親委託機制。每個應用使用WebAppClassloader進行單獨加載，他首先使用WebAppClassloader進行類加載，如果加載不了再委託父加載器去加載，這樣可以保證每個應用中的類不衝突。每個tomcat中可以部署多個項目，每個項目中存在很多相同的class文件（很多相同的jar包），他們加載到jvm中可以做到互不干擾。
利用破壞雙親委派來實現代碼熱替換（每次修改類文件，不需要重啟服務）。因為一個Class只能被一個ClassLoader加載一次，否則會報java.lang.LinkageError。當我們想要實現代碼熱部署時，可以每次都new一個自定義的ClassLoader來加載新的Class文件。JSP的實現動態修改就是使用此特性實現。

作者：Java大猿帥
原文鏈接：https://juejin.im/post/5e50921f5188254903693e82

分享到:

閱讀更多 追逐仰望星空 的文章

關鍵字: 數據結構數據庫 Tomcat