jvm類加載器，類加載機制詳解，看這一篇就夠了

前言

今天咱們來說講jvm裏類加載的過程，咱們寫了那麼多類，殊不知道類的加載過程，豈不是很尷尬。

jvm的啓動是經過引導類加載器（bootstrap class loader）建立一個初始類（initial class）來完成的，這個類是由jvm的具體實現指定的。[來自官方規範]

jvm組成結構之一就是類裝載器子系統，咱們今天就來仔細講講這個組件。

Java代碼執行流程圖

你們經過這個流程圖，瞭解一下咱們寫好的Java代碼是如何執行的，其中要經歷類加載器這個流程，咱們就來仔細講講這裏面的知識點。

類加載子系統

類加載系統架構圖

暫時看不懂這兩張圖不要緊，跟着老哥往下看

類的生命週期

類的生命週期包括：加載、連接、初始化、使用和卸載，其中加載、連接、初始化，屬於類加載的過程，咱們下面仔細講解。使用是指咱們new對象進行使用，卸載指對象被垃圾回收掉了。

類加載的過程

• 第一步：Loading加載

經過類的全限定名（包名 + 類名），獲取到該類的 .class文件的二進制字節流

將二進制字節流所表明的靜態存儲結構，轉化爲方法區運行時的數據結構

在內存中生成一個表明該類的java.lang.Class對象，做爲方法區這個類的各類數據的訪問入口

總結：加載二進制數據到內存 —> 映射成jvm能識別的結構 —> 在內存中生成class文件。

• 第二步：Linking連接

連接是指將上面建立好的class類合併至Java虛擬機中，使之可以執行的過程，可分爲驗證、準備、解析三個階段。

① 驗證（Verify）

確保class文件中的字節流包含的信息，符合當前虛擬機的要求，保證這個被加載的class類的正確性，不會危害到虛擬機的安全。

② 準備（Prepare）

爲類中的 靜態字段分配內存，並設置默認的初始值，好比int類型初始值是0。被final修飾的static字段不會設置，由於final在編譯的時候就分配了

③ 解析（Resolve）

解析階段的目的，是將常量池內的符號引用轉換爲直接引用的過程（將常量池內的符號引用解析成爲實際引用）。若是符號引用指向一個未被加載的類，或者未被加載類的字段或方法，那麼解析將觸發這個類的加載（但未必觸發這個類的連接以及初始化。）

事實上，解析器操做每每會伴隨着 JVM 在執行完初始化以後再執行。 符號引用就是一組符號來描述所引用的目標。符號引用的字面量形式明肯定義在《Java 虛擬機規範》的Class文件格式中。直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄。

解析動做主要針對類、接口、字段、類方法、接口方法、方法類型等。對應常量池中的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等。

• 第三步：initialization初始化

初始化就是執行類的構造器方法 init()的過程。

這個方法不須要定義，是javac編譯器自動收集類中全部類變量的賦值動做和靜態代碼塊中的語句合併來的。

若該類具備父類，jvm會保證父類的init先執行，而後在執行子類的init。

類加載器的分類

• 第一個：啓動類/引導類：Bootstrap ClassLoader

這個類加載器使用C/C++語言實現的，嵌套在JVM內部，java程序沒法直接操做這個類。

它用來加載Java核心類庫，如：JAVA_HOME/jre/lib/rt.jar、resources.jar、sun.boot.class.path路徑下的包，用於提供jvm運行所需的包。

並非繼承自java.lang.ClassLoader，它沒有父類加載器

它加載擴展類加載器和應用程序類加載器，併成爲他們的父類加載器

出於安全考慮，啓動類只加載包名爲：java、javax、sun開頭的類

• 第二個：擴展類加載器：Extension ClassLoader

Java語言編寫，由 sun.misc.Launcher$ExtClassLoader實現，咱們能夠用Java程序操做這個加載器

派生繼承自java.lang.ClassLoader，父類加載器爲啓動類加載器

從系統屬性：java.ext.dirs目錄中加載類庫，或者從JDK安裝目錄：jre/lib/ext目錄下加載類庫。咱們就能夠將咱們本身的包放在以上目錄下，就會自動加載進來了。

• 第三個：應用程序類加載器：Application Classloader

Java語言編寫，由 sun.misc.Launcher$AppClassLoader實現。

派生繼承自java.lang.ClassLoader，父類加載器爲啓動類加載器

它負責加載環境變量classpath或者系統屬性java.class.path指定路徑下的類庫

它是程序中默認的類加載器，咱們Java程序中的類，都是由它加載完成的。

咱們能夠經過ClassLoader#getSystemClassLoader()獲取並操做這個加載器

• 第四個：自定義加載器

通常狀況下，以上3種加載器能知足咱們平常的開發工做，不知足時，咱們還能夠 自定義加載器

好比用網絡加載Java類，爲了保證傳輸中的安全性，採用了加密操做，那麼以上3種加載器就沒法加載這個類，這時候就須要自定義加載器

自定義加載器實現步驟

繼承 java.lang.ClassLoader類，重寫findClass()方法

若是沒有太複雜的需求，能夠直接繼承URLClassLoader類，重寫loadClass方法，具體可參考AppClassLoader和ExtClassLoader。

獲取ClassLoader幾種方式

它是一個抽象類，其後全部的類加載器繼承自 ClassLoader（不包括啓動類加載器）

// 方式一：獲取當前類的 ClassLoader
clazz.getClassLoader()
// 方式二：獲取當前線程上下文的 ClassLoader
Thread.currentThread().getContextClassLoader()
// 方式三：獲取系統的 ClassLoader
ClassLoader.getSystemClassLoader()
// 方式四：獲取調用者的 ClassLoader
DriverManager.getCallerClassLoader()

類加載機制—雙親委派機制

jvm對class文件採用的是按需加載的方式，當須要使用該類時，jvm纔會將它的class文件加載到內存中產生class對象。

在加載類的時候，是採用的雙親委派機制，即把請求交給父類處理的一種任務委派模式。

• 工做原理

（1）若是一個類加載器接收到了類加載的請求，它本身不會先去加載，會把這個請求委託給父類加載器去執行。

（2）若是父類還存在父類加載器，則繼續向上委託，一直委託到啓動類加載器：Bootstrap ClassLoader

（3）若是父類加載器能夠完成加載任務，就返回成功結果，若是父類加載失敗，就由子類本身去嘗試加載，若是子類加載失敗就會拋出ClassNotFoundException異常，這就是雙親委派模式

• 第三方包加載方式：反向委派機制

在Java應用中存在着不少服務提供者接口（Service Provider Interface，SPI），這些接口容許第三方爲它們提供實現，如常見的 SPI 有 JDBC、JNDI等，這些 SPI 的接口屬於 Java 核心庫，通常存在rt.jar包中，由Bootstrap類加載器加載。而Bootstrap類加載器沒法直接加載SPI的實現類，同時因爲雙親委派模式的存在，Bootstrap類加載器也沒法反向委託AppClassLoader加載器SPI的實現類。在這種狀況下，咱們就須要一種特殊的類加載器來加載第三方的類庫，而線程上下文類加載器（雙親委派模型的破壞者）就是很好的選擇。

從圖可知rt.jar核心包是有Bootstrap類加載器加載的，其內包含SPI核心接口類，因爲SPI中的類常常須要調用外部實現類的方法，而jdbc.jar包含外部實現類(jdbc.jar存在於classpath路徑)沒法經過Bootstrap類加載器加載，所以只能委派線程上下文類加載器把jdbc.jar中的實現類加載到內存以便SPI相關類使用。顯然這種線程上下文類加載器的加載方式破壞了「雙親委派模型」，它在執行過程當中拋棄雙親委派加載鏈模式，使程序能夠逆向使用類加載器，固然這也使得Java類加載器變得更加靈活。

• 沙箱安全機制

自定義 String 類，可是在加載自定義 String 類的時候會率先使用引導類加載器加載，而引導類加載器在加載的過程當中會先加載 JDK 自帶的文件（rt.jar 包中的 javalangString.class），報錯信息說沒有 main 方法就是由於加載的 rt.jar 包中的 String 類。這樣能夠保證對 Java 核心源代碼的保護，這就是沙箱安全機制。

IT 老哥

我是一個經過大學四年自學，進入大廠作高級java開

發的程序員。關注我，天天分享技術乾貨，助你進大

廠。我能夠，你也能夠的。

若是你以爲文章寫的還不錯，請幫老哥點個贊！