JVM-01:類加載機制
1、什麽是類的加載
類的加載指的是將類的.class文件中的二進制數據讀入到內存中,將其放在運行時數據區的方法區內,然後在堆區創建一個java.lang.Class
對象,用來封裝類在方法區內的數據結構。類的加載的最終產品是位於堆區中的Class
對象,Class
對象封裝了類在方法區內的數據結構,並且向Java程序員提供了訪問方法區內的數據結構的接口。
類加載器並不需要等到某個類被“首次主動使用”時再加載它,JVM規範允許類加載器在預料某個類將要被使用時就預先加載它,如果在預先加載的過程中遇到了.class文件缺失或存在錯誤,類加載器必須在程序首次主動使用該類時才報告錯誤(LinkageError錯誤)如果這個類一直沒有被程序主動使用,那麽類加載器就不會報告錯誤
加載.class文件的方式
- 從本地系統中直接加載
- 通過網絡下載.class文件
- 從zip,jar等歸檔文件中加載.class文件
- 從專有數據庫中提取.class文件
- 將Java源文件動態編譯為.class文件
2、類的生命周期
其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中,加載、驗證、準備和初始化這四個階段發生的順序是確定的,而解析階段則不一定,它在某些情況下可以在初始化階段之後開始,這是為了支持Java語言的運行時綁定(也成為動態綁定或晚期綁定)。另外註意這裏的幾個階段是按順序開始,而不是按順序進行或完成,因為這些階段通常都是互相交叉地混合進行的,通常在一個階段執行的過程中調用或激活另一個階段。
加載
查找並加載類的二進制數據加載時類加載過程的第一個階段,在加載階段,虛擬機需要完成以下三件事情:
- 通過一個類的全限定名來獲取其定義的二進制字節流。
- 將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。
- 在Java堆中生成一個代表這個類的
java.lang.Class
對象,作為對方法區中這些數據的訪問入口。
相對於類加載的其他階段而言,加載階段(準確地說,是加載階段獲取類的二進制字節流的動作)是可控性最強的階段,因為開發人員既可以使用系統提供的類加載器來完成加載,也可以自定義自己的類加載器來完成加載。
加載階段完成後,虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區之中,而且在Java堆中也創建一個java.lang.Class
連接
驗證:確保被加載的類的正確性
驗證是連接階段的第一步,這一階段的目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求,並且不會危害虛擬機自身的安全。驗證階段大致會完成4個階段的檢驗動作:
- 文件格式驗證:驗證字節流是否符合Class文件格式的規範;例如:是否以
0xCAFEBABE
開頭、主次版本號是否在當前虛擬機的處理範圍之內、常量池中的常量是否有不被支持的類型。 - 元數據驗證:對字節碼描述的信息進行語義分析(註意:對比javac編譯階段的語義分析),以保證其描述的信息符合Java語言規範的要求;例如:這個類是否有父類,除了
java.lang.Object
之外。 - 字節碼驗證:通過數據流和控制流分析,確定程序語義是合法的、符合邏輯的。
- 符號引用驗證:確保解析動作能正確執行。
驗證階段是非常重要的,但不是必須的,它對程序運行期沒有影響,如果所引用的類經過反復驗證,那麽可以考慮采用-Xverifynone
參數來關閉大部分的類驗證措施,以縮短虛擬機類加載的時間。
準備:為類的靜態變量分
配內存,並將其初始化為默認值
準備階段是正式為類變量分配內存並設置類變量初始值的階段,這些內存都將在方法區中分配。對於該階段有以下幾點需要註意:
- 1、這時候進行內存分配的僅包括類變量(static),而不包括實例變量,實例變量會在對象實例化時隨著對象一塊分配在Java堆中。
- 2、這裏所設置的初始值通常情況下是數據類型默認的零值(如0、0L、null、false等),而不是被在Java代碼中被顯式地賦予的值。
假設一個類變量的定義為:public static int value = 3
;
那麽變量value在準備階段過後的初始值為0,而不是3,因為這時候尚未開始執行任何Java方法,而把value賦值為3的public static
指令是在程序編譯後,存放於類構造器<clinit>()
方法之中的,所以把value賦值為3的動作將在初始化階段才會執行。
這裏還需要註意如下幾點:
- 對基本數據類型來說,對於類變量(static)和全局變量,如果不顯式地對其賦值而直接使用,則系統會為其賦予默認的零值,而對於局部變量來說,在使用前必須顯式地為其賦值,否則編譯時不通過。
- 對於同時被static和final修飾的常量,必須在聲明的時候就為其顯式地賦值,否則編譯時不通過;而只被final修飾的常量則既可以在聲明時顯式地為其賦值,也可以在類初始化時顯式地為其賦值,總之,在使用前必須為其顯式地賦值,系統不會為其賦予默認零值。
- 對於引用數據類型reference來說,如數組引用、對象引用等,如果沒有對其進行顯式地賦值而直接使用,系統都會為其賦予默認的零值,即null。
- 如果在數組初始化時沒有對數組中的各元素賦值,那麽其中的元素將根據對應的數據類型而被賦予默認的零值。
- 3、如果類字段的字段屬性表中存在
ConstantValue
屬性,即同時被final和static修飾,那麽在準備階段變量value就會被初始化為ConstValue屬性所指定的值。
假設上面的類變量value被定義為: public static final int value = 3
;
編譯時Javac將會為value生成ConstantValue屬性,在準備階段虛擬機就會根據ConstantValue
的設置將value賦值為3。我們可以理解為static final常量在編譯期就將其結果放入了調用它的類的常量池中
解析:把類中的符號引用轉換為直接引用
解析階段是虛擬機將常量池內的符號引用替換為直接引用的過程,解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。符號引用就是一組符號來描述目標,可以是任何字面量。
直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄。
初始化
初始化,為類的靜態變量賦予正確的初始值,JVM負責對類進行初始化,主要對類變量進行初始化。在Java中對類變量進行初始值設定有兩種方式:
- ①聲明類變量是指定初始值
- ②使用靜態代碼塊為類變量指定初始值
JVM初始化步驟
- 1、假如這個類還沒有被加載和連接,則程序先加載並連接該類
- 2、假如該類的直接父類還沒有被初始化,則先初始化其直接父類
- 3、假如類中有初始化語句,則系統依次執行這些初始化語句
類初始化時機:只有當對類的主動使用的時候才會導致類的初始化,類的主動使用包括以下六種:
- 創建類的實例,也就是new的方式
- 訪問某個類或接口的靜態變量,或者對該靜態變量賦值
- 調用類的靜態方法
- 反射(如
Class.forName(“com.shengsiyuan.Test”)
) - 初始化某個類的子類,則其父類也會被初始化
- Java虛擬機啟動時被標明為啟動類的類(
Java Test
),直接使用java.exe
命令來運行某個主類
結束生命周期
在如下幾種情況下,Java虛擬機將結束生命周期
- 執行了
System.exit()
方法 - 程序正常執行結束
- 程序在執行過程中遇到了異常或錯誤而異常終止
- 由於操作系統出現錯誤而導致Java虛擬機進程終止
3、類加載器
尋找類加載器,先來一個小例子
package com.neo.classloader;
public class ClassLoaderTest {
public static void main(String[] args) {
ClassLoader loader = Thread.currentThread().getContextClassLoader();
System.out.println(loader);
System.out.println(loader.getParent());
System.out.println(loader.getParent().getParent());
}
}
運行後,輸出結果:
sun.misc.Launcher$AppClassLoader@64fef26a
sun.misc.Launcher$ExtClassLoader@1ddd40f3
null
從上面的結果可以看出,並沒有獲取到ExtClassLoader
的父Loader,原因是Bootstrap Loader
(引導類加載器)是用C語言實現的,找不到一個確定的返回父Loader的方式,於是就返回null。
這幾種類加載器的層次關系如下圖所示:
註意:這裏父類加載器並不是通過繼承關系來實現的,而是采用組合實現的。
站在Java虛擬機的角度來講,只存在兩種不同的類加載器:啟動類加載器:它使用C++實現(這裏僅限於Hotspot,也就是JDK1.5之後默認的虛擬機,有很多其他的虛擬機是用Java語言實現的),是虛擬機自身的一部分;所有其它的類加載器:這些類加載器都由Java語言實現,獨立於虛擬機之外,並且全部繼承自抽象類java.lang.ClassLoader
,這些類加載器需要由啟動類加載器加載到內存中之後才能去加載其他的類。
站在Java開發人員的角度來看,類加載器可以大致劃分為以下三類:
啟動類加載器:Bootstrap ClassLoader
,負責加載存放在JDK\jre\lib
(JDK代表JDK的安裝目錄,下同)下,或被-Xbootclasspath
參數指定的路徑中的,並且能被虛擬機識別的類庫(如rt.jar,所有的java.開頭的類均被Bootstrap ClassLoader
加載)。啟動類加載器是無法被Java程序直接引用的。
擴展類加載器:Extension ClassLoader
,該加載器由sun.misc.Launcher$ExtClassLoader
實現,它負責加載JDK\jre\lib\ext
目錄中,或者由java.ext.dirs
系統變量指定的路徑中的所有類庫(如javax.開頭的類),開發者可以直接使用擴展類加載器。
應用程序類加載器:Application ClassLoader
,該類加載器由sun.misc.Launcher$AppClassLoader
來實現,它負責加載用戶類路徑(ClassPath)所指定的類,開發者可以直接使用該類加載器,如果應用程序中沒有自定義過自己的類加載器,一般情況下這個就是程序中默認的類加載器。
應用程序都是由這三種類加載器互相配合進行加載的,如果有必要,我們還可以加入自定義的類加載器。因為JVM自帶的ClassLoader只是懂得從本地文件系統加載標準的java class文件,因此如果編寫了自己的ClassLoader,便可以做到如下幾點:
- 1、在執行非置信代碼之前,自動驗證數字簽名。
- 2、動態地創建符合用戶特定需要的定制化構建類。
- 3、從特定的場所取得java class,例如數據庫中和網絡中。
JVM類加載機制
- 全盤負責,當一個類加載器負責加載某個Class時,該Class所依賴的和引用的其他Class也將由該類加載器負責載入,除非顯示使用另外一個類加載器來載入
- 父類委托,先讓父類加載器試圖加載該類,只有在父類加載器無法加載該類時才嘗試從自己的類路徑中加載該類
- 緩存機制,緩存機制將會保證所有加載過的Class都會被緩存,當程序中需要使用某個Class時,類加載器先從緩存區尋找該Class,只有緩存區不存在,系統才會讀取該類對應的二進制數據,並將其轉換成Class對象,存入緩存區。這就是為什麽修改了Class後,必須重啟JVM,程序的修改才會生效
4、類的加載
類加載有三種方式:
- 1、命令行啟動應用時候由JVM初始化加載
- 2、通過Class.forName()方法動態加載
- 3、通過ClassLoader.loadClass()方法動態加載
例子:
package com.neo.classloader;
public class loaderTest {
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader loader = HelloWorld.class.getClassLoader();
System.out.println(loader);
//使用ClassLoader.loadClass()來加載類,不會執行初始化塊
loader.loadClass("Test2");
//使用Class.forName()來加載類,默認會執行初始化塊
//Class.forName("Test2");
//使用Class.forName()來加載類,並指定ClassLoader,初始化時不執行靜態塊
//Class.forName("Test2", false, loader);
}
}
demo類
public class Test2 {
static {
System.out.println("靜態初始化塊執行了!");
}
}
分別切換加載方式,會有不同的輸出結果。
Class.forName()和ClassLoader.loadClass()區別
Class.forName()
:將類的.class文件加載到jvm中之外,還會對類進行解釋,執行類中的static塊;ClassLoader.loadClass()
:只幹一件事情,就是將.class文件加載到jvm中,不會執行static中的內容,只有在newInstance才會去執行static塊。Class.forName(name, initialize, loader)
帶參函數也可控制是否加載static塊。並且只有調用了newInstance()方法采用調用構造函數,創建類的對象 。
5、雙親委派模型
雙親委派模型的工作流程是:如果一個類加載器收到了類加載的請求,它首先不會自己去嘗試加載這個類,而是把請求委托給父加載器去完成,依次向上,因此,所有的類加載請求最終都應該被傳遞到頂層的啟動類加載器中,只有當父加載器在它的搜索範圍中沒有找到所需的類時,即無法完成該加載,子加載器才會嘗試自己去加載該類。
雙親委派機制:
- 1、當
AppClassLoader
加載一個class時,它首先不會自己去嘗試加載這個類,而是把類加載請求委派給父類加載器ExtClassLoader
去完成。 - 2、當
ExtClassLoader
加載一個class時,它首先也不會自己去嘗試加載這個類,而是把類加載請求委派給BootStrapClassLoader```去完成。 - 3、如果
BootStrapClassLoader
加載失敗(例如在$JAVA_HOME/jre/lib
裏未查找到該class),會使用ExtClassLoader
來嘗試加載; - 4、若ExtClassLoader也加載失敗,則會使用
AppClassLoader
來加載,如果AppClassLoader
也加載失敗,則會報出異常ClassNotFoundException
。
ClassLoader源碼分析:
public Class<?> loadClass(String name)throws ClassNotFoundException {
return loadClass(name, false);
}
protected synchronized Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException {
// 首先判斷該類型是否已經被加載
Class c = findLoadedClass(name);
if (c == null) {
//如果沒有被加載,就委托給父類加載或者委派給啟動類加載器加載
try {
if (parent != null) {
//如果存在父類加載器,就委派給父類加載器加載
c = parent.loadClass(name, false);
} else {
//如果不存在父類加載器,就檢查是否是由啟動類加載器加載的類,通過調用本地方法native Class findBootstrapClass(String name)
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// 如果父類加載器和啟動類加載器都不能完成加載任務,才調用自身的加載功能
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
雙親委派模型意義:
- 系統類防止內存中出現多份同樣的字節碼
- 保證Java程序安全穩定運行
6、自定義類加載器
通常情況下,我們都是直接使用系統類加載器。但是,有的時候,我們也需要自定義類加載器。比如應用是通過網絡來傳輸 Java類的字節碼,為保證安全性,這些字節碼經過了加密處理,這時系統類加載器就無法對其進行加載,這樣則需要自定義類加載器來實現。自定義類加載器一般都是繼承自ClassLoader
類,從上面對loadClass
方法來分析來看,我們只需要重寫 findClass 方法即可。下面我們通過一個示例來演示自定義類加載器的流程:
package com.neo.classloader;
import java.io.*;
public class MyClassLoader extends ClassLoader {
private String root;
protected Class<?> findClass(String name) throws ClassNotFoundException {
byte[] classData = loadClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] loadClassData(String className) {
String fileName = root + File.separatorChar
+ className.replace(‘.‘, File.separatorChar) + ".class";
try {
InputStream ins = new FileInputStream(fileName);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 1024;
byte[] buffer = new byte[bufferSize];
int length = 0;
while ((length = ins.read(buffer)) != -1) {
baos.write(buffer, 0, length);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
public String getRoot() {
return root;
}
public void setRoot(String root) {
this.root = root;
}
public static void main(String[] args) {
MyClassLoader classLoader = new MyClassLoader();
classLoader.setRoot("E:\\temp");
Class<?> testClass = null;
try {
testClass = classLoader.loadClass("com.neo.classloader.Test2");
Object object = testClass.newInstance();
System.out.println(object.getClass().getClassLoader());
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}
自定義類加載器的核心在於對字節碼文件的獲取,如果是加密的字節碼則需要在該類中對文件進行解密。由於這裏只是演示,我並未對class文件進行加密,因此沒有解密的過程。這裏有幾點需要註意:
- 1、這裏傳遞的文件名需要是類的全限定性名稱,即
com.paddx.test.classloading.Test
格式的,因為 defineClass 方法是按這種格式進行處理的。 - 2、最好不要重寫loadClass方法,因為這樣容易破壞雙親委托模式。
- 3、這類Test 類本身可以被
AppClassLoader
類加載,因此我們不能把com/paddx/test/classloading/Test.class
放在類路徑下。否則,由於雙親委托機制的存在,會直接導致該類由AppClassLoader
加載,而不會通過我們自定義類加載器來加載。
JVM-01:類加載機制