**

一、什么是類的加載

**

類的加載指的是將類的.class文件中的二進制數據讀入到內存中，將其放在運行時數據區(qū)的方法區(qū)內，然后在堆區(qū)創(chuàng)建一個java.lang.Class對象，用來封裝類在方法區(qū)內的數據結構。類的加載的最終產品是位于堆區(qū)中的Class對象，Class對象封裝了類在方法區(qū)內的數據結構，并且向Java程序員提供了訪問方法區(qū)內的數據結構的接口。

加載.class文件的方式 ：

– 從本地系統(tǒng)中直接加載 – 通過網絡下載.class文件
– 從zip，jar等歸檔文件中加載.class文件
– 從專有數據庫中提取.class文件
– 將Java源文件動態(tài)編譯為.class文件

附JVM內存結構圖，詳見傳送門

**

二、類的生命周期

**

其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中，加載、驗證、準備和初始化這四個階段發(fā)生的順序是確定的，而解析階段則不一定，它在某些情況下可以在初始化階段之后開始，這是為了支持Java語言的運行時綁定（也成為動態(tài)綁定或晚期綁定）。另外注意這里的幾個階段是按順序開始，而不是按順序進行或完成，因為這些階段通常都是互相交叉地混合進行的，通常在一個階段執(zhí)行的過程中調用或激活另一個階段。

2.1 加載：
查找并加載類的二進制數據

加載時類加載過程的第一個階段，在加載階段，虛擬機需要完成以下三件事情：

通過一個類的全限定名來獲取其定義的二進制字節(jié)流

將這個字節(jié)流所代表的靜態(tài)存儲結構轉化為方法區(qū)的運行時數據結構

在Java堆中生成一個代表這個類的java.lang.Class對象，作為對方法區(qū)中這些數據的訪問入口

相對于類加載的其他階段而言，加載階段（準確地說，是加載階段獲取類的二進制字節(jié)流的動作）是可控性最強的階段，因為開發(fā)人員既可以使用系統(tǒng)提供的類加載器來完成加載，也可以自定義自己的類加載器來完成加載。

加載階段完成后，虛擬機外部的
二進制字節(jié)流就按照虛擬機所需的格式存儲在方法區(qū)之中，而且在Java堆中也創(chuàng)建一個java.lang.Class類的對象，這樣便可以通過該對象訪問方法區(qū)中的這些數據。

2.2 連接

2.2.1 驗證：
確保被加載的類的正確性

驗證是連接階段的第一步，這一階段的目的是為了確保Class文件的字節(jié)流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。驗證階段大致會完成4個階段的檢驗動作：

文件格式驗證：驗證字節(jié)流是否符合Class文件格式的規(guī)范；例如：是否以0xCAFEBABE開頭、主次版本號是否在當前虛擬機的處理范圍之內、常量池中的常量是否有不被支持的類型。

元數據驗證：對字節(jié)碼描述的信息進行語義分析（注意：對比javac編譯階段的語義分析），以保證其描述的信息符合Java語言規(guī)范的要求；例如：這個類是否有父類，除了java.lang.Object之外。

字節(jié)碼驗證：通過數據流和控制流分析，確定程序語義是合法的、符合邏輯的。

符號引用驗證：確保解析動作能正確執(zhí)行。

驗證階段是非常重要的，但不是必須的，它對程序運行期沒有影響，如果所引用的類經過反復驗證，那么可以考慮采用-Xverifynone參數來關閉大部分的類驗證措施，以縮短虛擬機類加載的時間。

2.2.2 準備：
為類的靜態(tài)變量分配內存，并將其初始化為默認值

準備階段是正式為類變量分配內存并設置類變量初始值的階段，這些內存都將在方法區(qū)中分配。對于該階段有以下幾點需要注意：

1、這時候進行內存分配的僅包括類變量（static），而不包括實例變量，實例變量會在對象實例化時隨著對象一塊分配在Java堆中。

2、這里所設置的初始值通常情況下是數據類型默認的零值（如0、0L、null、false等），而不是被在Java代碼中被顯式地賦予的值。

假設一個類變量的定義為：public static int value = 3；

那么變量value在準備階段過后的初始值為0，而不是3，因為這時候尚未開始執(zhí)行任何Java方法，而把value賦值為3的putstatic指令是在程序編譯后，存放于類構造器（）方法之中的，所以把value賦值為3的動作將在初始化階段才會執(zhí)行。

這里還需要注意如下幾點： ·

對基本數據類型來說，對于類變量（static）和全局變量，如果不顯式地對其賦值而直接使用，則系統(tǒng)會為其賦予默認的零值，而對于局部變量來說，在使用前必須顯式地為其賦值，否則編譯時不通過。
·
對于同時被static和final修飾的常量，必須在聲明的時候就為其顯式地賦值，否則編譯時不通過；而只被final修飾的常量則既可以在聲明時顯式地為其賦值，也可以在類初始化時顯式地為其賦值，總之，在使用前必須為其顯式地賦值，系統(tǒng)不會為其賦予默認零值。
·
對于引用數據類型reference來說，如數組引用、對象引用等，如果沒有對其進行顯式地賦值而直接使用，系統(tǒng)都會為其賦予默認的零值，即null。
· 如果在數組初始化時沒有對數組中的各元素賦值，那么其中的元素將根據對應的數據類型而被賦予默認的零值。

3、如果類字段的字段屬性表中存在ConstantValue屬性，即同時被final和static修飾，那么在準備階段變量value就會被初始化為ConstValue屬性所指定的值。

假設上面的類變量value被定義為： public static final int value = 3；

編譯時Javac將會為value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設置將value賦值為3。回憶上一篇博文中對象被動引用的第2個例子，便是這種情況。我們可以理解為static
final常量在編譯期就將其結果放入了調用它的類的常量池中

2.2.3 解析：
把類中的符號引用轉換為直接引用

解析階段是虛擬機將常量池內的符號引用替換為直接引用的過程，解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。符號引用就是一組符號來描述目標，可以是任何字面量。

直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄。

2.3 初始化

初始化，為類的靜態(tài)變量賦予正確的初始值，JVM負責對類進行初始化，主要對類變量進行初始化。在Java中對類變量進行初始值設定有兩種方式：

①聲明類變量是指定初始值

②使用靜態(tài)代碼塊為類變量指定初始值

JVM初始化步驟：

假如這個類還沒有被加載和連接，則程序先加載并連接該類

假如該類的直接父類還沒有被初始化，則先初始化其直接父類

假如類中有初始化語句，則系統(tǒng)依次執(zhí)行這些初始化語句

類初始化時機：只有當對類的主動使用的時候才會導致類的初始化，類的主動使用包括以下六種：

• 創(chuàng)建類的實例，也就是new的方式
• 訪問某個類或接口的靜態(tài)變量，或者對該靜態(tài)變量賦值
• 調用類的靜態(tài)方法
• 反射（如Class.forName(“com.shengsiyuan.Test”)）
• 初始化某個類的子類，則其父類也會被初始化
• Java虛擬機啟動時被標明為啟動類的類（Java Test），直接使用java.exe命令來運行某個主類

結束生命周期

在如下幾種情況下，Java虛擬機將結束生命周期

• 執(zhí)行了System.exit()方法
• 程序正常執(zhí)行結束
• 程序在執(zhí)行過程中遇到了異常或錯誤而異常終止
• 由于操作系統(tǒng)出現錯誤而導致Java虛擬機進程終止

**

三、類加載器

**

查看類加載器：

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開發(fā)人員的角度來看，類加載器可以大致劃分為以下三類：

啟動類加載器：Bootstrap ClassLoader，由C++實現，不是ClassLoader子類，負責加載存放在JDK\jre\lib(JDK代表JDK的安裝目錄，下同)下，或被-Xbootclasspath參數指定的路徑中的，并且能被虛擬機識別的類庫（如rt.jar，所有的java.*開頭的類均被Bootstrap ClassLoader加載）。啟動類加載器是無法被Java程序直接引用的。

擴展類加載器：Extension ClassLoader，該加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載DK\jre\lib\ext目錄中，或者由java.ext.dirs系統(tǒng)變量指定的路徑中的所有類庫（如javax.*開頭的類），開發(fā)者可以直接使用擴展類加載器。

應用程序類加載器：Application ClassLoader，該類加載器由sun.misc.Launcher$AppClassLoader來實現，它負責加載用戶類路徑（ClassPath）所指定的類，開發(fā)者可以直接使用該類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

應用程序都是由這三種類加載器互相配合進行加載的，如果有必要，我們還可以加入自定義的類加載器。因為JVM自帶的ClassLoader只是懂得從本地文件系統(tǒng)加載標準的java class文件，因此如果編寫了自己的ClassLoader，便可以做到如下幾點：

1）在執(zhí)行非置信代碼之前，自動驗證數字簽名。

2）動態(tài)地創(chuàng)建符合用戶特定需要的定制化構建類。

3）從特定的場所取得java class，例如數據庫中和網絡中。

JVM類加載機制

• 全盤負責，當一個類加載器負責加載某個Class時，該Class所依賴的和引用的其他Class也將由該類加載器負責載入，除非顯示使用另外一個類加載器來載入
• 父類委托，先讓父類加載器試圖加載該類，只有在父類加載器無法加載該類時才嘗試從自己的類路徑中加載該類
• 緩存機制，緩存機制將會保證所有加載過的Class都會被緩存，當程序中需要使用某個Class時，類加載器先從緩存區(qū)尋找該Class，只有緩存區(qū)不存在，系統(tǒng)才會讀取該類對應的二進制數據，并將其轉換成Class對象，存入緩存區(qū)。這就是為什么修改了Class后，必須重啟JVM，程序的修改才會生效

Tomcat類加載機制

Tomcat 使用正統(tǒng)的類加載機制(雙親委派),但部分地方做了改動。

Bootstrap classLoader 和 Extension classLoader 的作用不變。

System classLoader 正常情況下加載的是 CLASSPATH 下的類，但是 Tomcat 的啟動腳本并未使用該變量，而是從以下倉庫下加載類：
2.1 $CATALINA_HOME/bin/bootstrap.jar 包含了 Tomcat 的啟動類。在該啟動類中創(chuàng)建了 Common classLoader、Catalina classLoader、shared classLoader。因為 $CATALINA_BASE/conf/catalina.properties 中只對 common.loader 屬性做了定義，server.loader 和 shared.loader 屬性為空，所以默認情況下，這三個 classLoader 都是 CommonLoader。具體的代碼邏輯可以查閱 org.apache.catalina.startup.Bootstrap 類的 initClassLoaders() 方法和 createClassLoader() 方法。
2.2 $CATALINA_BASE/bin/tomcat-juli.jar 包含了 Tomcat 日志模塊所需要的實現類。
2.3 $CATALINA_HOME/bin/commons-daemon.jar。

Common classLoader 是位于 Tomcat 應用服務器頂層的公用類加載器。由其加載的類可以由 Tomcat 自身類和所有應用程序使用。掃描路徑由 $CATALINA_BASE/conf/catalina.properties 文件中的 common.loader 屬性定義。默認是 $CATALINA_HOME/lib。

catalina classLoader 用于加載服務器內部可見類，這些類應用程序不能訪問。

shared classLoader 用于加載應用程序共享類，這些類服務器不會依賴。

Webapp classLoader 。每個應用程序都會有一個獨一無二的 webapp classloader，他用來加載本應用程序 /WEB-INF/classes 和 /WEB-INF/lib 下的類。

特別的：

Webapp classLoader 的默認行為會與正常的雙親委派模式不同：

從 Bootstrap classloader 加載。

若沒有，從 /WEB-INF/classes 加載。

若沒有，從 /WEB-INF/lib/*.jar 加載。

若沒有，則依次從 System、Common、shared 加載（該步驟使用雙親委派）。

當然了，我們也可以通過配置來使 Webapp classLoader 嚴格按照雙親委派模式加載類：

通過在工程的 META-INF/context.xml（和 WEB-INF/classes 在同一目錄下） 配置文件中添加

因為 Webapp classLoader 的實現類是 org.apache.catalina.loader.WebappLoader，他有一個屬性叫 delegate， 用來控制類加載器的加載行為，默認為 false，我們可以使用 set 方法，將其設為 true 來啟用嚴格雙親委派加載模式。

嚴格雙親委派模式加載步驟：

從 Bootstrap classloader 加載。

若沒有，則依次從 System、Common、shared 加載。

若沒有，從 /WEB-INF/classes 加載。

若沒有，從 /WEB-INF/lib/*.jar 加載。

**

四、類的加載

**

類加載有三種方式：

1、命令行啟動應用時候由JVM初始化加載

2、通過Class.forName()方法動態(tài)加載

3、通過ClassLoader.loadClass()方法動態(tài)加載

例子：

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()來加載類，不會執(zhí)行初始化塊 loader.loadClass("Test2"); //使用Class.forName()來加載類，默認會執(zhí)行初始化塊 // Class.forName("Test2"); //使用Class.forName()來加載類，并指定ClassLoader，初始化時不執(zhí)行靜態(tài)塊 // Class.forName("Test2", false, loader); } }public class Test2 { static { System.out.println("靜態(tài)初始化塊執(zhí)行了！"); } }

分別切換加載方式，會有不同的輸出結果。

Class.forName()和ClassLoader.loadClass()區(qū)別

Class.forName()：將類的.class文件加載到jvm中之外，還會對類進行解釋，執(zhí)行類中的static塊；

ClassLoader.loadClass()：只干一件事情，就是將.class文件加載到jvm中，不會執(zhí)行static中的內容,只有在newInstance才會去執(zhí)行static塊。

注：

Class.forName(name, initialize, loader)帶參函數也可控制是否加載static塊。并且只有調用了newInstance()方法采用調用構造函數，創(chuàng)建類的對象 。

**

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;}

雙親委派模型意義：

-系統(tǒng)類防止內存中出現多份同樣的字節(jié)碼

-保證Java程序安全穩(wěn)定運行

**

六、自定義類加載器

**

通常情況下，我們都是直接使用系統(tǒng)類加載器。但是，有的時候，我們也需要自定義類加載器。比如應用是通過網絡來傳輸 Java 類的字節(jié)碼，為保證安全性，這些字節(jié)碼經過了加密處理，這時系統(tǒng)類加載器就無法對其進行加載，這樣則需要自定義類加載器來實現。自定義類加載器一般都是繼承自 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();}} }

自定義類加載器的核心在于對字節(jié)碼文件的獲取，如果是加密的字節(jié)碼則需要在該類中對文件進行解密。由于這里只是演示，我并未對class文件進行加密，因此沒有解密的過程。這里有幾點需要注意：

1、這里傳遞的文件名需要是類的全限定性名稱，即com.paddx.test.classloading.Test格式的，因為 defineClass 方法是按這種格式進行處理的。

2、最好不要重寫loadClass方法，因為這樣容易破壞雙親委托模式。

3、這類Test 類本身可以被 AppClassLoader 類加載，因此我們不能把 com/paddx/test/classloading/Test.class 放在類路徑下。否則，由于雙親委托機制的存在，會直接導致該類由 AppClassLoader 加載，而不會通過我們自定義類加載器來加載。

總結

以上是生活随笔為你收集整理的Java——类加载机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。