要點提煉| 理解JVM之類加載機制

本篇將瞭解類加載機制和雙親委派模型這兩大知識考點：

• 概述
• 類加載全過程
• 類加載器&雙親委派模型

---

1.概述

a.JVM類加載機制：是虛擬機把描述類的數據從Class文件加載到內存，並對數據進行校驗、轉換解析和初始化，最終造成可被虛擬機直接使用的Java類型的過程。

b.特性：運行期類加載。即在Java語言裏面，類型的加載、鏈接和初始化過程都是在程序運行期完成的，從而經過犧牲一些性能開銷來換取Java程序的高度靈活性。

JVM運行期動態加載+動態鏈接->Java語言的動態擴展特性

---

2.類加載全過程

類從被加載到虛擬機內存中開始、到卸載出內存爲止，整個生命週期包括7階段：

• 加載（Loading）
• 驗證（Verification）
• 準備（Preparation）
• 解析（Resolution）
• 初始化（Initialization）
• 使用（Using）
• 卸載（Unloading）

其中，驗證、準備、解析這3個部分統稱爲鏈接（Linking），流程以下圖：

注意：

• 『加載』->『驗證』->『準備』->『初始化』->『卸載』這5個階段的順序是肯定的，而『解析』可能爲了支持Java語言的運行時綁定會在『初始化』後纔開始。
• 上述階段一般都是互相交叉地混合式進行的，好比會在一個階段執行的過程當中調用、激活另一個階段。

接下來將分別介紹上述幾個階段。

---

a.加載

任務:

• 經過類的全限定名來獲取定義此類的二進制字節流。如從ZIP包讀取、從網絡中獲取、經過運行時計算生成、由其餘文件生成、從數據庫中讀取等等途徑......
• 將該二進制字節流所表明的靜態存儲結構轉化爲方法區的運行時數據結構，該數據存儲數據結構由虛擬機實現自行定義。
• 在內存中生成一個表明這個類的java.lang.Class對象，它將做爲程序訪問方法區中的這些類型數據的外部接口。

---

b.驗證

• 是鏈接階段的第一步，且工做量在JVM類加載子系統中佔了至關大的一部分。
• 目的：爲了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，而且不會危害虛擬機自身的安全。

因而可知，它能直接決定JVM可否承受惡意代碼的攻擊，所以驗證階段頗有必要，但因爲它對程序運行期沒有影響，並不必定必要，能夠考慮使用-Xverify：none參數來關閉大部分的類驗證措施，以縮短虛擬機類加載的時間。

• 檢驗過程包括如下四個階段：
  • 文件格式驗證：
    • 內容：驗證字節流是否符合Class文件格式的規範、以及是否能被當前版本的虛擬機處理。
    • 目的：保證輸入的字節流能正確地解析並存儲於方法區以內，且格式上符合描述一個Java類型信息的要求。只有保證二進制字節流經過了該驗證後，它纔會進入內存的方法區中進行存儲，因此後續3個驗證階段所有是基於方法區而不是字節流了。
  • 元數據驗證：
    • 內容：對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言規範的要求。
    • 目的：對類的元數據信息進行語義校驗，保證不存在不符合Java語言規範的元數據信息。
  • 字節碼驗證：是驗證過程當中最複雜的一個階段。
    • 內容：對類的方法體進行校驗分析，保證被校驗類的方法在運行時不會作出危害虛擬機安全的事件。
    • 目的：經過數據流和控制流分析，肯定程序語義是合法的、符合邏輯的。
  • 符號引用驗證：
    • 內容：對類自身之外（如常量池中的各類符號引用）的信息進行匹配性校驗。
    • 目的是確保解析動做能正常執行，若是沒法經過符號引用驗證，那麼將會拋出一個java.lang.IncompatibleClassChangeError異常的子類。
    • 注意：該驗證發生在虛擬機將符號引用轉化爲直接引用的時候，即『解析』階段。

---

c.準備

任務：

• 爲類變量分配內存：由於這裏的變量是由方法區分配內存的，因此僅包括類變量而不包括實例變量，後者將會在對象實例化時隨着對象一塊兒分配在Java堆中。
• 設置類變量初始值：一般狀況下零值。

---

d.解析

• 以前提過，解析階段就是虛擬機將常量池內的符號引用替換爲直接引用的過程。
  • 符號引用（Symbolic References）：以一組符號來描述所引用的目標。
    • 能夠是任何形式的字面量，只要使用時能無歧義地定位到目標便可。
    • 與虛擬機實現的內存佈局無關，由於符號引用的字面量形式明肯定義在Java虛擬機規範的Class文件格式中，因此即便各類虛擬機實現的內存佈局不一樣，可是能接受符號引用都是一致的。
  • 直接引用（Direct References）：
    • 能夠是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。
    • 與虛擬機實現的內存佈局相關，同一個符號引用在不一樣虛擬機實例上翻譯出來的直接引用通常不一樣。
• 發生時間：JVM會根據須要來判斷，是在類被加載器加載時就對常量池中的符號引用進行解析，仍是等到一個符號引用將要被使用前纔去解析。
• 解析動做：有7類符號及其對應在常量池的7種常量類型
  • 類或接口(CONSTANT_Class_info)
  • 字段(CONSTANT_Fieldref_info)
  • 類方法(CONSTANT_Methodref_info)
  • 接口方法(CONSTANT_InterfaceMethodref_info)
  • 方法類型(CONSTANT_MethodType_info)
  • 方法句柄(CONSTANT_MethodHandle_info)
  • 調用點限定符(CONSTANT_InvokeDynamic_info)

舉個例子，設當前代碼所處的爲類D，把一個從未解析過的符號引用N解析爲一個類或接口C的直接引用，解析過程分三步：

• 若C不是數組類型：JVM將會把表明N的全限定名傳遞給D類加載器去加載這個類C。在加載過程當中，因爲元數據驗證、字節碼驗證的須要，又可能觸發其餘相關類的加載動做。一旦這個加載過程出現了任何異常，解析過程就宣告失敗。
• 若C是數組類型且數組元素類型爲對象：JVM也會按照上述規則加載數組元素類型。
• 若上述步驟無任何異常：此時C在JVM中已成爲一個有效的類或接口，但在解析完成前還需進行符號引用驗證，來確認D是否具有對C的訪問權限。若是發現不具有訪問權限，將拋出java.lang.IllegalAccessError異常。

---

e.初始化

• 是類加載過程的最後一步，會開始真正執行類中定義的Java字節碼。而以前的類加載過程當中，除了在『加載』階段用戶應用程序可經過自定義類加載器參與以外，其他階段均由虛擬機主導和控制。
• 與『準備』階段的區分：
  • 準備階段：變量賦初始零值。
  • 初始化階段：根據Java程序的設定去初始化類變量和其餘資源，或者說是執行類構造器<clinit>()的過程。

<clinit>()：由編譯器自動收集類中的全部類變量的賦值動做和靜態語句塊static{}中的語句合併產生。

• 是線程安全的，在多線程環境中被正確地加鎖、同步。
• 對於類或接口來講是非必需的，若是一個類中沒有靜態語句塊，也沒有對變量的賦值操做，那麼編譯器能夠不爲這個類生成 <clinit>()。
• 接口與類不一樣的是，執行接口的 <clinit>()不須要先執行父接口的 <clinit>()，只有當父接口中定義的變量使用時，父接口才會初始化。另外，接口的實現類在初始化時也同樣不會執行接口的<clinit>()。

• 在虛擬機規範中，規定了有且只有五種狀況必須當即對類進行『初始化』：
  • 遇到new、getstatic、putstatic或invokestatic這4條字節碼指令時；
  • 使用java.lang.reflect包的方法對類進行反射調用的時候；
  • 當初始化一個類的時候，若發現其父類還未進行初始化，需先觸發其父類的初始化；
  • 在虛擬機啓動時，需指定一個要執行的主類，虛擬機會先初始化它；
  • 當使用JDK1.7的動態語言支持時，若一個java.lang.invoke.MethodHandle實例最後的解析結果爲REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，且這個方法句柄所對應的類未進行初始化，需先觸發其初始化。

---

3.類加載器&雙親委派模型

每一個類加載器都擁有一個獨立的類名稱空間，它不只用於加載類，還和這個類自己一塊兒做爲在JVM中的惟一標識。因此比較兩個類是否相等，只要看它們是否由同一個類加載器加載，即便它們來源於同一個Class文件且被同一個JVM加載，只要加載它們的類加載器不一樣，這兩個類就一定不相等。

a.類加載器

從JVM的角度，可將類加載器分爲兩種：

• 啓動類加載器（Bootstrap ClassLoader）
  • 由C++語言實現，是虛擬機自身的一部分。
  • 負責加載存放在＜JAVA_HOME＞\lib目錄中、或被-Xbootclasspath參數所指定路徑中的、且可被虛擬機識別的類庫。
  • 沒法被Java程序直接引用，若是自定義類加載器想要把加載請求委派給引導類加載器的話，可直接用null代替。
• 其餘類加載器：由Java語言實現，獨立於虛擬機外部，而且全都繼承自抽象類java.lang.ClassLoader，可被Java程序直接引用。常見幾種：
  • 擴展類加載器（Extension ClassLoader）
    • 由sun.misc.Launcher$ExtClassLoader實現。
    • 負責加載＜JAVA_HOME＞\lib\ext目錄中的、或者被java.ext.dirs系統變量所指定的路徑中的全部類庫。
  • 應用程序類加載器（Application ClassLoader）
    • 是默認的類加載器，是ClassLoader#getSystemClassLoader()的返回值，故又稱爲系統類加載器。
    • 由sun.misc.Launcher$App-ClassLoader實現。
    • 負責加載用戶類路徑上所指定的類庫。
  • 自定義類加載器（User ClassLoader）：若是以上類加載起不能知足需求，可自定義。

上述幾種類加載器的關係如圖：

須要注意的是，雖然數組類不經過類加載器建立而是由JVM直接建立的，但仍與類加載器有密切關係，由於數組類的元素類型最終還要靠類加載器去建立。

b.雙親委派模型（Parents Delegation Model）

• 表示類加載器之間的層次關係。
• 前提：除了頂層啓動類加載器外，其他類加載器都應當有本身的父類加載器，且它們之間關係通常不會以繼承（Inheritance）關係來實現，而是經過組合（Composition）關係來複用父加載器的代碼。
• 工做過程：若一個類加載器收到了類加載的請求，它先會把這個請求委派給父類加載器，並向上傳遞，最終請求都傳送到頂層的啓動類加載器中。只有當父加載器反饋本身沒法完成這個加載請求時，子加載器纔會嘗試本身去加載。
• 注意：不是一個強制性的約束模型，而是Java設計者推薦給開發者的一種類加載器實現方式。
• 優勢：類會隨着它的類加載器一塊兒具有帶有優先級的層次關係，可保證Java程序的穩定運做；實現簡單，全部實現代碼都集中在java.lang.ClassLoader的loadClass()中。

好比，某些類加載器要加載java.lang.Object類，最終都會委派給最頂端的啓動類加載器去加載，這樣Object類在程序的各類類加載器環境中都是同一個類。相反，系統中將會出現多個不一樣的Object類，Java類型體系中最基礎的行爲也就沒法保證，應用程序也將會變得一片混亂。