一、類加載器
類加載器（classloader），顧名思義，即加載類的東西。在我們使用一個類之前，jvm需要先將該類的字節碼文件（.class文件）從磁盤、網絡或其他來源加載到內存中，并對字節碼進行解析生成對應的class對象，這就是類加載器的功能。我們可以利用類加載器，實現類的動態加載。
二、類的加載機制
在java中，采用雙親委派機制來實現類的加載。那什么是雙親委派機制？在java doc中有這樣一段描述：
|
1
2
3
4
5
6
|
the classloader class uses a delegation model to search for classes and resources. each instance of classloader has an associated parent class loader. when requested to find a class or resource, a classloader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. the virtual machine's built-in class loader, called the "bootstrap class loader", does not itself have a parent but may serve as the parent of a classloader instance. |
從以上描述中，我們可以總結出如下四點：
1、類的加載過程采用委托模式實現
2、每個 classloader 都有一個父加載器。
3、類加載器在加載類之前會先遞歸的去嘗試使用父加載器加載。
4、虛擬機有一個內建的啟動類加載器（bootstrap classloader），該加載器沒有父加載器，但是可以作為其他加載器的父加載器。
java 提供三種類型的系統類加載器。第一種是啟動類加載器，由c++語言實現，屬于jvm的一部分，其作用是加載 <java_runtime_home>/lib 目錄中的文件，并且該類加載器只加載特定名稱的文件（如 rt.jar），而不是該目錄下所有的文件。另外兩種是 java 語言自身實現的類加載器，包括擴展類加載器（extclassloader）和應用類加載器（appclassloader），擴展類加載器負責加載<java_runtime_home>\lib\ext目錄中或系統變量 java.ext.dirs 所指定的目錄中的文件。應用程序類加載器負責加載用戶類路徑中的文件。用戶可以直接使用擴展類加載器或系統類加載器來加載自己的類，但是用戶無法直接使用啟動類加載器，除了這兩種類加載器以外，用戶也可以自定義類加載器，加載流程如下圖所示：
注意：這里父類加載器并不是通過繼承關系來實現的，而是采用組合實現的。
我們可以通過一段程序來驗證這個過程：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
public class test {} public class testmain { public static void main(string[] args) { classloader loader = test.class.getclassloader(); while (loader!=null){ system.out.println(loader); loader = loader.getparent(); } }} |
上面程序的運行結果如下所示:
從結果我們可以看出，默認情況下，用戶自定義的類使用 appclassloader 加載，appclassloader 的父加載器為 extclassloader，但是 extclassloader 的父加載器卻顯示為空，這是什么原因呢？究其緣由，啟動類加載器屬于 jvm 的一部分，它不是由 java 語言實現的，在 java 中無法直接引用，所以才返回空。但如果是這樣，該怎么實現 extclassloader 與 啟動類加載器之間雙親委派機制？我們可以參考一下源碼：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
protected class<?> loadclass(string name, boolean resolve) throws classnotfoundexception { synchronized (getclassloadinglock(name)) { // first, check if the class has already been loaded class<?> c = findloadedclass(name); if (c == null) { long t0 = system.nanotime(); 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. long t1 = system.nanotime(); c = findclass(name); // this is the defining class loader; record the stats sun.misc.perfcounter.getparentdelegationtime().addtime(t1 - t0); sun.misc.perfcounter.getfindclasstime().addelapsedtimefrom(t1); sun.misc.perfcounter.getfindclasses().increment(); } } if (resolve) { resolveclass(c); } return c; } } |
從源碼可以看出，extclassloader 和 appclassloader都繼承自 classloader 類，classloader 類中通過 loadclass 方法來實現雙親委派機制。整個類的加載過程可分為如下三步：
1、查找對應的類是否已經加載。
2、若未加載，則判斷當前類加載器的父加載器是否為空，不為空則委托給父類去加載，否則調用啟動類加載器加載（findbootstrapclassornull 再往下會調用一個 native 方法）。
3、若第二步加載失敗，則調用當前類加載器加載。
通過上面這段程序，可以很清楚的看出擴展類加載器與啟動類加載器之間是如何實現委托模式的。
現在，我們再驗證另一個問題。我們將剛才的test類打成jar包，將其放置在 <java_runtime_home>\lib\ext 目錄下，然后再次運行上面的代碼，結果如下：
現在，該類就不再通過 appclassloader 來加載，而是通過 extclassloader 來加載了。如果我們試圖把jar包拷貝到<java_runtime_home>\lib，嘗試通過啟動類加載器加載該類時，我們會發現編譯器無法識別該類，因為啟動類加載器除了指定目錄外，還必須是特定名稱的文件才能加載。
三、自定義類加載器
通常情況下，我們都是直接使用系統類加載器。但是，有的時候，我們也需要自定義類加載器。比如應用是通過網絡來傳輸 java 類的字節碼，為保證安全性，這些字節碼經過了加密處理，這時系統類加載器就無法對其進行加載，這樣則需要自定義類加載器來實現。自定義類加載器一般都是繼承自 classloader 類，從上面對 loadclass 方法來分析來看，我們只需要重寫 findclass 方法即可。下面我們通過一個示例來演示自定義類加載器的流程：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
package com.paddx.test.classloading; import java.io.*; /** * created by liuxp on 16/3/12. */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("/users/liuxp/tmp"); class<?> testclass = null; try { testclass = classloader.loadclass("com.paddx.test.classloading.test"); 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 加載，而不會通過我們自定義類加載器來加載。
四、總結
雙親委派機制能很好地解決類加載的統一性問題。對一個 class 對象來說，如果類加載器不同，即便是同一個字節碼文件，生成的 class 對象也是不等的。也就是說，類加載器相當于 class 對象的一個命名空間。雙親委派機制則保證了基類都由相同的類加載器加載，這樣就避免了同一個字節碼文件被多次加載生成不同的 class 對象的問題。但雙親委派機制僅僅是java 規范所推薦的一種實現方式，它并不是強制性的要求。近年來，很多熱部署的技術都已不遵循這一規則，如 osgi 技術就采用了一種網狀的結構，而非雙親委派機制。
感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！
