慘!字節一面掛!面試官跟我一個Android開發死磕JVM?該知道JVM加載機制了! 類加載 類加載的時機 class文件的加載時機: 類加載過程 類加載器 類加載器繼承關係 雙親委派

最近去字節面了一次,一面就沒有然後了……心累……,面我的是一個主要搞Java的,問了我好多JVM加載機制的問題。
回去後,我決定好好複習一下這個知識點, 這是我遇到的一個比較好的文,分享給大家,希望對大家的面試有幫助。
原文地址:https://muxiaonong.blog.csdn.net/article/details/114162705

類加載

Java虛擬機類加載過程是把Class類文件加載到內存,並對Class文件中的數據進行校驗、轉換解析和初始化,最終形成可以被虛擬機直接使用的java類型的過程

和那些編譯時需要連接工作的語言不同,在Java語言裏,類型的加載,連接和初始化過程都是在程序 運行期間完成的,這種策略雖然會令類加載時稍微增加一些性能開銷,但是會爲java應用程序提供比較高的靈活性。

當我們使用到某個類的時候,如果這個類還未從磁盤上加載到內存中,JVM就會通過三步走策略(加載、連接、初始化)來對這個類進行初始化,JVM完成這三個步驟的名稱,就叫做類加載或者類初始化

類加載的時機

什麼情況下需要開始類加載的第一個階段——加載 ,在Java虛擬機規範中沒有進行強制約束,而是交給虛擬機的具體實現來進行把握,但是對於初始化階段,虛擬機規範嚴格規定了 “有且只有” 五種情況必須立即對類進行初始化(而加載、驗證、準備自然需要在此之前開始),具體情況如下所示:

class文件的加載時機:

關於序號1的詳細解釋:

  • 使用 new 關鍵字實例化對象時
  • 讀取類的靜態變量時(被 final修飾,已在編譯期把結果放入常量池的靜態字段除外)
  • 設置類的靜態變量時
  • 調用一個類的靜態方法時

注意: newarray指令觸發的只是數組類型本身的初始化,而不會導致其相關類型的初始化,比如,new String[]只會直接觸發 String[]類的初始化,也就是觸發對類[Ljava.lang.String的初始化,而直接不會觸發String類的初始化。

生成這四條指令最常見的Java代碼場景是:

對於這5種會觸發類進行初始化的場景,虛擬機規範中使用了一個很強烈的限定語:“有且只有”,這5種場景中的行爲稱爲對一個類進行主動引用。除此之外,所有引用類的方式都不會觸發初始化,稱爲 被動引用。

需要特別指出的是,類的實例化和類的初始化是兩個完全不同的概念:

  • 類的實例化是指創建一個類的實例(對象)的過程;
  • 類的初始化是指爲類各個成員賦初始值的過程,是類生命週期中的一個階段;

被動引用的三個場景:

通過子類引用父類的靜態字段,不會導致子類初始化

/**
 * @program: jvm
 * @ClassName Test1
 * @Description:通過子類引用父類的靜態字段,不會導致子類初始化
 * @author: 牧小農
 * @create: 2021-02-27 11:42
 * @Version 1.0
 **/
public class Test1 {

    static {
        System.out.println("Init Superclass!!!");
    }

    public static void main(String[] args) {
                 int x = Son.count;
    }

}

class Father extends Test1{
    static int count = 1;
    static {
        System.out.println("Init father!!!");
    }
}

class Son extends Father{
    static {
        System.out.println("Init son!!!");
    }
}

輸出:

Init Superclass!!!
Init father!!!

對於靜態字段,只有直接定義這個字段的類纔會被初始化,因此通過其子類來引用父類中定義的靜態字段,只會觸發父類的初始化而不會觸發子類的初始化。至於是否要觸發子類的加載和驗證,在虛擬機中並未明確規定,這點取決於虛擬機的具體實現。對於Sun HotSpot虛擬機來說,可通過-XX:+TraceClassLoading參數觀察到此操作會導致子類的加載。

上面的案例中,由於count字段是在Father類中定義的,因此該類會被初始化,此外,在初始化類Father的時候,虛擬機發現其父類Test1 還沒被初始化,因此虛擬機將先初始化其父類Test1 ,然後初始化子類Father,而Son始終不會被初始化;

  1. 通過數組定義來引用類,不會觸發此類的初始化
/**
 * @program: jvm
 * @ClassName Test2
 * @description:
 * @author: muxiaonong
 * @create: 2021-02-27 12:03
 * @Version 1.0
 **/
public class Test2 {

    public static void main(String[] args) {
        M[] m = new M[8];
    }

}

class M{
    static {
        System.out.println("Init M!!!");
    }
}

運行之後我們會發現沒有輸出 “Init M!!!”,說明沒有觸發類的初始化階段

  1. 常量在編譯階段會存入調用類的常量池中,本質上並沒有直接引用到定義常量的類,因此不會觸發定義常量的類的初始化
/**
 * @program: jvm
 * @ClassName Test3
 * @description:
 * @author: muxiaonong
 * @create: 2021-02-27 12:05
 * @Version 1.0
 **/
public class Test3 {

    public static void main(String[] args) {
        System.out.println(ConstClass.COUNT);
    }

}

class ConstClass{
    static final int COUNT = 1;
    static{
        System.out.println("Init ConstClass!!!");
    }
}

上面代碼運行後也沒有輸出 Init ConstClass!!!,這是因爲雖然在Java源碼中引用了ConstClass 類中的常量COUNT ,但其實在編譯階段通過常量傳播優化,已經將常量的值 "1"存儲到Test3 常量池中了,對常量ConstClass.COUNT的引用實際都被轉化爲Test3 類對自身常量池的引用了,也就是說,實際上Test3 的Class文件之中並沒有ConstClass類的符號引用入口,這兩個類在編譯爲Class文件之後就不存在關係

類加載過程

有一個名叫Class文件,它靜靜的躺在了硬盤上,喫香的喝辣的,他究竟需要一個怎麼樣的過程經歷了什麼,才能夠從舒服的硬盤中到內存中呢?class進入內存總共有三大步。

  • 加載(Loading)
  • 連接(Linking)
  • 初始化(Initlalizing)

1、加載

加載 是 類加載(Class Loading) 過程的一個階段,加載 是 類加載(Class Loading) 過程的一個階段,加載是指將當前類的class文件讀入內存中,並且創建一個 java.lang.Class的對象,也就是說,當程序中使用任何類的時候,系統都會創建一個叫 java.lang.Class對象

在加載階段,虛擬機需要完成以下三個事情:

  • 通過一個類的全限定名類獲取定義此類的二進制字節流(沒有指明只能從一個Class文件中獲取,可以從其他渠道,如:網絡、動態生成、數據庫等)
  • 將這個字節流所代表的靜態存儲結構轉化爲方法區的運行時數據結構
  • 在內存中生成一個代表這個類的java.lang.Class對象,作爲方法區這個類的各種數據的訪問入口

類加載器通常無須等到“首次使用”該類時才加載該類,Java虛擬機規範允許系統預先加載某些類。加載階段與連接階段的部分內容是交叉進行的,加載階段尚未完成,連接階段可能已經開始,但這些夾在夾在階段之中進行的動作,仍然屬於連接階段的內容,這兩個階段的開始時間仍然保持着固定的先後順序。

2、連接

當類被加載之後,系統會生成一個對應的Class對象,就會進入 連接階段,連接階段負責把類的二進制數據合併到JRE中,連接階段又分爲三個小階段

1.1 驗證

驗證是連接階段的第一步,這一階段的主要目的是爲了確保Class文件的字節流中包含的信息符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。Java語言相對於 C/C++ 來說本身是相對安全的語言,驗證階段是非常重要的,這個階段是否嚴謹,決定了Java虛擬機能不能承受惡意代碼的攻擊,當驗證輸入的字節流不符合Class文件格式的約束時,虛擬機會拋出一個 java.lang.VerifyError異常或者子類異常,從大體來說驗證主要分爲四個校驗動作:文件格式驗證、元數據驗證、字節碼驗證、符號引用驗證

文件格式驗證: 主要驗證字節流是否符合Class文件格式的規範,並且能被當前版本的虛擬機處理。主要包含以下幾個方面:

  • 文件格式是否以 CAFEBABE開頭
  • 主次版本是否在虛擬機處理的範圍內
  • 常量池的常量是否有不被支持的常量類型
  • 指向常量的各種索引值是否有指向不存在的常量或者不符合類型的常量
  • CONSTANT_Utf8_info 型的常量是否有不符合UTF8編碼的數據
  • Class文件中各個部分及文件本身是否有被刪除的活附件的信息

元數據驗證: 主要是對字節碼描述的信息進行語義分析,主要目的是對類的元數據進行語義校驗,分析是否符合Java的 語言語法的規範,保證不存在不符合Java語言的規範的元數據的信息,該階段主要驗證的方面包含以下幾個方面:

  • 這個類是否有父類(除java.lang.Object)
  • 這個類的父類是否繼承了不允許被繼承的類(被final 修飾的類)
    如果這個類不是抽象類,是否實現了父類或接口之中要求的所有方法
  • 類中的字段、方法是否和父類產生矛盾

字節碼驗證: 最重要也是最複雜的校驗環節,通過數據流和控制流分析程序語義是否合法、符合邏輯的。主要針對類的方法體進行校驗分析,保證被校驗的類在運行時不會危害虛擬機安全的事情

  • 保證任何時候操作數棧的數據類型和指令代碼序列都能配合工作(例如在操作棧上有一個int類型的數據,保證不會在使用的時候按照long類型來加載到本地變量表中)
  • 跳轉指令不會條狀到方法體以外的字節碼指令上
  • 保證方法體中的數據轉換是有效的,例如可以把一個子類對象賦值給父類數據類型,但是不能把父類賦值給子類數據類型
    符號引用驗證: 針對符號引用轉換直接引用的時候,這個裝換工作會在第三階段(字節碼驗證)解析階段中發生。主要是保證引用一定會被訪問到,不會出現類無法訪問的問題。

1.2 準備

爲類變量 分配內存並設置類變量初始值的階段,這些變量所使用的內存都會在方法區進行分配,在準備階段是把class文件靜態變量賦默認值,注意:不是賦初始值,比如我們 public static int i = 8,在這個步驟 並不是把 i 賦值成8 ,而是先賦值爲0

基本類型的默認值:

在通常情況下初始值是0,但是如果我們把上面的常量加一個final 類修飾的話,那麼這個時候初始值就會編程我們指定的值 public static final int i = 8
編譯的時候Javac會把i的初始值變爲8,

1.3 解析

把class文件常量池裏面用到的符號引用轉換爲直接內存地址,直接可以訪問到的內容
符號引用:以一組符號來描述所引用的目標,符號可以是任何字面形式的字面量,只要不會出現衝突能夠定位到就可以
直接引用:可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄,如果有了直接引用,那引用的目標必定已經在內存中存在了

3、初始化

初始化是給類的靜態變量賦正確的初始值,剛纔我們有講到準備階段是複製默認值,而初始化是給靜態變量賦值初始值,看下面的語句:
'public static int i = 8'

首先字節碼文件被加載到內存後,先進行連接驗證,通過準備階段,給i分配內存,因爲是static,所以這個時候i 等於int類型的默認初始值是0,所以i 現在是 0,到了初始化的時候,纔會真正把i 賦值爲8

類加載器

類加載器負責加載所有的類,並且爲載入內存中的類生成一個 java.lang.Class實例對象,如果一個類被加載到JVM中後,同一個類不會再次被載入,就像對象有一個唯一的標識,同樣載入的JVM的類也有一個唯一的標識。JVM本身有一個類加載器的層次,這個類加載器本身就是一個普通的Class,所有的Class都是被類加載器加載到內存中,我們可以稱之爲ClassLoader,一個頂級的父類,也是一個abstract抽象類。

Bootstrap: 類加載器的加載過程,分成不同的層次來進行加載,不同的類加載器加載不同的Class,作爲最頂層的Bootstrap,它加載lib裏JDK最核心的內容,比如說rt.jar charset.jar等核心類,當我們調用getClassLoader()拿到這個加載器結果是一個Null的時候,代表我們已經達到了最頂層的加載器

Extension: Extension加載器擴展類,加載擴展包裏的各種各樣的文件,這些擴展包在JDK安裝目錄 jre/lib/ext下的jar

App: 就是我們平時用到的application ,用來加載classpath指定的內容

Custom ClassLoader: 自定義ClassLoader,加載自己自定義的加載器 Custom ClassLoader 的父類加載器是 application 的父類加載器是 Extension的父類加載器是Bootstrap

注意:他們不是繼承關係,而是委託關係

public class ClassLoaderTest {
    public static void main(String[] args) {
        // 查看是誰Load到內存的,執行結果是null,因爲Bootstrap使用C++實現的
        // 在Java裏面沒有class和它對應
        System.out.println(String.class.getClassLoader());

        //這個是核心類庫某個包裏的類執行,執行結果是Null,因爲該類也是被Bootstrap加載的
        System.out.println(sun.awt.HKSCS.class.getClassLoader());

        //這個類是位於ext目錄下某個jar文件裏面,當我們調用他執行結果就是sun.misc.Launcher$ExtClassLoader@a09ee92
        System.out.println(sun.net.spi.nameservice.dns.DNSNameService.class.getClassLoader());

        // 這個是我們自己寫的ClassLoad加載器,由sun.misc.Launcher$AppClassLoader@18b4aac2加載
        System.out.println(ClassLoaderTest.class.getClassLoader());

        // 是Exe的ClassLoader 調用它的getclass(),它本身也是一個class,調用它的getClassLoader,他的ClassLoader的ClassLoader就是我們的Bootstrap所以結果爲Null
        System.out.println(sun.net.spi.nameservice.dns.DNSNameService.class.getClassLoader().getClass().getClassLoader());
        
    }
}

類加載器繼承關係

這個圖講的是ClassLoader從語法上是從誰繼承的,這個圖只是單純的一個語法關係,不是繼承關係,大家可以記住,和上面的類加載沒有一點關係,過分的大家其實可以忽略這個圖

雙親委派

父加載器: 父加載器不是"類加載器的加載器",也不是"類加載器的父類加載器"
雙親委派是一個孩子向父親的方向,然後父親向孩子方向的雙親委派過程

當一個類加載器收到了類加載請求時候,他會先嚐試從自定義裏面去找,同時它內部還維護了緩存,如果在緩存中找到了就直接返回結果,如果沒有找到,就向父類進行委託,父類再去緩存中找,一直到最頂級的父類,如果這個時候還沒有從緩存中獲取到我們想要的結果,這個時候父親就說我你這個事情,我辦不了,你要自己動,然後兒子就自己去查詢對應的class類並加載,如果到了最小的一個兒子還是沒有找到對應的類,就會拋出異常 Class Not Found Exception

爲什麼要弄雙親委派?

這個是類加載器必問的一個面試題。

主要爲了安全,如果任何一個Class都可以把他load到內存中的話,那麼我寫一個 java.lang.String,如果我寫入了有危險的代碼,是不是就會發生安全問題,並且可以保證Java核心api中定義的類型不會被隨意替換,可以防止API內庫被隨意更改,其次是效率問題,如果有緩存在,直接從緩存裏面拿,就不用一遍一遍的去遍歷查詢我們的父類或者子類了。

最後

Android學習是一條漫長的道路,我們要學習的東西不僅僅只有表面的 技術,還要深入底層,弄明白下面的 原理,只有這樣,我們才能夠提高自己的競爭力,在當今這個競爭激烈的世界裏立足。

這裏整合了很多底層原理的知識,還有我認爲比較重要的學習方向和知識點,放在了我的GitHub(點擊此處可看),歡迎大家一起學習進步。

耗時298天,8大模塊、3382頁66萬字,Android開發核心知識筆記!

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