本文首發於個人網站，如需轉載請注明來源：類加載器中的雙親委派模型，看這篇就夠了
在上一篇文章中，我們梳理了類加載器的基本概念：類的生命周期、類加載器的作用、類的加載和卸載的時機等等，這篇文章我們接着前文繼續復習類加載器的知識，主要包括：JVM中有哪些類加載器？它們之間是什么關系？什么是雙親委派機制？
雙親委派模型
四種類加載器
從JVM的角度看，類加載器主要有兩類：Bootstrap ClassLoader和其他類加載，Bootstrap ClassLoader是C++語言實現，是虛擬機自身的一部分；其他類加載器都是Java語言實現，不屬於虛擬機，全部繼承自抽象類java.lang.ClassLoader。
從Java開發者的角度看，需要了解類加載器的雙親委派模型，如下圖所示：
-
Bootstrap ClassLoader：啟動類加載器，這個類加載器將負責存放在<JAVA_HOME>/lib目錄中、被-Xbootclasspath參數所指定的路徑中，並且是虛擬機會識別的jar類庫加載到內存中。更直白點說，就是我們常用的java.lang開頭的那些類，一定是被Bootstrap ClassLoader加載的。
-
Extension ClassLoader：擴展類加載器，這個類加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載<JAVA_HONME>/lib/ext目錄中的、或者被java.ext.dirs系統變量指定的路徑中的所有類庫。
-
Application ClassLoader：應用程序類加載器，這個類加載器由sun.misc.Launcher$AppClassLoader實現，它負責加載用戶CLASSPATH環境變量指定的路徑中的所有類庫。如果應用程序中沒有自定義過自己的類加載器，這個就是一個Java程序中默認的類加載器。
-
用戶自定義的類加載器：用戶在需要的情況下，可以實現自己的自定義類加載器，一般而言，在以下幾種情況下需要自定義類加載器：（1）隔離加載類。某些框架為了實現中間件和應用程序的模塊的隔離，就需要中間件和應用程序使用不同的類加載器；（2）修改類加載的方式。類加載的雙親委派模型並不是強制的，用戶可以根據需要在某個時間點動態加載類；（3）擴展類加載源，例如從數據庫、網絡進行類加載；（4）防止源代碼泄露。Java代碼很容易被反編譯和篡改，為了防止源碼泄露，可以對類的字節碼文件進行加密，並編寫自定義的類加載器來加載自己的應用程序的類。
例子1：不同的類加載器
在下面的代碼中，java.util.HashMap是rt.jar包中的類，因此它的類加載器是null，DNSNameService類是放在ext目錄下的jar包中的類，因此它的類加載器是ExtClassLoader；MyClassLoaderTest的類加載器就是應用類加載器。
import java.util.HashMap;
import sun.net.spi.nameservice.dns.DNSNameService;
public class MyClassLoaderTest {
public static void main(String[] args) {
System.out.println("class loader for HashMap: " + HashMap.class.getClassLoader());
System.out.println(
"class loader for DNSNameService: " + DNSNameService.class.getClassLoader());
System.out.println("class loader for this class: " + MyClassLoaderTest.class.getClassLoader());
System.out.println("class loader for Blob class: " + com.mysql.jdbc.Blob.class.getClassLoader());
}
}
運行上述代碼的接入過下圖所示：
例子2：不同類加載器管理的文件路徑
通過下面的這個程序，可以看到，每個類加載器負責的jar文件路徑都不一樣：
public class JVMClassLoader {
public static void main(String[] args) {
System.out.println("引導類加載器加載路徑：" + System.getProperty("sun.boot.class.path"));
System.out.println("擴展類加載器加載路徑：" + System.getProperty("java.ext.dirs"));
System.out.println("系統類加載器加載路徑：" + System.getProperty("java.class.path"));
}
}
例子3：Arthas中的classloader命令
Arthas中提供了classloader命令，可以用來查看當前應用中的類加載器相關的統計信息，如下圖所示，
- 輸入classloader后展示的表格匯總了當前應用的類加載器、每個類加載器的實例個數、每個類加載器加載的類的個數。
- 輸入classloader -t后，展示了當前應用中類加載器的層次結構，可以看出，BootStrap ClassLoader確實在類加載器體系的頂層，接下來是擴展類加載器，再然后是應用類加載器，這里還有一個ArthasClassLoader，是Arthas自己實現的一個自定義類加載器。
雙親委派模型的工作過程
如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去加載。
使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是Java類隨着它的類加載器一起具備了一種帶有優先級的層次關系。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處於模型最頂端的啟動類加載器進行加載，因此Object類在程序的各種類加載器環境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己編寫了一個稱為java.lang.Object的類，並放在程序的Class Path中，那系統中將會出現多個不同的Object類，Java類型體系中最基礎的行為也就無法保證，應用程序也將會變得一片混亂。
雙親委派模型的實現非常簡單，實現雙親委派的代碼在java.lang.ClassLoader的loadClass()方法之中，如下面的代碼所示：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，檢查該類是否已經被加載
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，
// 說明父類加載器無法完成加載請求
}
if (c == null) {
// 在父類加載器無法加載的時候，再調用本類的findClass方法進行類加載請求
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
// 當前類加載器是該類的define class loader
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
破壞雙親委派模型
線程上下文加載器
如上所述，雙親委派模型很好得解決了各個類加載器的基礎類的統一問題（越基礎的類由越上層的加載器進行加載），如果基礎類又要回調用戶的類該怎么辦？一個非常經典的例子就是SQL的驅動管理類——java.sql.DriverManager。
java.sql.DriverManager是Java的標准服務，該類放在rt.jar中，因此是由啟動類加載器加載的，但是在應用啟動的時候，該驅動類管理是需要加載由不同數據庫廠商實現的驅動，但是啟動類加載器找不到這些具體的實現類，為了解決這個問題，Java設計團隊提供了一個不太優雅的設計：線程上下文加載器（Thread Context ClassLoader）。這個類加載器可以通過java.lang.Thread類的setContextClassLoader()方法進行設置，如果創建線程時候它還沒有被設置，就會從父線程中繼承一個，如果再應用程序的全局范圍都沒有設置過的話，那這個類加載器就是應用程序類加載器。
有了線程上下文加載器，就可以解決上面的問題——父類加載器需要請求子類加載器完成類加載的動作，這種行為實際上就是打破了雙親委派的加載規則。
源碼分析
接下來，我們以java.sql.DriverManager為例，看下線程上下文加載器的用法，在java.sql.DriverManager類的下面這個靜態塊中，是JDBC驅動加載的入口。
/**
* Load the initial JDBC drivers by checking the System property
* jdbc.properties and then use the {@code ServiceLoader} mechanism
*/
static {
loadInitialDrivers();
println("JDBC DriverManager initialized");
}
順着loadInitialDrivers()方法往下看，使用線程上下文加載器的地方在ServiceLoader.load里
private static void loadInitialDrivers() {
// ……省去別的代碼
AccessController.doPrivileged(new PrivilegedAction<Void>() {
public Void run() {
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();
try{
while(driversIterator.hasNext()) {
driversIterator.next();
}
} catch(Throwable t) {
// Do nothing
}
return null;
}
});
//…… 省去別的代碼
ServiceLoader.load方法的代碼如下，JDBC的sqlDriverManager就是這里獲得的上下文加載器來驅動用戶代碼加載指定的類的。
public static <S> ServiceLoader<S> load(Class<S> service) {
// 獲取當前線程中的上下文類加載器
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
那么這個上下文加載器是什么時候設置進去的呢？前面我們提到了：
這個類加載器可以通過java.lang.Thread類的setContextClassLoader()方法進行設置，如果創建線程時候它還沒有被設置，就會從父線程中繼承一個，如果再應用程序的全局范圍都沒有設置過的話，那這個類加載器就是應用程序類加載器。
看下setContextClassLoader()方法別誰調用了，最終我們在Launcher中找到了如下代碼：
public class Launcher {
//……省去別的代碼
public Launcher() {
Launcher.ExtClassLoader var1;
try {
var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
throw new InternalError("Could not create extension class loader", var10);
}
try {
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
throw new InternalError("Could not create application class loader", var9);
}
Thread.currentThread().setContextClassLoader(this.loader);
//……省去別的代碼
}
}
總結
這篇文章我們復習了類加載器的雙親委派模型、雙親委派模型的工作過程，以及打破雙親委派模型的必要性和源碼分析。在第一部分的結尾，我們還演示了Arthas中關於類加載器的命令的用法，在實際排查問題時可以考慮使用。
參考資料
- https://www.journaldev.com/349/java-classloader#java-classloader-hierarchy
- https://www.cnblogs.com/joemsu/p/9310226.html
- 《深入理解Java虛擬機》
- 《碼出高效Java開發手冊》
本號專注於后端技術、JVM問題排查和優化、Java面試題、個人成長和自我管理等主題，為讀者提供一線開發者的工作和成長經驗，期待你能在這里有所收獲。