實習雜記（30）：虛擬機類加載機制（3）

• 2019 年 11 月 14 日
• 筆記

轉載地址：http://blog.csdn.net/zhoudaxia/article/details/35824249

1 基本信息

　　每個開發人員對Java.lang.ClassNotFoundExcetpion這個異常肯定都不陌生，這背後就涉及到了java技術體系中的類加載。Java的類加載機制是技術體系中比較核心的部分，雖然和大部分開發人員直接打交道不多，但是對其背後的機理有一定理解有助於排查程序中出現的類加載失敗等技術問題，對理解java虛擬機的連接模型和java語言的動態性都有很大幫助。

2 Java虛擬機類加載器結構簡述

2.1 JVM三種預定義類型類加載器

　　我們首先看一下JVM預定義的三種類型類加載器，當一個 JVM啟動的時候，Java缺省開始使用如下三種類型類裝入器：

　　啟動（Bootstrap）類加載器：引導類裝入器是用本地代碼實現的類裝入器，它負責將 <Java_Runtime_Home>/lib下面的核心類庫或-Xbootclasspath選項指定的jar包加載到內存中。由於引導類加載器涉及到虛擬機本地實現細節，開發者無法直接獲取到啟動類加載器的引用，所以不允許直接通過引用進行操作。

　　擴展（Extension）類加載器：擴展類加載器是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）實現的。它負責將< Java_Runtime_Home >/lib/ext或者由系統變量-Djava.ext.dir指定位置中的類庫加載到內存中。開發者可以直接使用標準擴展類加載器。

　　系統（System）類加載器：系統類加載器是由 Sun的 AppClassLoader（sun.misc.Launcher$AppClassLoader）實現的。它負責將系統類路徑java -classpath或-Djava.class.path變量所指的目錄下的類庫加載到內存中。開發者可以直接使用系統類加載器。

　　除了以上列舉的三種類加載器，還有一種比較特殊的類型就是線程上下文類加載器，這個將在後面單獨介紹。

2.2 類加載雙親委派機制介紹和分析

在這裡，需要着重說明的是，JVM在加載類時默認採用的是雙親委派機制。通俗的講，就是某個特定的類加載器在接到加載類的請求時，首先將加載任務委託給父類加載器，依次遞歸，如果父類加載器可以完成類加載任務，就成功返回；只有父類加載器無法完成此加載任務時，才自己去加載。關於虛擬機默認的雙親委派機制，我們可以從系統類加載器和擴展類加載器為例作簡單分析。

圖一 標準擴展類加載器繼承層次圖

圖二系統類加載器繼承層次圖

通過圖一和圖二我們可以看出，類加載器均是繼承自java.lang.ClassLoader抽象類。我們下面我們就看簡要介紹一下java.lang.ClassLoader中幾個最重要的方法：

1. public Class<?> loadClass(String name) throws ClassNotFoundException{ … }
2. //加載指定名稱（包括包名）的二進制類型，同時指定是否解析（但是這裡的resolve參數不一定真正能達到解析的效果），供繼承用
3. protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException{ … }
5. //findClass方法一般被loadClass方法調用去加載指定名稱類，供繼承用
6. protected Class<?> findClass(String name) throws ClassNotFoundException { … }
8. //定義類型，一般在findClass方法中讀取到對應位元組碼後調用，可以看出不可繼承
9. //（說明：JVM已經實現了對應的具體功能，解析對應的位元組碼，產生對應的內部數據結構放置到方法區，所以無需覆寫，直接調用就可以了）
10. 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）方法的代碼就可以分析出虛擬機默認採用的雙親委派機制到底是什麼模樣：

[java] view plain copy

1. return loadClass(name, false);
2. }
4. protected synchronized Class<?> loadClass(String name, boolean resolve)
5. throws ClassNotFoundException {
7. // 首先判斷該類型是否已經被加載
8. Class c = findLoadedClass(name);
9. if (c == null) {
10. //如果沒有被加載，就委託給父類加載或者委派給啟動類加載器加載
11. try {
12. if (parent != null) {
13. //如果存在父類加載器，就委派給父類加載器加載
14. c = parent.loadClass(name, false);
15. } else {
16. //如果不存在父類加載器，就檢查是否是由啟動類加載器加載的類，
17. //通過調用本地方法native findBootstrapClass0(String name)
18. c = findBootstrapClass0(name);
19. }
20. } catch (ClassNotFoundException e) {
21. // 如果父類加載器和啟動類加載器都不能完成加載任務，才調用自身的加載功能
22. c = findClass(name);
23. }
24. }
25. if (resolve) {
26. resolveClass(c);
27. }
28. return c;
29. }

　　通過上面的代碼分析，我們可以對JVM採用的雙親委派類加載機制有了更感性的認識，下面我們就接着分析一下啟動類加載器、標準擴展類加載器和系統類加載器三者之間的關係。可能大家已經從各種資料上面看到了如下類似的一幅圖片：

圖三 類加載器默認委派關係圖

　　上面圖片給人的直觀印象是系統類加載器的父類加載器是標準擴展類加載器，標準擴展類加載器的父類加載器是啟動類加載器，下面我們就用代碼具體測試一下：

[java] view plain copy

2. public static void main(String[] args) {
3. try {
4. System.out.println(ClassLoader.getSystemClassLoader());
5. System.out.println(ClassLoader.getSystemClassLoader().getParent());
6. System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());
7. } catch (Exception e) {
8. e.printStackTrace();
9. }
10. }
11. }

　　說明：通過java.lang.ClassLoader.getSystemClassLoader()可以直接獲取到系統類加載器。 　　代碼輸出如下：

[plain] view plain copy

1. sun.misc.Launcher$AppClassLoader@6d06d69c
2. sun.misc.Launcher$ExtClassLoader@70dea4e
3. null

　　通過以上的代碼輸出，我們可以判定系統類加載器的父加載器是標準擴展類加載器，但是我們試圖獲取標準擴展類加載器的父類加載器時確得到了null，就是說標準擴展類加載器本身強制設定父類加載器為null。我們還是藉助於代碼分析一下。

　　我們首先看一下java.lang.ClassLoader抽象類中默認實現的兩個構造函數：

[java] view plain copy

1. protected ClassLoader() {
2. SecurityManager security = System.getSecurityManager();
3. if (security != null) {
4. security.checkCreateClassLoader();
5. }
6. //默認將父類加載器設置為系統類加載器，getSystemClassLoader()獲取系統類加載器
7. this.parent = getSystemClassLoader();
8. initialized = true;
9. }
11. protected ClassLoader(ClassLoader parent) {
12. SecurityManager security = System.getSecurityManager();
13. if (security != null) {
14. security.checkCreateClassLoader();
15. }
16. //強制設置父類加載器
17. this.parent = parent;
18. initialized = true;
19. }

我們再看一下ClassLoader抽象類中parent成員的聲明：

[java] view plain copy

1. // The parent class loader for delegation
2. private ClassLoader parent;

　　聲明為私有變量的同時並沒有對外提供可供派生類訪問的public或者protected設置器接口（對應的setter方法），結合前面的測試代碼的輸出，我們可以推斷出： 　　1． 系統類加載器（AppClassLoader）調用ClassLoader(ClassLoader parent)構造函數將父類加載器設置為標準擴展類加載器(ExtClassLoader)。（因為如果不強制設置，默認會通過調用getSystemClassLoader()方法獲取並設置成系統類加載器，這顯然和測試輸出結果不符。） 　　2． 擴展類加載器（ExtClassLoader）調用ClassLoader(ClassLoader parent)構造函數將父類加載器設置為null。（因為如果不強制設置，默認會通過調用getSystemClassLoader()方法獲取並設置成系統類加載器，這顯然和測試輸出結果不符。） 　　現在我們可能會有這樣的疑問：擴展類加載器（ExtClassLoader）的父類加載器被強制設置為null了，那麼擴展類加載器為什麼還能將加載任務委派給啟動類加載器呢？

圖四 標準擴展類加載器和系統類加載器成員大綱視圖

圖五 擴展類加載器和系統類加載器公共父類成員大綱視圖

　　通過圖四和圖五可以看出，標準擴展類加載器和系統類加載器及其父類（java.net.URLClassLoader和java.security.SecureClassLoader）都沒有覆寫java.lang.ClassLoader中默認的加載委派規則—loadClass（…）方法。有關java.lang.ClassLoader中默認的加載委派規則前面已經分析過，如果父加載器為null，則會調用本地方法進行啟動類加載嘗試。所以，圖三中，啟動類加載器、標準擴展類加載器和系統類加載器之間的委派關係事實上是仍就成立的。（在後面的用戶自定義類加載器部分，還會做更深入的分析）。

2.3 類加載雙親委派示例

　　以上已經簡要介紹了虛擬機默認使用的啟動類加載器、標準擴展類加載器和系統類加載器，並以三者為例結合JDK代碼對JVM默認使用的雙親委派類加載機製做了分析。下面我們就來看一個綜合的例子。首先在IDE中建立一個簡單的java應用工程，然後寫一個簡單的JavaBean如下：

[java] view plain copy

1. package classloader.test.bean;
3. public class TestBean {
5. public TestBean() { }
6. }

　　在現有當前工程中另外建立一測試類（ClassLoaderTest.java）內容如下：

　　測試一：

[java] view plain copy

1. package classloader.test.bean;
3. public class ClassLoaderTest {
5. public static void main(String[] args) {
6. try {
7. //查看當前系統類路徑中包含的路徑條目
8. System.out.println(System.getProperty("java.class.path"));
9. //調用加載當前類的類加載器（這裡即為系統類加載器）加載TestBean
10. Class typeLoaded = Class.forName("classloader.test.bean.TestBean");
11. //查看被加載的TestBean類型是被那個類加載器加載的
12. System.out.println(typeLoaded.getClassLoader());
13. } catch (Exception e) {
14. e.printStackTrace();
15. }
16. }
17. }

對應的輸出如下：

[plain] view plain copy

1. C:UsersJackZhouDocumentsNetBeansProjectsClassLoaderTestbuildclasses
2. sun.misc.Launcher$AppClassLoader@73d16e93

說明：當前類路徑默認的含有的一個條目就是工程的輸出目錄。 測試二：

　　將當前工程輸出目錄下的TestBean.class打包進test.jar剪貼到<Java_Runtime_Home>/lib/ext目錄下（現在工程輸出目錄下和JRE擴展目錄下都有待加載類型的class文件）。再運行測試一測試代碼，結果如下：

[plain] view plain copy

1. C:UsersJackZhouDocumentsNetBeansProjectsClassLoaderTestbuildclasses
2. sun.misc.Launcher$ExtClassLoader@15db9742

　　對比測試一和測試二，我們明顯可以驗證前面說的雙親委派機制，系統類加載器在接到加載classloader.test.bean.TestBean類型的請求時，首先將請求委派給父類加載器（標準擴展類加載器），標準擴展類加載器搶先完成了加載請求。 　　測試三： 　　將test.jar拷貝一份到<Java_Runtime_Home>/lib下，運行測試代碼，輸出如下：

[plain] view plain copy

1. C:UsersJackZhouDocumentsNetBeansProjectsClassLoaderTestbuildclasses
2. 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中變量視圖查看驗證。