Java基础——类加载机制及原理
一、什么是類的加載？
? ? ? ?類的加載指的是將類的.class文件中的二進制數據讀入到內存中，將其放在運行時數據區的方法區內，然后在堆區創建一個java.lang.Class對象，用來封裝類在方法區內的數據結構。類的加載的最終產品是位于堆區中的Class對象，Class對象封裝了類在方法區內的數據結構，并且向Java程序員提供了訪問方法區內的數據結構的接口。
? ? ? ?類加載器并不需要等到某個類被“首次主動使用”時再加載它，JVM規范允許類加載器在預料某個類將要被使用時就預先加載它，如果在預先加載的過程中遇到了.class文件缺失或存在錯誤，類加載器必須在程序首次主動使用該類時才報告錯誤（LinkageError錯誤）如果這個類一直沒有被程序主動使用，那么類加載器就不會報告錯誤。
加載.class文件的方式 – 從本地系統中直接加載 – 通過網絡下載.class文件 – 從zip，jar等歸檔文件中加載.class文件 – 從專有數據庫中提取.class文件 – 將Java源文件動態編譯為.class文件
二、類的生命周期
? ? ? ?其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中，加載、驗證、準備和初始化這四個階段發生的順序是確定的，而解析階段則不一定，它在某些情況下可以在初始化階段之后開始，這是為了支持Java語言的運行時綁定（也成為動態綁定或晚期綁定）。另外注意這里的幾個階段是按順序開始，而不是按順序進行或完成，因為這些階段通常都是互相交叉地混合進行的，通常在一個階段執行的過程中調用或激活另一個階段。
1、加載：查找并加載類的二進制數據
加載時類加載過程的第一個階段，在加載階段，虛擬機需要完成以下三件事情：
? ? ? ?1）通過一個類的全限定名來獲取其定義的二進制字節流。
? ? ? ?2）將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。
? ? ? ?3）在Java堆中生成一個代表這個類的java.lang.Class對象，作為對方法區中這些數據的訪問入口。
? ? ? ?相對于類加載的其他階段而言，加載階段（準確地說，是加載階段獲取類的二進制字節流的動作）是可控性最強的階段，因為開發人員既可以使用系統提供的類加載器來完成加載，也可以自定義自己的類加載器來完成加載。
? ? ? ?加載階段完成后，虛擬機外部的 二進制字節流就按照虛擬機所需的格式存儲在方法區之中，而且在Java堆中也創建一個java.lang.Class類的對象，這樣便可以通過該對象訪問方法區中的這些數據。
2、驗證：確保被加載的類的正確性
? ? ? ?驗證是連接階段的第一步，這一階段的目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，并且不會危害虛擬機自身的安全。驗證階段大致會完成4個階段的檢驗動作：
? ? ? ?文件格式驗證：驗證字節流是否符合Class文件格式的規范；例如：是否以0xCAFEBABE開頭、主次版本號是否在當前虛擬機的處理范圍之內、常量池中的常量是否有不被支持的類型。
? ? ? ?元數據驗證：對字節碼描述的信息進行語義分析（注意：對比javac編譯階段的語義分析），以保證其描述的信息符合Java語言規范的要求；例如：這個類是否有父類，除了java.lang.Object之外。
? ? ? ?字節碼驗證：通過數據流和控制流分析，確定程序語義是合法的、符合邏輯的。
? ? ? ?符號引用驗證：確保解析動作能正確執行。
? ? ? ?驗證階段是非常重要的，但不是必須的，它對程序運行期沒有影響，如果所引用的類經過反復驗證，那么可以考慮采用-Xverifynone參數來關閉大部分的類驗證措施，以縮短虛擬機類加載的時間。
3、準備：為類的靜態變量分配內存，并將其初始化為默認值
? ? ? ?準備階段是正式為類變量分配內存并設置類變量初始值的階段，這些內存都將在方法區中分配。對于該階段有以下幾點需要注意：
? ? ? ?1）這時候進行內存分配的僅包括類變量（static），而不包括實例變量，實例變量會在對象實例化時隨著對象一塊分配在Java堆中。
? ? ? ?2）這里所設置的初始值通常情況下是數據類型默認的零值（如0、0L、null、false等），而不是被在Java代碼中被顯式地賦予的值。
? ? ? ?假設一個類變量的定義為：public static int value = 3；
? ? ? ?那么變量value在準備階段過后的初始值為0，而不是3，因為這時候尚未開始執行任何Java方法，而把value賦值為3的putstatic指令是在程序編譯后，存放于類構造器<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。回憶上一篇博文中對象被動引用的第2個例子，便是這種情況。我們可以理解為static final常量在編譯期就將其結果放入了調用它的類的常量池中。
4、解析：把類中的符號引用轉換為直接引用
? ? ? ?解析階段是虛擬機將常量池內的符號引用替換為直接引用的過程，解析動作主要針對類或接口、字段、類方法、接口方法、方法類型、方法句柄和調用點限定符7類符號引用進行。符號引用就是一組符號來描述目標，可以是任何字面量。
? ? ? ?直接引用就是直接指向目標的指針、相對偏移量或一個間接定位到目標的句柄。
5、初始化
? ? ? ?初始化，為類的靜態變量賦予正確的初始值，JVM負責對類進行初始化，主要對類變量進行初始化。在Java中對類變量進行初始值設定有兩種方式：
? ? ? ?①聲明類變量是指定初始化值
? ? ? ?②使用靜態代碼塊為類變量指定初始值
?JVM初始化步驟
? ? ? ?1）假如這個類還沒有被加載和連接，則程序先加載并連接該類
? ? ? ?2）假如該類的直接父類還沒有被初始化，則先初始化其直接父類
? ? ? ?3）假如類中有初始化語句，則系統依次執行這些初始化語句
類初始化時機
只有當對類的主動使用的時候才會導致類的初始化，類的主動使用包括以下六種：
? ? ? ?– 創建類的實例，也就是new的方式
? ? ? ?– 訪問某個類或接口的靜態變量，或者對該靜態變量賦值
? ? ? ?– 調用類的靜態方法
? ? ? ?– 反射（如Class.forName(“com.shengsiyuan.Test”)）
? ? ? ?– 初始化某個類的子類，則其父類也會被初始化
? ? ? ?– Java虛擬機啟動時被標明為啟動類的類（Java Test），直接使用java.exe命令來運行某個主類
?
結束生命周期
在如下幾種情況下，Java虛擬機將結束生命周期：
? ? ? ?– 執行了System.exit()方法
? ? ? ?– 程序正常執行結束
? ? ? ?– 程序在執行過程中遇到了異常或錯誤而異常終止
? ? ? ?– 由于操作系統出現錯誤而導致Java虛擬機進程終止
三、Java虛擬機類加載器
1、JVM三種預定義類型類加載器
我們首先看一下JVM預定義的三種類型類加載器，當一個?JVM啟動的時候，Java缺省開始使用如下三種類型類裝入器：
? ? ? ?啟動（Bootstrap）類加載器：引導類裝入器是用本地代碼實現的類裝入器，它負責將%JAVA_HOME%\lib路徑下或-Xbootclasspath參數指定路徑下的、能被虛擬機識別的類庫（僅按照文件名識別，如：rt.jar，名字不符合的類庫不會被加載）加載至虛擬機內存中。由于引導類加載器涉及到虛擬機本地實現細節，開發者無法直接獲取到啟動類加載器的引用，所以不允許直接通過引用進行操作。
? ? ? ?擴展（Extension）類加載器：擴展類加載器是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）實現的。它負責將java.ext.dirs參數（默認值是%JAVA_HOME%\jre\lib\ext，可由VM參數-Djava.ext.dirs指定）指定路徑中的所有類庫加載到內存中。開發者可以直接使用標準擴展類加載器。
? ? ? ?系統（System）類加載器：系統類加載器是由?Sun的AppClassLoader（sun.misc.Launcher$AppClassLoader）實現的，由于這個類加載器是ClassLoader中的getSystemClassLoader()方法的返回值，也稱為系統類加載器。它負責將系統類路徑java -classpath或-Djava.class.path變量所指的目錄下的類庫加載到內存中。開發者可以直接使用系統類加載器。
? ? ? ?注意：上述三個JDK提供的類加載器雖然是父子類加載器關系，但是沒有使用繼承，而是使用了組合關系。
2、類加載雙親委派機制介紹和分析
從JDK1.2開始，java虛擬機規范推薦開發者使用雙親委派模式(ParentsDelegation Model)進行類加載，其加載過程如下：
? ? ? ?關于虛擬機默認的雙親委派機制，我們可以從系統類加載器和擴展類加載器為例作簡單分析。
圖一 標準擴展類加載器繼承層次圖
圖二系統類加載器繼承層次圖
? ? ? ?通過圖一和圖二我們可以看出，類加載器均是繼承自java.lang.ClassLoader抽象類。我們下面我們就看簡要介紹一下java.lang.ClassLoader中幾個最重要的方法：
//加載指定名稱（包括包名）的二進制類型，供用戶調用的接口 public Class<?> loadClass(String name) throws ClassNotFoundException{ … } //加載指定名稱（包括包名）的二進制類型，同時指定是否解析（但是這里的resolve參數不一定真正能達到解析的效果），供繼承用 protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{ … } //findClass方法一般被loadClass方法調用去加載指定名稱類，供繼承用 protected Class<?> findClass(String name) throws ClassNotFoundException { … } //定義類型，一般在findClass方法中讀取到對應字節碼后調用，可以看出不可繼承 //（說明：JVM已經實現了對應的具體功能，解析對應的字節碼，產生對應的內部數據結構放置到方法區，所以無需覆寫，直接調用就可以了） protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError{ … } ? ? ? ?通過進一步分析標準擴展類加載器（ sun.misc.Launcher$ExtClassLoader ）和系統類加載器（ sun.misc.Launcher$AppClassLoader ）的代碼以及其公共父類（java.net.URLClassLoader 和java.security.SecureClassLoader ）的代碼可以看出，都沒有覆寫 java.lang.ClassLoader中默認的加載委派規則---loadClass（… ）方法。既然這樣，我們就可以通過分析java.lang.ClassLoader 中的loadClass （String name）方法的代碼就可以分析出虛擬機默認采用的雙親委派機制到底是什么模樣：
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 findBootstrapClass0(String name) c = findBootstrapClass0(name); } } catch (ClassNotFoundException e) { // 如果父類加載器和啟動類加載器都不能完成加載任務，才調用自身的加載功能 c = findClass(name); } } if (resolve) { resolveClass(c); } return c; } ? ? ? ?通過上面的代碼分析，我們可以對JVM 采用的雙親委派類加載機制有了更感性的認識，下面我們就接著分析一下啟動類加載器、標準擴展類加載器和系統類加載器三者之間的關系。可能大家已經從各種資料上面看到了如下類似的一幅圖片：
圖三 類加載器默認委派關系圖
? ? ? ?上面圖片給人的直觀印象是系統類加載器的父類加載器是標準擴展類加載器，標準擴展類加載器的父類加載器是啟動類加載器，下面我們就用代碼具體測試一下：
public class LoaderTest { public static void main(String[] args) { try { System.out.println(ClassLoader.getSystemClassLoader()); System.out.println(ClassLoader.getSystemClassLoader().getParent()); System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent()); } catch (Exception e) { e.printStackTrace(); } } } ? ? ? ?說明：通過java.lang.ClassLoader.getSystemClassLoader()可以直接獲取到系統類加載器。
代碼輸出如下：
sun.misc.Launcher$AppClassLoader@6d06d69c sun.misc.Launcher$ExtClassLoader@70dea4e null ? ? ? ?通過以上的代碼輸出，我們可以判定系統類加載器的父加載器是標準擴展類加載器，但是我們試圖獲取標準擴展類加載器的父類加載器時確得到了 null，就是說標準擴展類加載器本身強制設定父類加載器為null 。我們還是借助于代碼分析一下。
我們首先看一下java.lang.ClassLoader抽象類中默認實現的兩個構造函數：
// The parent class loader for delegation private ClassLoader parent;? ? ? ?聲明為私有變量的同時并沒有對外提供可供派生類訪問的public或者protected設置器接口（對應的setter方法），結合前面的測試代碼的輸出，我們可以推斷出：
- 系統類加載器（AppClassLoader）調用ClassLoader(ClassLoader parent)構造函數將父類加載器設置為標準擴展類加載器(ExtClassLoader)。（因為如果不強制設置，默認會通過調用getSystemClassLoader()方法獲取并設置成系統類加載器，這顯然和測試輸出結果不符。）
- 擴展類加載器（ExtClassLoader）調用ClassLoader(ClassLoader parent)構造函數將父類加載器設置為null。（因為如果不強制設置，默認會通過調用getSystemClassLoader()方法獲取并設置成系統類加載器，這顯然和測試輸出結果不符。）
? ? ? ?現在我們可能會有這樣的疑問：擴展類加載器（ExtClassLoader）的父類加載器被強制設置為null了，那么擴展類加載器為什么還能將加載任務委派給啟動類加載器呢？
? ? ? ?通過圖四和圖五可以看出，標準擴展類加載器和系統類加載器及其父類（java.net.URLClassLoader和java.security.SecureClassLoader）都沒有覆寫java.lang.ClassLoader中默認的加載委派規則---loadClass（…）方法。有關java.lang.ClassLoader中默認的加載委派規則前面已經分析過，如果父加載器為null，則會調用本地方法進行啟動類加載嘗試。所以，圖三中，啟動類加載器、標準擴展類加載器和系統類加載器之間的委派關系事實上是仍就成立的。（在后面的用戶自定義類加載器部分，還會做更深入的分析）。
? ? ? ?雙親委派模式的類加載機制的優點：java類它的類加載器一起具備了一種帶優先級的層次關系，越是基礎的類，越是被上層的類加載器進行加載，保證了java程序的穩定運行。
3、類加載雙親委派示例
? ? ? ?以上已經簡要介紹了虛擬機默認使用的啟動類加載器、標準擴展類加載器和系統類加載器，并以三者為例結合JDK代碼對JVM默認使用的雙親委派類加載機制做了分析。下面我們就來看一個綜合的例子。首先在IDE中建立一個簡單的java應用工程，然后寫一個簡單的JavaBean如下：
package classloader.test.bean; public class TestBean { public TestBean() { } } 在現有當前工程中另外建立一測試類（ClassLoaderTest.java）內容如下：
測試一：
package classloader.test.bean; public class ClassLoaderTest { public static void main(String[] args) { try { //查看當前系統類路徑中包含的路徑條目 System.out.println(System.getProperty("java.class.path")); //調用加載當前類的類加載器（這里即為系統類加載器）加載TestBean Class typeLoaded = Class.forName("classloader.test.bean.TestBean"); //查看被加載的TestBean類型是被那個類加載器加載的 System.out.println(typeLoaded.getClassLoader()); } catch (Exception e) { e.printStackTrace(); } } } 輸出結果：
C:\Users\Administrator\Documents\NetBeansProjects\ClassLoaderTest\build\classes sun.misc.Launcher$AppClassLoader@73d16e93 說明：當前類路徑默認的含有的一個條目就是工程的輸出目錄。
測試二：
? ? ? ?將當前工程輸出目錄下的TestBean.class打包進test.jar剪貼到<Java_Runtime_Home>/lib/ext目錄下（現在工程輸出目錄下和JRE擴展目錄下都有待加載類型的class文件）。再運行測試一測試代碼，結果如下：
C:\Users\Administrator\Documents\NetBeansProjects\ClassLoaderTest\build\classes sun.misc.Launcher$ExtClassLoader@15db9742
? ? ? ?對比測試一和測試二，我們明顯可以驗證前面說的雙親委派機制，系統類加載器在接到加載classloader.test.bean.TestBean類型的請求時，首先將請求委派給父類加載器（標準擴展類加載器），標準擴展類加載器搶先完成了加載請求。
測試三：
? ? ? ?將test.jar拷貝一份到<Java_Runtime_Home>/lib下，運行測試代碼，輸出如下：C:\Users\Administrator\Documents\NetBeansProjects\ClassLoaderTest\build\classes sun.misc.Launcher$ExtClassLoader@15db9742? ? ? ?測試三和測試二輸出結果一致。那就是說，放置到<Java_Runtime_Home>/lib目錄下的TestBean對應的class字節碼并沒有被加載，這其實和前面講的雙親委派機制并不矛盾。 虛擬機出于安全等因素考慮，不會加載<Java_Runtime_Home>/lib存在的陌生類，開發者通過將要加載的非JDK自身的類放置到此目錄下期待啟動類加載器加載是不可能的。做個進一步驗證，刪除<Java_Runtime_Home>/lib/ext目錄下和工程輸出目錄下的TestBean對應的class文件，然后再運行測試代碼，則將會有ClassNotFoundException異常拋出。有關這個問題，大家可以在java.lang.ClassLoader中的loadClass(String name, boolean resolve)方法中設置相應斷點運行測試三進行調試，會發現findBootstrapClass0()會拋出異常，然后在下面的findClass方法中被加載，當前運行的類加載器正是擴展類加載器（sun.misc.Launcher$ExtClassLoader），這一點可以通過JDT中變量視圖查看驗證。
四、Java程序動態擴展方式
? ? ? ?Java的連接模型允許用戶運行時擴展引用程序，既可以通過當前虛擬機中預定義的加載器加載編譯時已知的類或者接口，又允許用戶自行定義類裝載器，在運行時動態擴展用戶的程序。通過用戶自定義的類裝載器，你的程序可以裝載在編譯時并不知道或者尚未存在的類或者接口，并動態連接它們并進行有選擇的解析。
運行時動態擴展java應用程序有如下兩個途徑：
1、調用java.lang.Class.forName(…)加載類
? ? ? ?這個方法其實在前面已經討論過，在后面的問題2解答中說明了該方法調用會觸發哪個類加載器開始加載任務。這里需要說明的是多參數版本的forName(…)方法：public static Class<?> forName(String name, boolean initialize, ClassLoader loader) throws ClassNotFoundException? ? ? ?這里的initialize參數是很重要的。它表示在加載同時是否完成初始化的工作（說明：單參數版本的forName方法默認是完成初始化的）。 有些場景下需要將initialize設置為true來強制加載同時完成初始化。例如典型的就是利用DriverManager進行JDBC驅動程序類注冊的問題。因為每一個JDBC驅動程序類的靜態初始化方法都用DriverManager注冊驅動程序，這樣才能被應用程序使用。這就要求驅動程序類必須被初始化，而不單單被加載。Class.forName的一個很常見的用法就是在加載數據庫驅動的時候。如 Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance()用來加載 Apache Derby 數據庫的驅動。
2、用戶自定義類加載器
? ? ? ?通過前面的分析，我們可以看出，除了和本地實現密切相關的啟動類加載器之外，包括標準擴展類加載器和系統類加載器在內的所有其他類加載器我們都可以當做自定義類加載器來對待，唯一區別是是否被虛擬機默認使用。前面的內容中已經對java.lang.ClassLoader抽象類中的幾個重要的方法做了介紹，這里就簡要敘述一下一般用戶自定義類加載器的工作流程吧（可以結合后面問題解答一起看）：
? ? ? ?說明：這里說的自定義類加載器是指JDK 1.2以后版本的寫法，即不覆寫改變java.lang.loadClass(…)已有委派邏輯情況下。
整個加載類的過程如下圖：
圖六 自定義類加載器加載類的過程
五、常見問題
1、由不同的類加載器加載的指定類還是相同的類型嗎？
? ? ? ?在Java中，一個類用其完全匹配類名(fully qualified class name)作為標識，這里指的完全匹配類名包括包名和類名。但在JVM中一個類用其全名和一個加載類ClassLoader的實例作為唯一標識，不同類加載器加載的類將被置于不同的命名空間。我們可以用兩個自定義類加載器去加載某自定義類型（注意不要將自定義類型的字節碼放置到系統路徑或者擴展路徑中，否則會被系統類加載器或擴展類加載器搶先加載），然后用獲取到的兩個Class實例進行java.lang.Object.equals（…）判斷，將會得到不相等的結果。這個大家可以寫兩個自定義的類加載器去加載相同的自定義類型，然后做個判斷；同時，可以測試加載java.*類型，然后再對比測試一下測試結果。
2、在代碼中直接調用Class.forName(String name)方法，到底會觸發那個類加載器進行類加載行為？
Class.forName(String name)默認會使用調用類的類加載器來進行類加載。我們直接來分析一下對應的jdk的代碼：
//java.lang.Class.java publicstatic Class<?> forName(String className) throws ClassNotFoundException { return forName0(className, true, ClassLoader.getCallerClassLoader()); } //java.lang.ClassLoader.java // Returns the invoker's class loader, or null if none. static ClassLoader getCallerClassLoader() { // 獲取調用類（caller）的類型 Class caller = Reflection.getCallerClass(3); // This can be null if the VM is requesting it if (caller == null) { return null; } // 調用java.lang.Class中本地方法獲取加載該調用類（caller）的ClassLoader return caller.getClassLoader0(); } //java.lang.Class.java //虛擬機本地實現，獲取當前類的類加載器，前面介紹的Class的getClassLoader()也使用此方法 native ClassLoader getClassLoader0();
? ? ? ?前面講過，在不指定父類加載器的情況下，默認采用系統類加載器。可能有人覺得不明白，現在我們來看一下JDK對應的代碼實現。眾所周知，我們編寫自定義的類加載器直接或者間接繼承自java.lang.ClassLoader抽象類，對應的無參默認構造函數實現如下：
//摘自java.lang.ClassLoader.java protected ClassLoader() { SecurityManager security = System.getSecurityManager(); if (security != null) { security.checkCreateClassLoader(); } this.parent = getSystemClassLoader(); initialized = true; } 我們再來看一下對應的getSystemClassLoader()方法的實現：
private static synchronized void initSystemClassLoader() { //... sun.misc.Launcher l = sun.misc.Launcher.getLauncher(); scl = l.getClassLoader(); //... } 我們可以寫簡單的測試代碼來測試一下：
System.out.println(sun.misc.Launcher.getLauncher().getClassLoader()); 輸出結果：
sun.misc.Launcher$AppClassLoader@73d16e93 ? ? ? ?所以，我們現在可以相信當自定義類加載器沒有指定父類加載器的情況下，默認的父類加載器即為系統類加載器。同時，我們可以得出如下結論： 即使用戶自定義類加載器不指定父類加載器，那么，同樣可以加載如下三個地方的類：
4、在編寫自定義類加載器時，如果將父類加載器強制設置為null，那么會有什么影響？如果自定義的類加載器不能加載指定類，就肯定會加載失敗嗎？
? ? ? ?JVM規范中規定如果用戶自定義的類加載器將父類加載器強制設置為null，那么會自動將啟動類加載器設置為當前用戶自定義類加載器的父類加載器（這個問題前面已經分析過了）。同時，我們可以得出如下結論：
? ? ? ?即使用戶自定義類加載器不指定父類加載器，那么，同樣可以加載到<Java_Runtime_Home>/lib下的類，但此時就不能夠加載<Java_Runtime_Home>/lib/ext目錄下的類了。
? ? ? ?說明：問題3和問題4的推斷結論是基于用戶自定義的類加載器本身延續了java.lang.ClassLoader.loadClass（…）默認委派邏輯，如果用戶對這一默認委派邏輯進行了改變，以上推斷結論就不一定成立了，詳見問題5。
5、編寫自定義類加載器時，一般有哪些注意點？
1）一般盡量不要覆寫已有的loadClass(...)方法中的委派邏輯
? ? ? ?一般在JDK 1.2之前的版本才這樣做，而且事實證明，這樣做極有可能引起系統默認的類加載器不能正常工作。在JVM規范和JDK文檔中（1.2或者以后版本中），都沒有建議用戶覆寫loadClass(…)方法，相比而言，明確提示開發者在開發自定義的類加載器時覆寫findClass(…)邏輯。舉一個例子來驗證該問題：
//用戶自定義類加載器WrongClassLoader.Java（覆寫loadClass邏輯） public class WrongClassLoader extends ClassLoader { public Class<?> loadClass(String name) throws ClassNotFoundException { return this.findClass(name); } protected Class<?> findClass(String name) throws ClassNotFoundException { // 假設此處只是到工程以外的特定目錄D:\library下去加載類 // 具體實現代碼省略 } } ? ? ? ?通過前面的分析我們已經知道，這個自定義類加載器WrongClassLoader的默認類加載器是系統類加載器，但是現在問題4種的結論就不成立了。大家可以簡單測試一下，現在<Java_Runtime_Home>/lib、< Java_Runtime_Home >/lib/ext和工程類路徑上的類都加載不上了。//問題5測試代碼一 public class WrongClassLoaderTest { publicstaticvoid main(String[] args) { try { WrongClassLoader loader = new WrongClassLoader(); Class classLoaded = loader.loadClass("beans.Account"); System.out.println(classLoaded.getName()); System.out.println(classLoaded.getClassLoader()); } catch (Exception e) { e.printStackTrace(); } } } 這里D:"classes"beans"Account.class是物理存在的。輸出結果：
java.io.FileNotFoundException: D:"classes"java"lang"Object.class (系統找不到指定的路徑。) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.<init>(FileInputStream.java:106) at WrongClassLoader.findClass(WrongClassLoader.java:40) at WrongClassLoader.loadClass(WrongClassLoader.java:29) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.lang.ClassLoader.defineClass(ClassLoader.java:400) at WrongClassLoader.findClass(WrongClassLoader.java:43) at WrongClassLoader.loadClass(WrongClassLoader.java:29) at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27) Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Object at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.lang.ClassLoader.defineClass(ClassLoader.java:400) at WrongClassLoader.findClass(WrongClassLoader.java:43) at WrongClassLoader.loadClass(WrongClassLoader.java:29) at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27) ? ? ? ?這說明，連要加載的類型的超類型java.lang.Object都加載不到了。這里列舉的由于覆寫loadClass()引起的邏輯錯誤明顯是比較簡單的，實際引起的邏輯錯誤可能復雜的多。
//問題5測試二 //用戶自定義類加載器WrongClassLoader.Java(不覆寫loadClass邏輯) public class WrongClassLoader extends ClassLoader { protected Class<?> findClass(String name) throws ClassNotFoundException { //假設此處只是到工程以外的特定目錄D:\library下去加載類 //具體實現代碼省略 } } 將自定義類加載器代碼WrongClassLoader.Java做以上修改后，再運行測試代碼，輸出結果如下：
beans.Account WrongClassLoader@1c78e57 2）正確設置父類加載器
? ? ? ?通過上面問題4和問題5的分析我們應該已經理解，個人覺得這是自定義用戶類加載器時最重要的一點，但常常被忽略或者輕易帶過。有了前面JDK代碼的分析作為基礎，我想現在大家都可以隨便舉出例子了。
3）保證findClass(String name)方法的邏輯正確性
? ? ? ?事先盡量準確理解待定義的類加載器要完成的加載任務，確保最大程度上能夠獲取到對應的字節碼內容。
6、如何在運行時判斷系統類加載器能加載哪些路徑下的類？
? ? ? ?一是可以直接調用ClassLoader.getSystemClassLoader()或者其他方式獲取到系統類加載器（系統類加載器和擴展類加載器本身都派生自URLClassLoader），調用URLClassLoader中的getURLs()方法可以獲取到。
? ? ? ?二是可以直接通過獲取系統屬性java.class.path來查看當前類路徑上的條目信息 ：System.getProperty("java.class.path")。
7、如何在運行時判斷標準擴展類加載器能加載哪些路徑下的類？
方法一：
import java.net.URL; import java.net.URLClassLoader; public class ClassLoaderTest { /** * @param args the command line arguments */ public static void main(String[] args) { try { URL[] extURLs = ((URLClassLoader) ClassLoader.getSystemClassLoader().getParent()).getURLs(); for (int i = 0; i < extURLs.length; i++) { System.out.println(extURLs[i]); } } catch (Exception e) { //… } } } 輸出結果： file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/access-bridge-64.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/cldrdata.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/dnsns.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/jaccess.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/jfxrt.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/localedata.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/nashorn.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/sunec.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/sunjce_provider.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/sunmscapi.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/sunpkcs11.jar file:/C:/Program%20Files/Java/jdk1.8.0_05/jre/lib/ext/zipfs.jar六、開發自己的類加載器
? ? ? ?在前面介紹類加載器的代理委派模式的時候，提到過類加載器會首先代理給其它類加載器來嘗試加載某個類。這就意味著真正完成類的加載工作的類加載器和啟動這個加載過程的類加載器，有可能不是同一個。真正完成類的加載工作是通過調用defineClass來實現的；而啟動類的加載過程是通過調用loadClass來實現的。前者稱為一個類的定義加載器（defining loader），后者稱為初始加載器（initiating loader）。在Java虛擬機判斷兩個類是否相同的時候，使用的是類的定義加載器。也就是說，哪個類加載器啟動類的加載過程并不重要，重要的是最終定義這個類的加載器。兩種類加載器的關聯之處在于：一個類的定義加載器是它引用的其它類的初始加載器。如類 com.example.Outer引用了類 com.example.Inner，則由類 com.example.Outer的定義加載器負責啟動類 com.example.Inner的加載過程。
? ? ? ?方法 loadClass()拋出的是 java.lang.ClassNotFoundException異常；方法 defineClass()拋出的是 java.lang.NoClassDefFoundError異常。
? ? ? ?類加載器在成功加載某個類之后，會把得到的 java.lang.Class類的實例緩存起來。下次再請求加載該類的時候，類加載器會直接使用緩存的類的實例，而不會嘗試再次加載。也就是說，對于一個類加載器實例來說，相同全名的類只加載一次，即 loadClass方法不會被重復調用。
? ? ? ?在絕大多數情況下，系統默認提供的類加載器實現已經可以滿足需求。但是在某些情況下，您還是需要為應用開發出自己的類加載器。比如您的應用通過網絡來傳輸Java類的字節代碼，為了保證安全性，這些字節代碼經過了加密處理。這個時候您就需要自己的類加載器來從某個網絡地址上讀取加密后的字節代碼，接著進行解密和驗證，最后定義出要在Java虛擬機中運行的類來。下面將通過兩個具體的實例來說明類加載器的開發。
1、文件系統類加載器
第一個類加載器用來加載存儲在文件系統上的Java字節代碼。完整的實現如下所示。
? ? ? ?類 FileSystemClassLoader的 findClass()方法首先根據類的全名在硬盤上查找類的字節代碼文件（.class 文件），然后讀取該文件內容，最后通過defineClass()方法來把這些字節代碼轉換成 java.lang.Class類的實例。
加載本地文件系統上的類，示例如下：
com.example.Sample@7852e922
? ? ? ?下面將通過一個網絡類加載器來說明如何通過類加載器來實現組件的動態更新。即基本的場景是：Java 字節代碼（.class）文件存放在服務器上，客戶端通過網絡的方式獲取字節代碼并執行。當有版本更新的時候，只需要替換掉服務器上保存的文件即可。通過類加載器可以比較簡單的實現這種需求。
? ? ? ?類 NetworkClassLoader負責通過網絡下載Java類字節代碼并定義出Java類。它的實現與FileSystemClassLoader類似。
客戶端接口：
網絡上的不同版本的類：
package classloader; public class CalculatorTest { public static void main(String[] args) { String url = "http://localhost:8080/ClassloaderTest/classes"; NetworkClassLoader ncl = new NetworkClassLoader(url); String basicClassName = "com.example.CalculatorBasic"; String advancedClassName = "com.example.CalculatorAdvanced"; try { Class<?> clazz = ncl.loadClass(basicClassName); // 加載一個版本的類 ICalculator calculator = (ICalculator) clazz.newInstance(); // 創建對象 System.out.println(calculator.getVersion()); clazz = ncl.loadClass(advancedClassName); // 加載另一個版本的類 calculator = (ICalculator) clazz.newInstance(); System.out.println(calculator.getVersion()); } catch (Exception e) { e.printStackTrace(); } } }
總結
以上是生活随笔為你收集整理的Java基础——类加载机制及原理的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Python已成美国顶尖高校中最受欢迎的
- 下一篇： Java基础——深入理解Java线程池