理解Java ClassLoader
ClassLoader是Java最為神祕的技術之一，無數人被它傷透了腦筋，摸不清門道究竟在哪裡。網上的文章也是一篇又一篇，經過本人的親自鑑定，絕大部分內容都是在誤導別人。本文我帶讀者徹底吃透 ClassLoader，以後其它的相關文章你們可以不必再細看了。
ClassLoader 做什麼的？
顧名思義，它是用來載入 Class 的。它負責將 Class 的位元組碼形式轉換成記憶體形式的 Class 物件。位元組碼可以來自於磁碟檔案 *.class，也可以是 jar 包裡的 *.class，也可以來自遠端伺服器提供的位元組流，位元組碼的本質就是一個位元組陣列 []byte，它有特定的複雜的內部格式。
有很多位元組碼加密技術就是依靠定製 ClassLoader 來實現的。先使用工具對位元組碼檔案進行加密，執行時使用定製的 ClassLoader 先解密檔案內容再載入這些解密後的位元組碼。
每個== Class 物件的內部都有一個 classLoader 欄位來標識自己是由哪個 ClassLoader 載入的==。ClassLoader 就像一個容器，裡面裝了很多已經載入的 Class 物件。
class Class<T> {
...
private final ClassLoader classLoader;
...
}
延遲載入
JVM 執行並不是一次性載入所需要的全部類的，它是按需載入，也就是延遲載入
比如你在呼叫某個類的靜態方法時，首先這個類肯定是需要被載入的，但是並不會觸及這個類的例項欄位，那麼例項欄位的類別 Class 就可以暫時不必去載入，但是它可能會載入靜態欄位相關的類別，因為靜態方法會訪問靜態欄位。而例項欄位的類別需要等到你例項化物件的時候才可能會載入。
各司其職
JVM 執行例項中會存在多個 ClassLoader，不同的 ClassLoader 會從不同的地方載入位元組碼檔案。它可以從不同的檔案目錄載入，也可以從不同的 jar 檔案中載入，也可以從網路上不同的服務地址來載入。
JVM中內建了三個重要的ClassLoader，分別是BootstrapClassLoader、ExtensionClassLoader和AppClassLoader。
BootstrapClassLoader 負責載入 JVM 執行時核心類，這些類位於 JAVA_HOME/lib/rt.jar 檔案中，我們常用內建庫 java.xxx.* 都在裡面，比如 java.util.、java.io.、java.nio.、java.lang. 等等。這個 ClassLoader 比較特殊，它是由 C 程式碼實現的，我們將它稱之為「根載入器」。
ExtensionClassLoader 負責載入 JVM 擴充套件類，比如 swing 系列、內建的 js 引擎、xml 解析器 等等，這些庫名通常以 javax 開頭，它們的 jar 包位於 JAVA_HOME/lib/ext/*.jar 中，有很多 jar 包。
AppClassLoader 才是直接面向我們使用者的載入器，它會載入 Classpath 環境變數裡定義的路徑中的 jar 包和目錄。我們自己編寫的程式碼以及使用的第三方 jar 包通常都是由它來載入的。
那些位於網路上靜態檔案伺服器提供的 jar 包和 class檔案，jdk 內建了一個 URLClassLoader，使用者只需要傳遞規範的網路路徑給構造器，就可以使用 URLClassLoader 來載入遠端類庫了。URLClassLoader 不但可以載入遠端類庫，還可以載入本地路徑的類庫，取決於構造器中不同的地址形式。ExtensionClassLoader 和 AppClassLoader 都是從本地檔案系統里加載類庫。
AppClassLoader 可以由 ClassLoader 類提供的靜態方法 getSystemClassLoader() 得到，它就是我們所說的「系統類載入器」，我們使用者平時編寫的類程式碼通常都是由它載入的。當我們的 main 方法執行的時候，這第一個使用者類的載入器就是 AppClassLoader。
ClassLoader 傳遞性
程式在執行過程中，遇到了一個未知的類，它會選擇由哪個 ClassLoader 來載入它呢？虛擬機器的策略是使用呼叫者 Class 物件的 ClassLoader 來載入當前未知的類。何為呼叫者 Class 物件？就是在遇到這個未知的類時，虛擬機器肯定正在執行一個方法呼叫（靜態方法或者例項方法），這個方法掛在哪個類上面，那這個類就是呼叫者 Class 物件。前面我們提到每個 Class 物件裡面都有一個 classLoader 屬性記錄了當前的類是由誰來載入的。
因為 ClassLoader 的傳遞性，所有延遲載入的類都會由初始呼叫 main 方法的這個 ClassLoader 全權負責，它就是 AppClassLoader。
雙親委派機制
前面我們提到 AppClassLoader 只負責載入 Classpath 下面的類庫，如果遇到沒有載入的系統類庫怎麼辦，AppClassLoader 必須將系統類庫的載入工作交給 BootstrapClassLoader 和 ExtensionClassLoader 來做，這就是我們常說的「雙親委派」。
AppClassLoader 在載入一個未知的類名時，它並不是立即去搜尋 Classpath，它會首先將這個類名稱交給 ExtensionClassLoader 來載入，如果 ExtensionClassLoader 可以載入，那麼 AppClassLoader 就不用麻煩了。否則它就會搜尋 Classpath 。
而 ExtensionClassLoader 在載入一個未知的類名時，它也並不是立即搜尋 ext 路徑，它會首先將類名稱交給 BootstrapClassLoader 來載入，如果 BootstrapClassLoader 可以載入，那麼 ExtensionClassLoader 也就不用麻煩了。否則它就會搜尋 ext 路徑下的 jar 包。
這三個 ClassLoader 之間形成了級聯的父子關係，每個 ClassLoader 都很懶，儘量把工作交給父親做，父親幹不了了自己才會幹。每個 ClassLoader 物件內部都會有一個 parent 屬性指向它的父載入器。
class ClassLoader {
...
private final ClassLoader parent;
...
}
值得注意的是圖中的 ExtensionClassLoader 的 parent 指標畫了虛線，這是因為它的parent的值是null，當parent 欄位是null 時就表示它的父載入器是「根載入器」。如果某個Class物件的 classLoader 屬性值是null，那麼就表示這個類也是「根載入器」載入的。
Class.forName方法
當我們在使用 jdbc驅動時，經常會使用 Class.forName 方法來動態載入驅動類。
Class.forName("com.mysql.cj.jdbc.Driver");
其原理是mysql驅動的Driver類裡有一個靜態程式碼塊，它會在Driver 類被載入的時候執行。這個靜態程式碼塊會將mysql驅動例項註冊到全域性的jdbc驅動管理器裡。
class Driver {
static {
try {
java.sql.DriverManager.registerDriver(new Driver());
} catch (SQLException E) {
throw new RuntimeException("Can't register driver!");
}
}
...
}
forName 方法同樣也是使用呼叫者 Class 物件的 ClassLoader 來載入目標類。不過 forName 還提供了多引數版本，可以指定使用哪個ClassLoader 來載入：
Class<?> forName(String name, boolean initialize, ClassLoader cl)
通過這種形式的 forName方法可以突破內建載入器的限制，通過使用自定義類載入器允許我們自由載入其它任意來源的類庫。根據ClassLoader的傳遞性，目標類庫傳遞引用到的其它類庫也將會使用自定義載入器載入。
自定義類載入器
ClassLoader 裡面有三個重要的方法 loadClass()、findClass() 和 defineClass()。
loadClass() 方法是載入目標類的入口，它首先會查詢當前 ClassLoader 以及它的雙親裡面是否已經載入了目標類，如果沒有找到就會讓雙親嘗試載入，如果雙親都載入不了，就會呼叫 findClass() 讓自定義載入器自己來載入目標類。ClassLoader 的 findClass() 方法是需要子類來覆蓋的，不同的載入器將使用不同的邏輯來獲取目標類的位元組碼。拿到這個位元組碼之後再呼叫 defineClass() 方法將位元組碼轉換成 Class 物件。下面我使用偽程式碼表示一下基本過程：
class ClassLoader {
// 載入入口，定義了雙親委派規則
Class loadClass(String name) {
// 是否已經載入了
Class t = this.findFromLoaded(name);
if(t == null) {
// 交給雙親
t = this.parent.loadClass(name)
}
if(t == null) {
// 雙親都不行，只能靠自己了
t = this.findClass(name);
}
return t;
}
// 交給子類自己去實現
Class findClass(String name) {
throw ClassNotFoundException();
}
// 組裝Class物件
Class defineClass(byte[] code, String name) {
return buildClassFromCode(code, name);
}
}
class CustomClassLoader extends ClassLoader {
Class findClass(String name) {
// 尋找位元組碼
byte[] code = findCodeFromSomewhere(name);
// 組裝Class物件
return this.defineClass(code, name);
}
}
自定義類載入器不易破壞雙親委派規則，不要輕易覆蓋 loadClass 方法。否則可能會導致自定義載入器無法載入內建的核心類庫。在使用自定義載入器時，要明確好它的父載入器是誰，將父載入器通過子類的構造器傳入。如果父類載入器是 null，那就表示父載入器是「根載入器」。
/ ClassLoader 構造器
protected ClassLoader(String name, ClassLoader parent);
雙親委派規則可能會變成三親委派，四親委派，取決於你使用的父載入器是誰，它會一直遞迴委派到根載入器。
鑽石依賴
專案管理上有一個著名的概念叫著「鑽石依賴」，是指軟體依賴導致同一個軟體包的兩個版本需要共存而不能衝突。
我們平時使用的 maven 是這樣解決鑽石依賴的，它會從多個衝突的版本中選擇一個來使用，如果不同的版本之間相容性很糟糕，那麼程式將無法正常編譯執行。Maven 這種形式叫「扁平化」依賴管理。
使用 ClassLoader 可以解決鑽石依賴問題。不同版本的軟體包使用不同的 ClassLoader 來載入，位於不同 ClassLoader 中名稱一樣的類實際上是不同的類。下面讓我們使用 URLClassLoader 來嘗試一個簡單的例子，它預設的父載入器是 AppClassLoader
$ cat ~/source/jcl/v1/Dep.java
public class Dep {
public void print() {
System.out.println("v1");
}
}
$ cat ~/source/jcl/v2/Dep.java
public class Dep {
public void print() {
System.out.println("v1");
}
}
$ cat ~/source/jcl/Test.java
public class Test {
public static void main(String[] args) throws Exception {
String v1dir = "file:///Users/qianwp/source/jcl/v1/";
String v2dir = "file:///Users/qianwp/source/jcl/v2/";
URLClassLoader v1 = new URLClassLoader(new URL[]{new URL(v1dir)});
URLClassLoader v2 = new URLClassLoader(new URL[]{new URL(v2dir)});
Class<?> depv1Class = v1.loadClass("Dep");
Object depv1 = depv1Class.getConstructor().newInstance();
depv1Class.getMethod("print").invoke(depv1);
Class<?> depv2Class = v2.loadClass("Dep");
Object depv2 = depv2Class.getConstructor().newInstance();
depv2Class.getMethod("print").invoke(depv2);
System.out.println(depv1Class.equals(depv2Class));
}
}
在執行之前，我們需要對依賴的類庫進行編譯
$ cd ~/source/jcl/v1
$ javac Dep.java
$ cd ~/source/jcl/v2
$ javac Dep.java
$ cd ~/source/jcl
$ javac Test.java
$ java Test
v1
v2
false
在這個例子中即使兩個 URLClassLoader 指向的路徑是一樣的，下面這個表示式還是 false，因為即使是同樣的位元組碼用不同的 ClassLoader 加載出來的類都不能算同一個類。
depv1Class.equals(depv2Class)
ClassLoader 固然可以解決依賴衝突問題，不過它也限制了不同軟體包的操作介面必須使用反射或介面的方式進行動態呼叫。Maven 沒有這種限制，它依賴於虛擬機器的預設懶惰載入策略，執行過程中如果沒有顯示使用定製的 ClassLoader，那麼從頭到尾都是在使用 AppClassLoader，而不同版本的同名類必須使用不同的 ClassLoader 載入，所以 Maven 不能完美解決鑽石依賴。
如果你想知道有沒有開源的包管理工具可以解決鑽石依賴的，我推薦你瞭解一下 sofa-ark，它是螞蟻金服開源的輕量級類隔離框架。
分工與合作
這裡我們重新理解一下== ClassLoader 的意義，它相當於類的名稱空間，起到了類隔離的作用==。位於同一個 ClassLoader 裡面的類名是唯一的，不同的 ClassLoader 可以持有同名的類。ClassLoader 是類名稱的容器，是類的沙箱。
不同的 ClassLoader 之間也會有合作，它們之間的合作是通過 parent 屬性和雙親委派機制來完成的。parent 具有更高的載入優先順序。除此之外，parent 還表達了一種共享關係，當多個子 ClassLoader 共享同一個 parent 時，那麼這個 parent 裡面包含的類可以認為是所有子 ClassLoader 共享的。這也是為什麼 BootstrapClassLoader 被所有的類載入器視為祖先載入器，JVM 核心類庫自然應該被共享。
JDK9 增加了模組功能之後對類載入器的結構設計做了一定程度的修改，不過類載入器的原理還是類似的，作為類的容器，它起到類隔離的作用，同時還需要依靠雙親委派機制來建立不同的類載入器之間的合作關係。