JVM實戰---類加載的過程

任何程序都須要加載到內存才能與CPU進行交流

同理, 字節碼.class文件一樣須要加載到內存中，才能夠實例化類

ClassLoader的使命就是提早加載.class 類文件到內存中

在加載類時，使用的是Parents Delegation Model(溯源委派加載模型)

Java的類加載器是一個運行時核心基礎設施模塊，主要是在啓動之初進行類的加載、連接、初始化

第一步，Load階段

讀取類文件產生二進制流，並轉爲特定數據結構，初步校驗cafe babe魔法數、常量池、文件長度、是否有父類等，而後建立對應類的java.lang.Class實例

第二步，Link階段

包括驗證、準備、解析三個步驟

• 驗證是更詳細的校驗，好比final是否合規、類型是否正確、靜態變量是否合理等
• 準備階段是爲靜態變量分配內存，並設定默認值，解析類和方法確保類與類之間的相互引用正確性，完成內存結構佈局第三步，Init 階段執行類構造器<clinit> 方法，若是賦值運算是經過其餘類的靜態方法來完成的，那麼會立刻解析另一個類，在虛擬機棧中執行完畢後經過返回值進行賦值

  類加載是一個將.class字節碼文件實例化成Class對象並進行相關初始化的過程。

在這個過程當中，JVM會初始化繼承樹上尚未被初始化過的全部父類，而且會執行這個鏈路上全部未執行過的靜態代碼塊、靜態變量賦值語句等。

某些類在使用時，也能夠按需由類加載器進行加載。

全小寫的class是關鍵字，用來定義類

而首字母大寫的Class,它是全部class的類

這句話理解起來有難度，類已是現實世界中某種事物的抽象，爲何這個抽象仍是另一個類Class的對象?

示例代碼以下:

● 第1處說明:

Class類下的newInstance()在JDK9中已經置爲過期，使用getDeclaredConstructor().newInstance()的方式

着重說明一下new與newInstance的區別

• new是強類型校驗，能夠調用任何構造方法，在使用new操做的時候，這個類能夠沒有被加載過

• 而Class類下的newInstance是弱類型，只能調用無參構造方法

  • 若是沒有默認構造方法，就拋出InstantiationException異常;
  • 若是此構造方法沒有權限訪問，則拋 IllegalAccessException異常

Java 經過類加載器把類的實現與類的定義進行解耦，因此是實現面向接口編程、依賴倒置的必然選擇。

● 第2處說明:

可使用相似的方式獲取其餘聲明，如註解、方法等

● 第3處說明: private 成員在類外是否能夠修改?

經過setccessible(true),便可使用Class類的set方法修改其值

若是沒有這一步,則拋出以下異常:

類加載器

類加載器是如何定位具體的類文件並讀取的呢?

在類加載器家族中存在着相似人類社會的權力等級制度

• 最高層的Bootstrap

在JVM啓動時建立的,一般由與操做系統相關的本地代碼實現,是最根基的類加載器,負責裝載最核心的Java類,好比Object、System、 String ,Java運行時的rt.jar等jar包

• JDK9的Platform ClassLoader

負責加載<JAVA_HOME>libext目錄中的，或者java.ext.dirs系統變量指定的路徑中的因此類庫;
加載一些擴展的系統類，好比XML、加密、壓縮相關的功能類等;
JDK9以前是Extension ClassLoader.

• 第三層 Application ClassLoader

應用類加載器，主要是加載用戶定義的CLASSPATH路徑下的類

第2、三層類加載器爲Java語言實現，用戶也能夠自定義類加載器

查看本地類加載器的方式以下:

在JDK8環境中，執行結果以下

AppClassLoader的Parent爲Bootstrap,它是經過C/C++實現的，並不存在於JVM體系內,因此輸出爲 null

低層次的當前類加載器，不能覆蓋更高層次類加載器已經加載的類

若是低層次的類加載器想加載一個未知類，要很是禮貌地向上逐級詢問:「請問，這個類已經加載了嗎?」

被詢問的高層次類加載器會自問兩個問題

• 我是否已加載過此類
• 若是沒有，是否能夠加載此類

只有當全部高層次類加載器在兩個問題的答案均爲「否」時，纔可讓當前類加載器加載這個未知類

左側綠色箭頭向上逐級詢問是否已加載此類，直至Bootstrap ClassLoader,而後向下逐級嘗試是否可以加載此類，若是都加載不了，則通知發起加載請求的當前類加載器，准予加載

在右側的三個小標籤裏，列舉了此層類加載器主要加載的表明性類庫，事實上不止於此

經過以下代碼能夠查看Bootstrap 全部已加載類庫

執行結果

Bootstrap加載的路徑能夠追加，不建議修改或刪除原有加載路徑

在JVM中增長以下啓動參數，則能經過Class.forName正常讀取到指定類，說明此參數能夠增長Bootstrap的類加載路徑:

-Xbootclasspath/a:/Users/sss/book/ easyCoding/byJdk11/src

若是想在啓動時觀察加載了哪一個jar包中的哪一個類，能夠增長

-XX:+TraceClassLoading

此參數在解決類衝突時很是實用，畢竟不一樣的JVM環境對於加載類的順序並不是是一致的

有時想觀察特定類的加載上下文，因爲加載的類數量衆多，調試時很難捕捉到指定類的加載過程，這時可使用條件斷點功能

好比，想查看HashMap的加載過程，在loadClass處打個斷點，而且在condition框內輸入如圖

JVM如何確立每一個類在JVM的惟一性

類的全限定名和加載這個類的類加載器的ID

在學習了類加載器的實現機制後，知道雙親委派模型並不是強制模型，用戶能夠自定義類加載器，在什麼狀況下須要自定義類加載器呢?

• 隔離加載類

在某些框架內進行中間件與應用的模塊隔離，把類加載到不一樣的環境
好比，阿里內某容器框架經過自定義類加載器確保應用中依賴的jar包不會影響到中間件運行時使用的jar包

• 修改類加載方式

類的加載模型並不是強制，除Bootstrap外，其餘的加載並不是必定要引入，或者根據實際狀況在某個時間點進行按需進行動態加載

• 擴展加載源

好比從數據庫、網絡，甚至是電視機機頂盒進行加載

• 防止源碼泄露

Java代碼容易被編譯和篡改，能夠進行編譯加密。那麼類加載器也須要自定義，還原加密的字節碼。

實現自定義類加載器的步驟

• 繼承ClassLoader
• 重寫findClass()方法
• 調用defineClass()方法

一個簡單的類加載器實現的示例代碼以下

因爲中間件通常都有本身的依賴jar包，在同一個工程內引用多個框架時，每每被迫進行類的仲裁

按某種規則jar包的版本被統一指定， 致使某些類存在包路徑、類名相同的狀況，就會引發類衝突，致使應用程序出現異常

主流的容器類框架都會自定義類加載器，實現不一樣中間件之間的類隔離，有效避免了類衝突。

1 加載的定位

「加載」是「類加載」(Class Loading)過程的第一步1.1 加載的過程

在加載的過程當中,JVM主要作3件事情

• 經過一個類的全限定名來獲取定義此類的二進制字節流(class文件)

在程序運行過程當中,當要訪問一個類時,若發現這個類還沒有被加載,並知足類初始化的條件時，就根據要被初始化的這個類的全限定名找到該類的二進制字節流,開始加載過程

• 將這個字節流的靜態存儲結構轉化爲方法區的運行時數據結構
• 在內存中建立一個該類的java.lang.Class對象,做爲方法區該類的各類數據的訪問入口

程序在運行中全部對該類的訪問都經過這個類對象,也就是這個Class對象是提供給外界訪問該類的接口

1.2 加載源

JVM規範對於加載過程給予了較大的寬鬆度.通常二進制字節流都從已經編譯好的本地class文件中讀取,此外還能夠從如下地方讀取

• zip包

Jar、War、Ear等String[] str = new String[10];這個數組的數組類型是Ljava.lang.String,而String只是這個數組的元素類型

• 其它文件生成

由JSP文件中生成對應的Class類.

• 數據庫中

將二進制字節流存儲至數據庫中,而後在加載時從數據庫中讀取.有些中間件會這麼作,用來實現代碼在集羣間分發

• 網絡

從網絡中獲取二進制字節流.典型就是Applet.

• 運行時計算生成

動態代理技術,用PRoxyGenerator.generateProxyClass爲特定接口生成形式爲"*$Proxy"的代理類的二進制字節流.1.3 類和數組加載過程的區別數組也有類型,稱爲「數組類型」.如:

當程序在運行過程當中遇到new關鍵字建立一個數組時,由JVM直接建立數組類,再由類加載器建立數組中的元素類型.

而普通類的加載由類加載器建立.既可使用系統提供的引導類加載器,也能夠由用戶自定義的類加載器完成(即重寫一個類加載器的loadClass()方法)

1.4 加載過程的注意點

• JVM規範並未給出類在方法區中存放的數據結構

類完成加載後,二進制字節流就以特定的數據結構存儲在方法區中,但存儲的數據結構是由虛擬機本身定義的,虛擬機規範並無指定

• JVM規範並無指定Class對象存放的位置

在二進制字節流以特定格式存儲在方法區後,JVM會建立一個java.lang.Class類的對象,做爲本類的外部訪問接口
既然是對象就應該存放在Java堆中,不過JVM規範並無給出限制,不一樣的虛擬機根據本身的需求存放這個對象
HotSpot將Class對象存放在方法區.

• 加載階段和連接階段是交叉的

類加載的過程當中每一個步驟的開始順序都有嚴格限制,但每一個步驟的結束順序沒有限制.也就是說,類加載過程當中,必須按照以下順序開始: 加載 -> 連接 -> 初始化

但結束順序無所謂,所以因爲每一個步驟處理時間的長短不一就會致使有些步驟會出現交叉

2 驗證

驗證階段比較耗時,它很是重要但不必定必要(由於對程序運行期沒有影響),若是所運行的代碼已經被反覆使用和驗證過,那麼可使用-Xverify:none參數關閉,以縮短類加載時間

2.1 驗證的目的

保證二進制字節流中的信息符合虛擬機規範,並無安全問題

2.2 驗證的必要性

雖然Java語言是一門安全的語言,它能確保程序猿沒法訪問數組邊界之外的內存、避免讓一個對象轉換成任意類型、避免跳轉到不存在的代碼行.也就是說,Java語言的安全性是經過編譯器來保證的.

可是咱們知道,編譯器和虛擬機是兩個獨立的東西,虛擬機只認二進制字節流,它不會管所得到的二進制字節流是哪來的，固然，若是是編譯器給它的，那麼就相對安全，但若是是從其它途徑得到的，那麼沒法確保該二進制字節流是安全的。

經過上文可知，虛擬機規範中沒有限制二進制字節流的來源，在字節碼層面上,上述Java代碼沒法作到的都是能夠實現的,至少語義上是能夠表達出來的,爲了防止字節流中有安全問題，須要驗證！

2.3 驗證的過程

• 文件格式驗證

驗證字節流是否符合Class文件格式的規範,而且能被當前的虛擬機處理.
本驗證階段是基於二進制字節流進行的,只有經過本階段驗證,才被容許存到方法區
後面的三個驗證階段都是基於方法區的存儲結構進行,不會再直接操做字節流.

經過上文可知，加載開始前，二進制字節流還沒進方法區，而加載完成後，二進制字節流已經存入方法區
而在文件格式驗證前，二進制字節流還沒有進入方法區，文件格式驗證經過以後才進入方法區
也就是說，加載開始後，當即啓動了文件格式驗證，本階段驗證經過後，二進制字節流被轉換成特定數據結構存儲至方法區中，繼而開始下階段的驗證和建立Class對象等操做
這個過程印證了：加載和驗證是交叉進行的

• 元數據驗證

對字節碼描述信息進行語義分析,確保符合Java語法規範.public static final int value = 123;準備階段後 a 的值爲 0，而不是 123，要在初始化以後才變爲 123,但若被final修飾的常量若是有初始值,那麼在編譯階段就會將初始值存入constantValue屬性中,在準備階段就將constantValue的值賦給該字段(此處將value賦爲123).4 解析解析階段是虛擬機將常量池中的符號引用替換爲直接引用的過程.5 初始化真正開始執行類中定義的Java程序代碼(或者說是字節碼)
初始化階段就是執行類構造器clinit()的過程.

• 字節碼驗證

本階段是驗證過程的最複雜的一個階段.
本階段對方法體進行語義分析,保證方法在運行時不會出現危害虛擬機的事件.
字節碼驗證將對類的方法進行校驗分析，保證被校驗的方法在運行時不會作出危害虛擬機的事，一個類方法體的字節碼沒有經過字節碼驗證，那必定有問題，但若一個方法經過了驗證，也不能說明它必定安全

• 符號引用驗證

發生在JVM將符號引用轉化爲直接引用的時候,這個轉化動做發生在解析階段,對類自身之外的信息進行匹配校驗,確保解析能正常執行.3 準備完成兩件事情

• 爲已在方法區中的類的靜態成員變量分配內存
• 爲靜態成員變量設置初始值

初始值爲0、false、null等

clinit()方法由編譯器自動產生，收集類中static{}代碼塊中的類變量賦值語句和類中靜態成員變量的賦值語句。在準備階段，類中靜態成員變量已經完成了默認初始化，而在初始化階段，clinit()方法對靜態成員變量進行顯示初始化。

5.1 初始化過程的注意點

• clinit()方法是IDE自動收集類中全部類變量的賦值動做和靜態語句塊中的語句合併產生的,IDE收集的順序是由語句在源文件中出現的順序所決定的.public class Test {
  static {

  i=0;
  System.out.println(i);//編譯失敗:"非法向前引用"

  }
  static int i = 1;

}

• 靜態代碼塊只能訪問到出如今靜態代碼塊以前的變量,定義在它以後的變量,在前面的靜態語句塊能夠賦值,可是不能訪問.
• 實例構造器init()須要顯示調用父類構造函數,而類的clinit()不須要調用父類的類構造函數,虛擬機會確保子類的clinit()方法執行前已經執行完畢父類的clinit()方法.所以在JVM中第一個被執行的clinit()方法的類確定是java.lang.Object.
• 若是一個類/接口中沒有靜態代碼塊,也沒有靜態成員變量的賦值操做,那麼編譯器就不會爲此類生成clinit()方法.
• 接口也須要經過clinit()方法爲接口中定義的靜態成員變量顯示初始化。
• 接口中不能使用靜態代碼塊,但仍然有變量初始化的賦值操做,所以接口與類同樣都會生成clinit()方法.不一樣的是,執行接口的clinit()方法不須要先執行父接口的clinit()方法.只有當父接口中的靜態成員變量被使用到時纔會執行父接口的clinit()方法.
• 虛擬機會保證在多線程環境中一個類的clinit()方法別正確地加鎖,同步.當多條線程同時去初始化一個類時，只會有一個線程去執行該類的clinit()方法,其它線程都被阻塞等待,直到活動線程執行clinit()方法完畢.

其餘線程雖會被阻塞,只要有一個clinit()方法執行完,其它線程喚醒後不會再進入clinit()方法.同一個類加載器下,一個類型只會初始化一次.

參考

• 《碼到成功》
• 《深刻理解Java虛擬機第二版》