老大難的 Java ClassLoader，到了該徹底理解它的時候了

ClassLoader 是 Java 屆最為神秘的技術之一，無數人被它傷透了腦筋，摸不清門道究竟在哪裡。網上的文章也是一篇又一篇，經過本人的親自鑑定，絕大部分內容都是在誤導別人。本文我帶讀者徹底吃透 ClassLoader，以後其它的相關文章你們可以不必再細看了。

ClassLoader 做什麼的？

顧名思義，它是用來載入 Class 的。它負責將 Class 的位元組碼形式轉換成記憶體形式的 Class 物件。位元組碼可以來自於磁碟檔案 *.class，也可以是 jar 包裡的 *.class，也可以來自遠端伺服器提供的位元組流，位元組碼的本質就是一個位元組陣列 []byte，它有特定的複雜的內部格式。

有很多位元組碼加密技術就是依靠定製 ClassLoader 來實現的。先使用工具對位元組碼檔案進行加密，執行時使用定製的 ClassLoader 先解密檔案內容再載入這些解密後的位元組碼。

每個 Class 物件的內部都有一個 classLoader 欄位來標識自己是由哪個 ClassLoader 載入的。

class Class<T> {
  ...
  private final ClassLoader classLoader;
  ...
}

延遲載入

JVM 執行並不是一次性載入所需要的全部類的，它是按需載入，也就是延遲載入。程式在執行的過程中會逐漸遇到很多不認識的新類，這時候就會呼叫 ClassLoader 來載入這些類。載入完成後就會將 Class 物件存在 ClassLoader 裡面，下次就不需要重新載入了。

比如你在呼叫某個類的靜態方法時，首先這個類肯定是需要被載入的，但是並不會觸及這個類的例項欄位，那麼例項欄位的類別 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 都是 URLClassLoader 的子類，它們都是從本地檔案系統里載入類庫。

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);

雙親委派規則可能會變成三親委派，四親委派，取決於你使用的父載入器是誰，它會一直遞迴委派到根載入器。

Class.forName vs ClassLoader.loadClass

這兩個方法都可以用來載入目標類，它們之間有一個小小的區別，那就是 Class.forName() 方法可以獲取原生型別的 Class，而 ClassLoader.loadClass() 則會報錯。

Class<?> x = Class.forName("[I");
System.out.println(x);

x = ClassLoader.getSystemClassLoader().loadClass("[I");
System.out.println(x);

---------------------
class [I

Exception in thread "main" java.lang.ClassNotFoundException: [I
...

鑽石依賴

專案管理上有一個著名的概念叫著「鑽石依賴」，是指軟體依賴導致同一個軟體包的兩個版本需要共存而不能衝突。

我們平時使用的 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)

我們還可以讓兩個不同版本的 Dep 類實現同一個介面，這樣可以避免使用反射的方式來呼叫 Dep 類裡面的方法。

Class<?> depv1Class = v1.loadClass("Dep");
IPrint depv1 = (IPrint)depv1Class.getConstructor().newInstance();
depv1.print()

ClassLoader 固然可以解決依賴衝突問題，不過它也限制了不同軟體包的操作介面必須使用反射或介面的方式進行動態呼叫。Maven 沒有這種限制，它依賴於虛擬機器的預設懶惰載入策略，執行過程中如果沒有顯示使用定製的 ClassLoader，那麼從頭到尾都是在使用 AppClassLoader，而不同版本的同名類必須使用不同的 ClassLoader 載入，所以 Maven 不能完美解決鑽石依賴。

如果你想知道有沒有開源的包管理工具可以解決鑽石依賴的，我推薦你瞭解一下 sofa-ark，它是螞蟻金服開源的輕量級類隔離框架。

分工與合作

這裡我們重新理解一下 ClassLoader 的意義，它相當於類的名稱空間，起到了類隔離的作用。位於同一個 ClassLoader 裡面的類名是唯一的，不同的 ClassLoader 可以持有同名的類。ClassLoader 是類名稱的容器，是類的沙箱。

不同的 ClassLoader 之間也會有合作，它們之間的合作是透過 parent 屬性和雙親委派機制來完成的。parent 具有更高的載入優先順序。除此之外，parent 還表達了一種共享關係，當多個子 ClassLoader 共享同一個 parent 時，那麼這個 parent 裡面包含的類可以認為是所有子 ClassLoader 共享的。這也是為什麼 BootstrapClassLoader 被所有的類載入器視為祖先載入器，JVM 核心類庫自然應該被共享。

Thread.contextClassLoader

如果你稍微閱讀過 Thread 的原始碼，你會在它的例項欄位中發現有一個欄位非常特別

class Thread {
  ...
  private ClassLoader contextClassLoader;

  public ClassLoader getContextClassLoader() {
    return contextClassLoader;
  }

  public void setContextClassLoader(ClassLoader cl) {
    this.contextClassLoader = cl;
  }
  ...
}

contextClassLoader「執行緒上下文類載入器」，這究竟是什麼東西？

首先 contextClassLoader 是那種需要顯示使用的類載入器，如果你沒有顯示使用它，也就永遠不會在任何地方用到它。你可以使用下面這種方式來顯示使用它

Thread.currentThread().getContextClassLoader().loadClass(name);

這意味著如果你使用 forName(string name) 方法載入目標類，它不會自動使用 contextClassLoader。那些因為程式碼上的依賴關係而懶惰載入的類也不會自動使用 contextClassLoader來載入。

其次執行緒的 contextClassLoader 是從父執行緒那裡繼承過來的，所謂父執行緒就是建立了當前執行緒的執行緒。程式啟動時的 main 執行緒的 contextClassLoader 就是 AppClassLoader。這意味著如果沒有人工去設定，那麼所有的執行緒的 contextClassLoader 都是 AppClassLoader。

那這個 contextClassLoader 究竟是做什麼用的？我們要使用前面提到了類載入器分工與合作的原理來解釋它的用途。

它可以做到跨執行緒共享類，只要它們共享同一個 contextClassLoader。父子執行緒之間會自動傳遞 contextClassLoader，所以共享起來將是自動化的。

如果不同的執行緒使用不同的 contextClassLoader，那麼不同的執行緒使用的類就可以隔離開來。

如果我們對業務進行劃分，不同的業務使用不同的執行緒池，執行緒池內部共享同一個 contextClassLoader，執行緒池之間使用不同的 contextClassLoader，就可以很好的起到隔離保護的作用，避免類版本衝突。

如果我們不去定製 contextClassLoader，那麼所有的執行緒將會預設使用 AppClassLoader，所有的類都將會是共享的。

執行緒的 contextClassLoader 使用場合比較罕見，如果上面的邏輯晦澀難懂也不必過於計較。

JDK9 增加了模組功能之後對類載入器的結構設計做了一定程度的修改，不過類載入器的原理還是類似的，作為類的容器，它起到類隔離的作用，同時還需要依靠雙親委派機制來建立不同的類載入器之間的合作關係。