如下圖所示,JVM類加載機制分為五個部分:加載,驗證,準備,解析,初始化,下面我們就分別來看一下這五個過程。
![JVM之類加載機制和雙親委派機制](http://p2.ttnews.xyz/loading.gif)
加載
加載是類加載過程中的一個階段,這個階段會在內存中生成一個代表這個類的java.lang.Class對象,作為方法區這個類的各種數據的入口。注意這裡不一定非得要從一個Class文件獲取,這裡既可以從ZIP包中讀取(比如從jar包和war包中讀取),也可以在運行時計算生成(動態代理),也可以由其它文件生成(比如將JSP文件轉換成對應的Class類)。
驗證
這一階段的主要目的是為了確保Class文件的字節流中包含的信息是否符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。
準備
準備階段是正式為類變量分配內存並設置類變量的初始值階段,即在方法區中分配這些變量所使用的內存空間。注意這裡所說的初始值概念,比如一個類變量定義為:
1
public static int v = 8080;
實際上變量v在準備階段過後的初始值為0而不是8080,將v賦值為8080的putstatic指令是程序被編譯後,存放於類構造器
1
public static final int v = 8080;
在編譯階段會為v生成ConstantValue屬性,在準備階段虛擬機會根據ConstantValue屬性將v賦值為8080。
解析
解析階段是指虛擬機將常量池中的符號引用替換為直接引用的過程。符號引用就是class文件中的:
- CONSTANT_Class_info
- CONSTANT_Field_info
- CONSTANT_Method_info
等類型的常量。
下面我們解釋一下符號引用和直接引用的概念:
- 符號引用與虛擬機實現的佈局無關,引用的目標並不一定要已經加載到內存中。各種虛擬機實現的內存佈局可以各不相同,但是它們能接受的符號引用必須是一致的,因為符號引用的字面量形式明確定義在Java虛擬機規範的Class文件格式中。
- 直接引用可以是指向目標的指針,相對偏移量或是一個能間接定位到目標的句柄。如果有了直接引用,那引用的目標必定已經在內存中存在。
初始化
初始化階段是類加載最後一個階段,前面的類加載階段之後,除了在加載階段可以自定義類加載器以外,其它操作都由JVM主導。到了初始階段,才開始真正執行類中定義的Java程序代碼。
初始化階段是執行類構造器
注意以下幾種情況不會執行類初始化:
- 通過子類引用父類的靜態字段,只會觸發父類的初始化,而不會觸發子類的初始化。
- 定義對象數組,不會觸發該類的初始化。
- 常量在編譯期間會存入調用類的常量池中,本質上並沒有直接引用定義常量的類,不會觸發定義常量所在的類。
- 通過類名獲取Class對象,不會觸發類的初始化。
- 通過Class.forName加載指定類時,如果指定參數initialize為false時,也不會觸發類初始化,其實這個參數是告訴虛擬機,是否要對類進行初始化。
- 通過ClassLoader默認的loadClass方法,也不會觸發初始化動作。
類加載器
虛擬機設計團隊把加載動作放到JVM外部實現,以便讓應用程序決定如何獲取所需的類,JVM提供了3種類加載器:
- 啟動類加載器(Bootstrap ClassLoader):負責加載 JAVA_HOME\lib 目錄中的,或通過-Xbootclasspath參數指定路徑中的,且被虛擬機認可(按文件名識別,如rt.jar)的類。
- 擴展類加載器(Extension ClassLoader):負責加載 JAVA_HOME\lib\ext 目錄中的,或通過java.ext.dirs系統變量指定路徑中的類庫。
- 應用程序類加載器(Application ClassLoader):負責加載用戶路徑(classpath)上的類庫。
JVM通過雙親委派模型進行類的加載,當然我們也可以通過繼承java.lang.ClassLoader實現自定義的類加載器。
![JVM之類加載機制和雙親委派機制](http://p2.ttnews.xyz/loading.gif)
雙親委派機制 主要體現在ClassLoader#loadClass 如下代碼中:
protected Class> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
// First, check if the class has already been loaded
Class> c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
return c;
}
上面代碼邏輯簡單易懂, 主要是以下4個步驟:
- findLoadedClass(name) 從已加載的類的緩存中查找。
- parent.loadClass(name, false) 如果父加載器不為空,則委託父加載器加載`。
- findBootstrapClassOrNull(name) 委託 bootstrap 加載器加載。
- findClass(name) 最後調用 findClass(name) 加載。
這個雙親體現在上面的步驟 2) 和 3) 也就是下面的幾行代碼:
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
第一個親就體現在 parent 即父加載器。
第二個新就體現在 bootstrap 加載器。因為 bootstrap 加載器是 JVM 中的根加載器。
為什麼需要雙親委託機制
簡單來說,這是為了保證 JDK 核心類庫都是由 bootstrap 加載器加載。
那為什麼需要保證 JDK 核心類庫由 bootstrap 加載器加載呢?其實這主要是為了保證 JDK 核心類庫都是由同一個加載器加載?那為什麼要保證 JDK 核心類庫都需要由同一個加載器加載呢?這是為了保證核心類庫的類在 JVM 中只有一個對應實體。也就是為了保證類型關係的正確性。
鏈接:http://www.importnew.com/25295.html
閱讀更多 JAVA熊 的文章