Java 類加載機制詳解
來源：原創(chuàng) 時間：2017-11-03 瀏覽：0 次
什么是 Java 類加載機制?
Java 虛擬機一般使用 Java 類的流程為：首先將開發(fā)者編寫的 Java 源代碼（.java文件）編譯成 Java 字節(jié)碼（.class文件），然后類加載器會讀取這個 .class 文件，并轉(zhuǎn)換成 java.lang.Class 的實例。有了該 Class 實例后，Java 虛擬機可以利用 newInstance 之類的方法創(chuàng)建其真正對象了。
ClassLoader 是 Java 提供的類加載器，絕大多數(shù)的類加載器都繼承自 ClassLoader，它們被用來加載不同來源的 Class 文件。
Class 文件有哪些來源呢?
上文提到了 ClassLoader 可以去加載多種來源的 Class，那么具體有哪些來源呢？
首先，最常見的是開發(fā)者在應用程序中編寫的類，這些類位于項目目錄下；
然后，有 Java 內(nèi)部自帶的核心類如 java.lang、java.math、java.io 等 package 內(nèi)部的類，位于 $JAVA_HOME/jre/lib/ 目錄下，如 java.lang.String 類就是定義在 $JAVA_HOME/jre/lib/rt.jar 文件里；
另外，還有 Java 核心擴展類，位于 $JAVA_HOME/jre/lib/ext 目錄下。開發(fā)者也可以把自己編寫的類打包成 jar 文件放入該目錄下；
最后還有一種，是動態(tài)加載遠程的 .class 文件。
既然有這么多種類的來源，那么在 Java 里，是由某一個具體的 ClassLoader 來統(tǒng)一加載呢？還是由多個 ClassLoader 來協(xié)作加載呢？
哪些 ClassLoader 負責加載上面幾類 Class？
實際上，針對上面四種來源的類，分別有不同的加載器負責加載。
首先，我們來看級別最高的 Java 核心類，即$JAVA_HOME/jre/lib 里的核心 jar 文件。這些類是 Java 運行的基礎(chǔ)類，由一個名為 BootstrapClassLoader 加載器負責加載，它也被稱作 根加載器／引導加載器。注意，BootstrapClassLoader 比較特殊，它不繼承 ClassLoader，而是由 JVM 內(nèi)部實現(xiàn)；
然后，需要加載 Java 核心擴展類，即 $JAVA_HOME/jre/lib/ext 目錄下的 jar 文件。這些文件由 ExtensionClassLoader 負責加載，它也被稱作 擴展類加載器。當然，用戶如果把自己開發(fā)的 jar 文件放在這個目錄，也會被 ExtClassLoader 加載；
接下來是開發(fā)者在項目中編寫的類，這些文件將由 AppClassLoader 加載器進行加載，它也被稱作 系統(tǒng)類加載器 System ClassLoader；
最后，如果想遠程加載如（本地文件／網(wǎng)絡(luò)下載）的方式，則必須要自己自定義一個 ClassLoader，復寫其中的 findClass() 方法才能得以實現(xiàn)。
因此能看出，Java 里提供了至少四類 ClassLoader 來分別加載不同來源的 Class。
那么，這幾種 ClassLoader 是如何協(xié)作來加載一個類呢？
這些 ClassLoader 以何種方式來協(xié)作加載 String 類呢？
String 類是 Java 自帶的最常用的一個類，現(xiàn)在的問題是，JVM 將以何種方式把 String class 加載進來呢？
我們來猜想下。
首先，String 類屬于 Java 核心類，位于 $JAVA_HOME/jre/lib 目錄下。有的朋友會馬上反應過來，上文中提過了，該目錄下的類會由 BootstrapClassLoader 進行加載。沒錯，它確實是由 BootstrapClassLoader 進行加載。但，這種回答的前提是你已經(jīng)知道了 String 在 $JAVA_HOME/jre/lib 目錄下。
那么，如果你并不知道 String 類究竟位于哪呢？或者我希望你去加載一個 unknown 的類呢？
有的朋友這時會說，那很簡單，只要去遍歷一遍所有的類，看看這個 unknown 的類位于哪里，然后再用對應的加載器去加載。
是的，思路很正確。那應該如何去遍歷呢？
比如，可以先遍歷用戶自己寫的類，如果找到了就用 AppClassLoader 去加載；否則去遍歷 Java 核心類目錄，找到了就用 BootstrapClassLoader 去加載，否則就去遍歷 Java 擴展類庫，依次類推。
這種思路方向是正確的，不過存在一個漏洞。
假如開發(fā)者自己偽造了一個 java.lang.String 類，即在項目中創(chuàng)建一個包java.lang，包內(nèi)創(chuàng)建一個名為 String 的類，這完全可以做到。那如果利用上面的遍歷方法，是不是這個項目中用到的 String 不是都變成了這個偽造的 java.lang.String 類嗎？如何解決這個問題呢？
解決方法很簡單，當查找一個類時，優(yōu)先遍歷最高級別的 Java 核心類，然后再去遍歷 Java 核心擴展類，最后再遍歷用戶自定義類，而且這個遍歷過程是一旦找到就立即停止遍歷。
在 Java 中，這種實現(xiàn)方式也稱作 雙親委托。其實很簡單，把 BootstrapClassLoader 想象為核心高層領(lǐng)導人， ExtClassLoader 想象為中層干部， AppClassLoader 想象為普通公務員。每次需要加載一個類，先獲取一個系統(tǒng)加載器 AppClassLoader 的實例（ClassLoader.getSystemClassLoader()），然后向上級層層請求，由最上級優(yōu)先去加載，如果上級覺得這些類不屬于核心類，就可以下放到各子級負責人去自行加載。
如下圖所示：
真的是按照雙親委托方式進行類加載嗎？
下面通過幾個例子來驗證上面的加載方式。
開發(fā)者自定義的類會被 AppClassLoader 加載嗎？
在項目中創(chuàng)建一個名為 MusicPlayer 的類文件，內(nèi)容如下：
然后來加載 MusicPlayer。
打印結(jié)果為：
可以驗證，MusicPlayer 是由 AppClassLoader 進行的加載。
驗證 AppClassLoader 的雙親真的是 ExtClassLoader 和 BootstrapClassLoader 嗎？
這時發(fā)現(xiàn) AppClassLoader 提供了一個 getParent() 的方法，來打印看看都是什么。
打印結(jié)果為：
首先能看到 ExtClassLoader 確實是 AppClassLoader 的雙親，不過卻沒有看到 BootstrapClassLoader。事實上，上文就提過， BootstrapClassLoader比較特殊，它是由 JVM 內(nèi)部實現(xiàn)的，所以 ExtClassLoader.getParent() = null。
如果把 MusicPlayer 類挪到 $JAVA_HOME/jre/lib/ext 目錄下會發(fā)生什么？
上文中說了，ExtClassLoader 會加載$JAVA_HOME/jre/lib/ext 目錄下所有的 jar 文件。那來嘗試下直接把 MusicPlayer 這個類放到 $JAVA_HOME/jre/lib/ext 目錄下吧。
利用下面命令可以把 MusicPlayer.java 編譯打包成 jar 文件，并放置到對應目錄。
這時 MusicPlayer.jar 已經(jīng)被放置與 $JAVA_HOME/jre/lib/ext 目錄下，同時把之前的 MusicPlayer 刪除，而且這一次刻意使用 AppClassLoader 來加載：
打印結(jié)果為：
說明即使直接用 AppClassLoader 去加載，它仍然會被 ExtClassLoader 加載到。
從源碼角度真正理解雙親委托加載機制
上面已經(jīng)通過一些例子了解了雙親委托的一些特性了，下面來看一下它的實現(xiàn)代碼，加深理解。
打開 ClassLoader 里的 loadClass() 方法，便是需要分析的源碼了。這個方法里做了下面幾件事：
檢查目標class是否曾經(jīng)加載過，如果加載過則直接返回；
如果沒加載過，把加載請求傳遞給 parent 加載器去加載；
如果 parent 加載器加載成功，則直接返回；
如果 parent 未加載到，則自身調(diào)用 findClass() 方法進行尋找，并把尋找結(jié)果返回。
代碼如下：
看完實現(xiàn)源碼相信能夠有更完整的理解。
類加載器最酷的一面：自定義類加載器
前面提到了 Java 自帶的加載器 BootstrapClassLoader、AppClassLoader和ExtClassLoader，這些都是 Java 已經(jīng)提供好的。
而真正有意思的，是 自定義類加載器，它允許我們在運行時可以從本地磁盤或網(wǎng)絡(luò)上動態(tài)加載自定義類。這使得開發(fā)者可以動態(tài)修復某些有問題的類，熱更新代碼。
下面來實現(xiàn)一個網(wǎng)絡(luò)類加載器，這個加載器可以從網(wǎng)絡(luò)上動態(tài)下載 .class 文件并加載到虛擬機中使用。
后面我還會寫作與 熱修復／動態(tài)更新 相關(guān)的文章，這里先學習 Java 層 NetworkClassLoader 相關(guān)的原理。
作為一個 NetworkClassLoader，它首先要繼承 ClassLoader；
然后它要實現(xiàn)ClassLoader內(nèi)的 findClass() 方法。注意，不是loadClass()方法，因為ClassLoader提供了loadClass()（如上面的源碼），它會基于雙親委托機制去搜索某個 class，直到搜索不到才會調(diào)用自身的findClass()，如果直接復寫loadClass()，那還要實現(xiàn)雙親委托機制；
在 findClass() 方法里，要從網(wǎng)絡(luò)上下載一個 .class 文件，然后轉(zhuǎn)化成 Class 對象供虛擬機使用。
具體實現(xiàn)代碼如下：
這個類的作用是從網(wǎng)絡(luò)上（這里是本人的 local apache 服務器 http://localhost/java 上）目錄里去下載對應的 .class 文件，并轉(zhuǎn)換成 Class<?> 返回回去使用。
下面我們來利用這個 NetworkClassLoader 去加載 localhost 上的 MusicPlayer 類：
首先把 MusicPlayer.class 放置于 /Library/WebServer/Documents/java （MacOS）目錄下，由于 MacOS 自帶 apache 服務器，這里是服務器的默認目錄；
執(zhí)行下面一段代碼：
正常運行，加載 http://localhost/java/classloader/MusicPlayer.class成功。
可以看出 NetworkClassLoader 可以正常工作，如果讀者要用的話，只要稍微修改 url 的拼接方式即可自行使用。
小結(jié)
類加載方式是 Java 上非常創(chuàng)新的一項技術(shù)，給未來的熱修復技術(shù)提供了可能。本文力求通過簡單的語言和合適的例子來講解其中雙親委托機制、自定義加載器等，并開發(fā)了自定義的NetworkClassLoader。
當然，類加載是很有意思的技術(shù)，很難覆蓋所有知識點，比如不同類加載器加載同一個類，得到的實例卻不是同一個等等。
