本文實例講述了深入理解JVM之類加載機制。分享給大家供大家參考，具體如下：

概述

虛擬機把描述類的數(shù)據(jù)從Class文件加載到內(nèi)存，并對數(shù)據(jù)進(jìn)行校驗、轉(zhuǎn)換解析和初始化，最終形成可以被虛擬機直接使用的Java類型，這就是虛擬機的類加載機制。

與那些在編譯時需要進(jìn)行鏈接工作的語言不同，在Java語言里，類型的加載、連接和初始化過程都是在程序運行期間完成的，例如import java.util.*下面包含很多類，但是，在程序運行的時候，虛擬機只會加載哪些我們程序需要的類。這種策略雖然會令類加載時稍微增加一些性能開銷，但是會為Java應(yīng)用程序提供高度的靈活性。

類加載的時機

類從創(chuàng)建起（這里的類也可能是接口，下同），就注定了其是有生命周期的（這里的生命周期指的是類在運行期間所經(jīng)歷的過程，與是否存儲在存儲介質(zhì)上無關(guān)）。類從被虛擬機加載到內(nèi)存中開始，到卸載出內(nèi)存為止，它的生命周期經(jīng)歷了加載（Loading）、驗證（Verification）、準(zhǔn)備（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸載（Unloading），一共七個階段，其中驗證、準(zhǔn)備、解析部分統(tǒng)稱為連接。這七個階段可以用如下圖描述：

從上圖中可以明顯看出各個階段是有順序的，加載、驗證、準(zhǔn)備、初始化這個5個階段的順序是固定的，也就是說類的加載過程必須按照這種順序按部就班開始；解析階段則不一定，解析階段的工作完全可能在初始化之后才開始，之所以這么設(shè)計，就是為了支持Java語言的動態(tài)綁定。還有一點需要注意的是，雖然上述的5個階段可能按照順序開始，但是并不是說一個接一個階段完成后才開始，一個階段的進(jìn)行完全可能激活另一個階段的進(jìn)行，交叉混合式的進(jìn)行。

那么什么情況下需要開始類加載過程的第一個階段，加載到內(nèi)存中呢？這就不得不涉及兩個概念：主動引用和被動引用。根據(jù)Java虛擬機的規(guī)范，只有5中情況屬于主動引用：

1. 遇到new（使用new 關(guān)鍵字實例化一個對象）、getstatic（讀取一個類的靜態(tài)字段）、putstatic或者invokestatic（設(shè)置一個類的靜態(tài)字段）這4條指令的時候，如果累沒有進(jìn)行過初始化。則需要先觸發(fā)其初始化。

2. 使用反射進(jìn)行反射調(diào)用的時候，如果類沒有初始化，則需要先觸發(fā)其初始化。

3. 當(dāng)初始化一個類的時候，如果其父類沒有初始化，則需要先觸發(fā)其父類的初始化

4. 程序啟動需要觸發(fā)main方法的時候，虛擬機會先觸發(fā)這個類的初始化

5. 當(dāng)使用jdk1.7的動態(tài)語言支持的時候，如果一個java.lang.invoke.MethodHandler實例最后的解析結(jié)果為REF_getStatic、REF_pusStatic、REF_invokeStatic的方法句柄（句柄中包含了對象的實例數(shù)據(jù)和類型數(shù)據(jù)，句柄是訪問對象的一種方法。句柄存儲在堆中），并且句柄對應(yīng)的類沒有被初始化，那么需要先觸發(fā)這個類的初始化。

5種之外情況就是被動引用。被動引用的經(jīng)典例子有：

1. 通過子類引用父類的靜態(tài)字段
   這種情況不會導(dǎo)致子類的初始化，因為對于靜態(tài)字段，只有直接定義靜態(tài)字段的類才會被觸發(fā)初始化，子類不是定義這個靜態(tài)字段的類，自然不能被實例化。

2. 通過數(shù)組定義來引用類，不會觸發(fā)該類的初始化
   例如， Clazz[] arr = new Clazz[10];并不會觸發(fā)。

3. 常量不會觸發(fā)定義常量的類的初始化
   因為常量在編譯階段會存入調(diào)用常量的類的常量池中，本質(zhì)上并沒有引用定義這個常量的類，所以不會觸發(fā)定義這個常量的類的初始化。

對于這5種主動引用會觸發(fā)類進(jìn)行初始化的場景，在java虛擬機規(guī)范中限定了“有且只有”這5種場景會觸發(fā)類的加載。

類加載的過程

加載

在加載階段虛擬機需要完成以下三件事：

1. 通過一個類的全限定名稱來獲取此類的二進(jìn)制字節(jié)流

2. 將這個字節(jié)流所代表的靜態(tài)存儲結(jié)構(gòu)轉(zhuǎn)化為方法區(qū)的運行時數(shù)據(jù)結(jié)構(gòu)

3. 在內(nèi)存中生成一個代表這個類的java.lang.Class對象，作為方法區(qū)這個類的各種數(shù)據(jù)的訪問入口

這三件事在Java虛擬機中并沒有說的很詳細(xì)，比如類的全限定名稱是如何加載進(jìn)來的，以及從哪里加載進(jìn)來的。通常來講，一個類的全限定名稱可以從zip、jar包中加載，也可以從網(wǎng)絡(luò)中獲取，也可以在運行的時候生成（這點最明顯的技術(shù)體現(xiàn)就是反射機制）。

對于類的加載，可以分為數(shù)組類型和非數(shù)組類型，對于非數(shù)組類型可以通過系統(tǒng)的引導(dǎo)類加載器進(jìn)行加載，也可以通過自定義的類加載器進(jìn)行加載。這點是比較靈活的。而對于數(shù)組類型，數(shù)組類本身不通過類加載器進(jìn)行加載，而是通過Java虛擬機直接進(jìn)行加載的，那么是不是數(shù)組類型的類就不需要類加載器了呢？答案是否定的。因為當(dāng)數(shù)組去除所有維度之后的類型最終還是要依靠類加載器進(jìn)行加載的，所以數(shù)組類型的類與類加載器的關(guān)系還是很密切的。

通常一個數(shù)組類型的類進(jìn)行加載需要遵循以下的原則：

1. 如果數(shù)組的組件類型（也就是數(shù)組類去除一個維度之后的類型，比如對于二維數(shù)組，去除一個維度之后是一個一維數(shù)組）是引用類型，那么遞歸采用上面的過程加載這個組件類型

2. 如果數(shù)組類的組件類型不是引用類型，比如是基本數(shù)據(jù)類型，Java虛擬機將把數(shù)組類標(biāo)記為與引導(dǎo)類加載器關(guān)聯(lián)

3. 數(shù)組類的可見性與組件類型的可見性是一致的。如果組件類型不是引用類型，那么數(shù)組類的可見性是public，意味著組件類型的可見性也是public。

前面已經(jīng)介紹過，加載階段與連接階段是交叉進(jìn)行的，所以可能加載階段還沒有完成，連接階段就已經(jīng)開始。但是即便如此，記載階段與連接階段之間的開始順序仍然保持著固定的順序。

驗證

驗證階段的目的是為了確保Class字節(jié)流中包含的信息符合當(dāng)前虛擬機的要求，并且不會危害虛擬機的安全。

我們知道Java語言具有相對的安全性（這里的安全性體現(xiàn)為兩個方面：一是Java語言本身特性，比如Java去除指針，這點可以避免對內(nèi)存的直接操作；二是Java所提供的沙箱運行機制，Java保證所運行的機制都是在沙箱之內(nèi)運行的，而沙箱之外的操作都不可以運行）。但是需要注意的是Java虛擬機處理的Class文件并不一定是是從Java代碼編譯而來，完全可能是來自其他的語言，甚至可以直接通過十六進(jìn)制編輯器書寫Class文件（當(dāng)然前提是編寫的Class文件符合規(guī)范）。從這個角度講，其他來源的Class文件是不可能都保證其安全性的。所以如果Java虛擬機都信任其加載進(jìn)來的Class文件，那么很有可能會造成對虛擬機自身的危害。

虛擬機的驗證階段主要完后以下4項驗證：文件格式驗證、元數(shù)據(jù)驗證、字節(jié)碼驗證、符號引用驗證。（結(jié)合前文，查看Class類文件結(jié)構(gòu)）

文件格式驗證

這里的文件格式是指Class的文件規(guī)范，這一步的驗證主要保證加載的字節(jié)流（在計算機中不可能是整個Class文件，只有0和1，也就是字節(jié)流）符合Class文件的規(guī)范（根據(jù)前面對Class類文件的描述，Class文件的每一個字節(jié)表示的含義都是確定的。比如前四個字節(jié)是否是一個魔數(shù)等）以及保證這個字節(jié)流可以被虛擬機接受處理。

在Hotspot的規(guī)范中，對文件格式的驗證遠(yuǎn)不止這些，但是只有通過文件格式的驗證才能進(jìn)入方法區(qū)中進(jìn)行存儲。所以自然也就知道，后面階段的驗證工作都是在方法區(qū)中進(jìn)行的。

元數(shù)據(jù)驗證

元數(shù)據(jù)可以理解為描述數(shù)據(jù)的數(shù)據(jù)，更通俗的說，元數(shù)據(jù)是描述類之間的依賴關(guān)系的數(shù)據(jù)，比如Java語言中的注解使用（使用@interface創(chuàng)建一個注解）。元數(shù)據(jù)驗證主要目的是對類的元數(shù)據(jù)信息進(jìn)行語義校驗，保證不存在不符合Java語言規(guī)范（Java語法）的元數(shù)據(jù)信息。

具體的驗證信息包括以下幾個方面：

1. 這個類是否有父類（除了java.lang.Object外其余的類都應(yīng)該有父類）

2. 這個類的父類是否繼承了不允許被繼承的類（比如被final修飾的類）

3. 如果這個類不是抽象類，是否實現(xiàn)了其父類或者接口中要求實現(xiàn)的方法

4. 類中的字段、方法是否與父類產(chǎn)生矛盾（比如是否覆蓋了父類的final字段）

字節(jié)碼驗證

這個階段主要對類的方法體進(jìn)行校驗分析。通過了字節(jié)碼的驗證并不代表就是沒有問題的，但是如果沒有通過驗證就一定是有問題的。整個字節(jié)碼的驗證過程比這個復(fù)雜的多，由于字節(jié)碼驗證的高度復(fù)雜性，在jdk1.6版本之后的虛擬機增加了一項優(yōu)化，Class類文件結(jié)構(gòu)這篇文章中說到過有一個屬性：StackMapTable屬性?？梢院唵卫斫膺@個屬性是用于檢查類型是否匹配。

符號引用驗證

這個驗證是最后階段的驗證，符號引用是Class文件的邏輯符號，直接引用指向的方法區(qū)中某一個地址，在解析階段，將符號引用轉(zhuǎn)為直接引用，這里只進(jìn)行轉(zhuǎn)化前的匹配性校驗。符號引用驗證主要是對類自身以外的信息進(jìn)行匹配性校驗。比如符號引用是否通過字符串描述的全限定名是否能夠找到對應(yīng)點類。

• 符號引用（Symbolic Reference）
  符號引用以一組符號來描述所引用的目標(biāo)，符號引用可以是任何形式的字面量，只要使用時能無歧義的定位到目標(biāo)即可（符號字面量，還沒有涉及到內(nèi)存）。符號引用與虛擬機實現(xiàn)的內(nèi)存布局無關(guān)，引用的目標(biāo)并不一定已經(jīng)加載在內(nèi)存中。各種虛擬機實現(xiàn)的內(nèi)存布局可以各不相同，但是他們能接受的符號引用必須都是一致的，因為符號引用的字面量形式明確定義在Java虛擬機規(guī)范的Class文件格式中。

• 直接引用（Direct Reference）
  直接引用可以是直接指向目標(biāo)的指針、相對偏移量或是一個能間接定位到目標(biāo)的句柄（可以理解為內(nèi)存地址）。直接引用是與虛擬機實現(xiàn)的內(nèi)存布局相關(guān)的，同一個符號引用在不同的虛擬機實例上翻譯出來的直接引用一般都不相同，如果有了直接引用，那引用的目標(biāo)必定已經(jīng)在內(nèi)存中存在。

進(jìn)行符號引用驗證的目的在于確保解析動作能夠正常執(zhí)行，如果無法通過符號引用驗證那么將會拋出java.lang.IncomingChangeError異常的子類。

準(zhǔn)備

完成了驗證階段之后，就進(jìn)入準(zhǔn)備階段。準(zhǔn)備階段是正式為變量分配內(nèi)存空間并且設(shè)置類變量初始值。

需要注意的是，這時候進(jìn)行內(nèi)存分配的僅僅是類變量（也就是被static修飾的變量），實例變量是不包括的，實例變量的初始化是在對象實例化的時候進(jìn)行初始化，而且分配的內(nèi)存區(qū)域是Java堆。這里的初始值也就是在編程中默認(rèn)值，也就是零值。

例如public static int value = 123 ；value在準(zhǔn)備階段后的初始值是0而不是123，因為此時尚未執(zhí)行任何的Java方法，而把value賦值為123的putStatic指令是程序被編譯后，存放在類構(gòu)造器clinit()方法之中，把value賦值為123的動作將在初始化階段才會執(zhí)行。

特殊情況：如果類字段的字段屬性表中存在ConstantValue屬性，那在準(zhǔn)備階段變量就會被初始化為ConstantValue屬性所指定的值，例如public static final int value = 123 編譯時javac將會為value生成ConstantValue屬性，在準(zhǔn)備階段虛擬機就會根據(jù)ConstantValue的設(shè)置將變量賦值為123。

解析

解析階段是將常量池中的符號引用替換為直接引用的過程（前面已經(jīng)提到了符號引用與直接引用的區(qū)別）。在進(jìn)行解析之前需要對符號引用進(jìn)行解析，不同虛擬機實現(xiàn)可以根據(jù)需要判斷到底是在類被加載器加載的時候?qū)ΤＡ砍氐姆栆眠M(jìn)行解析（也就是初始化之前），還是等到一個符號引用被使用之前進(jìn)行解析（也就是在初始化之后）。

到現(xiàn)在我們已經(jīng)明白解析階段的時機，那么還有一個問題是：如果一個符號引用進(jìn)行多次解析請求，虛擬機中除了invokedynamic指令外，虛擬機可以對第一次解析的結(jié)果進(jìn)行緩存（在運行時常量池中記錄引用，并把常量標(biāo)識為一解析狀態(tài)），這樣就避免了一個符號引用的多次解析。

解析動作主要針對的是類或者接口、字段、類方法、方法類型、方法句柄和調(diào)用點限定符7類符號引用。這里主要說明前四種的解析過程。

類或者接口解析

要把一個類或者接口的符號引用解析為直接引用，需要以下三個步驟：

1. 如果該符號引用不是一個數(shù)組類型，那么虛擬機將會把該符號代表的全限定名稱傳遞給調(diào)用這個符號引用的類。這個過程由于涉及驗證過程所以可能會觸發(fā)其他相關(guān)類的加載

2. 如果該符號引用是一個數(shù)組類型，并且該數(shù)組的元素類型是對象。我們知道符號引用是存在方法區(qū)的常量池中的，該符號引用的描述符會類似”[java/lang/Integer”的形式（描述符的概念詳見前文【深入理解JVM】：Class類文件結(jié)構(gòu)），將會按照上面的規(guī)則進(jìn)行加載，虛擬機將會生成一個代表此數(shù)組對象的直接引用

3. 如果上面的步驟都沒有出現(xiàn)異常，那么該符號引用已經(jīng)在虛擬機中產(chǎn)生了一個直接引用，但是在解析完成之前需要對符號引用進(jìn)行驗證，主要是確認(rèn)當(dāng)前調(diào)用這個符號引用的類是否具有訪問權(quán)限，如果沒有訪問權(quán)限將拋出java.lang.IllegalAccess異常

字段解析

對字段的解析需要首先對其所屬的類進(jìn)行解析，因為字段是屬于類的，只有在正確解析得到其類的正確的直接引用才能繼續(xù)對字段的解析。對字段的解析主要包括以下幾個步驟：

1. 如果該字段符號引用（后面簡稱符號）就包含了簡單名稱和字段描述符都與目標(biāo)相匹配的字段，則返回這個字段的直接引用，解析結(jié)束

2. 否則，如果在該符號的類實現(xiàn)了接口，將會按照繼承關(guān)系從下往上遞歸搜索各個接口和它的父接口，如果在接口中包含了簡單名稱和字段描述符都與目標(biāo)相匹配的字段，那么久直接返回這個字段的直接引用，解析結(jié)束

3. 否則，如果該符號所在的類不是Object類的話，將會按照繼承關(guān)系從下往上遞歸搜索其父類，如果在父類中包含了簡單名稱和字段描述符都相匹配的字段，那么直接返回這個字段的直接引用，解析結(jié)束

4. 否則，解析失敗，拋出java.lang.NoSuchFieldError異常
   如果最終返回了這個字段的直接引用，就進(jìn)行權(quán)限驗證，如果發(fā)現(xiàn)不具備對字段的訪問權(quán)限，將拋出java.lang.IllegalAccessError異常

類方法解析

進(jìn)行類方法的解析仍然需要先解析此類方法的類，在正確解析之后需要進(jìn)行如下的步驟：

1. 類方法和接口方法的符號引用是分開的，所以如果在類方法表中發(fā)現(xiàn)class_index（類中方法的符號引用）的索引是一個接口，那么會拋出java.lang.IncompatibleClassChangeError的異常

2. 如果class_index的索引確實是一個類，那么在該類中查找是否有簡單名稱和描述符都與目標(biāo)字段相匹配的方法，如果有的話就返回這個方法的直接引用，查找結(jié)束

3. 否則，在該類的父類中遞歸查找是否具有簡單名稱和描述符都與目標(biāo)字段相匹配的字段，如果有，則直接返回這個字段的直接引用，查找結(jié)束

4. 否則，在這個類的接口以及它的父接口中遞歸查找，如果找到的話就說明這個方法是一個抽象類，查找結(jié)束，返回java.lang.AbstractMethodError異常（因為抽象類是沒有實現(xiàn)的）

5. 否則，查找失敗，拋出java.lang.NoSuchMethodError異常
   如果最終返回了直接引用，還需要對該符號引用進(jìn)行權(quán)限驗證，如果沒有訪問權(quán)限，就拋出java.lang.IllegalAccessError異常

接口方法解析

同類方法解析一樣，也需要先解析出該方法的類或者接口的符號引用，如果解析成功，就進(jìn)行下面的解析工作：

1. 如果在接口方法表中發(fā)現(xiàn)class_index的索引是一個類而不是一個接口，那么也會拋出java.lang.IncompatibleClassChangeError的異常

2. 否則，在該接口方法的所屬的接口中查找是否具有簡單名稱和描述符都與目標(biāo)字段相匹配的方法，如果有的話就直接返回這個方法的直接引用。查找結(jié)束

3. 否則，在該接口以及其父接口中查找，直到Object類，如果找到則直接返回這個方法的直接引用
   否則，查找失敗

接口的所有方法都是public，所以不存在訪問權(quán)限問題

初始化

到了初始化階段，虛擬機才開始真正執(zhí)行Java程序代碼，前文講到對類變量的初始化，但那是僅僅賦初值，用戶自定義的值還沒有賦給該變量。只有到了初始化階段，才開始真正執(zhí)行這個自定義的過程，所以也可以說初始化階段是執(zhí)行類構(gòu)造器方法clinit() 的過程。那么這個clinit() 方法是這么生成的呢？

• clinit() 是編譯器自動收集類中所有類變量的賦值動作和靜態(tài)語句塊合并生成的。編譯器收集的順序是由語句在源文件中出現(xiàn)的順序決定的。靜態(tài)語句塊中只能訪問到定義在靜態(tài)語句塊之前的變量，定義在它之后的變量，在前面的靜態(tài)語句塊可以賦值，但是不能訪問。
  示例代碼：

 public class Test {
  static{
   i =0;   //給變量賦值可以正常編譯通過
   System.out.println(i); //這句編譯器會提示“非法向前引用”
  }
  static int i = 1;
}

• clinit() 方法與類的構(gòu)造器方法不同，因為前者不需要顯式調(diào)用父類構(gòu)造器，因為虛擬機會保證在子類的clinit() 方法執(zhí)行之前，父類的clinit() 方法已經(jīng)執(zhí)行完畢

• 由于父類的clinit() 方法會先執(zhí)行，所以就表示父類的static方法會先于子類的clinit() 方法執(zhí)行。如下面的例子所示，輸出結(jié)果為2而不是1。

public class Parent { 
 public static int A = 1; 
 static{ 
  A = 2; 
 } 
} 

public class Sub extends Parent{ 
 public static int B = A; 
} 

public class Test { 
 public static void main(String[] args) { 
  System.out.println(Sub.B); 
 } 
}

• clinit()方法對于類或者接口來說并不是必需的，如果一個類中沒有靜態(tài)語句塊也沒有對變量的賦值操作，那么編譯器可以不為這個類生成clinit()方法。

• 接口中不能使用靜態(tài)語句塊，但仍然有變量賦值的初始化操作，因此接口也會生成clinit()方法。但是接口與類不同，執(zhí)行接口的clinit()方法不需要先執(zhí)行父接口的clini>()方法。只有當(dāng)父接口中定義的變量被使用時，父接口才會被初始化。另外，接口的實現(xiàn)類在初始化時也不會執(zhí)行接口的clinit()方法。

• 虛擬機會保證一個類的clinit()方法在多線程環(huán)境中被正確地加鎖和同步。如果有多個線程去同時初始化一個類，那么只會有一個線程去執(zhí)行這個類的clinit()方法，其它線程都需要阻塞等待，直到活動線程執(zhí)行clinit()方法完畢。如果在一個類的clinit()方法中有耗時很長的操作，那么就可能造成多個進(jìn)程阻塞。

注意：解析和初始化在繼承關(guān)系中從下往上遞歸搜索父類的特性，可以用來解釋繼承關(guān)系中的父類和子類的初始化順序（另一個原因是Java HotSpot虛擬機的內(nèi)存布局分配策略的影響），具體的分析詳見文章【深入理解JVM】：Java類繼承關(guān)系中的初始化順序。

參考
1、周志明，深入理解Java虛擬機：JVM高級特性與最佳實踐，機械工業(yè)出版社

更多java相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《Java面向?qū)ο蟪绦蛟O(shè)計入門與進(jìn)階教程》、《Java數(shù)據(jù)結(jié)構(gòu)與算法教程》、《Java操作DOM節(jié)點技巧總結(jié)》、《Java文件與目錄操作技巧匯總》和《Java緩存操作技巧匯總》

希望本文所述對大家java程序設(shè)計有所幫助。

最新評論