Java ClassLoader機制分析

時間 2019-11-17

原文原文鏈接

1、問題引出：

你們都知道，當咱們寫好一個Java程序以後，都是須要通過編譯成若干個.class文件組織而成的一個完整的Java應用程序，當程序在運行時，即會調用該程序的一個入口函數來調用系統的相關功能，而這些功能都被封裝在不一樣的class文件當中，因此常常要從這個class文件中要調用另一個class文件中的方法，若是另一個文件不存在的，則會引起系統異常。而程序在啓動的時候，並不會一次性加載程序所要用的全部class文件，而是根據程序的須要，經過Java的類加載機制（ClassLoader）來動態加載某個class文件到內存當中的，從而只有class文件被載入到了內存以後，才能被其它class所引用。因此ClassLoader就是用來動態加載class文件到內存當中用的。html

2、ClassLoader機制分析：

類加載器是 Java 語言的一個創新，也是 Java 語言流行的重要緣由之一。它使得 Java 類能夠被動態加載到 Java 虛擬機中並執行。類加載器從 JDK 1.0 就出現了，最初是爲了知足 Java Applet 的須要而開發出來的。Java Applet 須要從遠程下載 Java 類文件到瀏覽器中並執行。如今類加載器在 Web 容器和 OSGi 中獲得了普遍的使用。通常來講，Java 應用的開發人員不須要直接同類加載器進行交互。Java 虛擬機默認的行爲就已經足夠知足大多數狀況的需求了。不過若是遇到了須要與類加載器進行交互的狀況，而對類加載器的機制又不是很瞭解的話，就很容易花大量的時間去調試 ClassNotFoundException和 NoClassDefFoundError等異常。本文將詳細介紹 Java 的類加載器，幫助讀者深入理解 Java 語言中的這個重要概念。下面首先介紹一些相關的基本概念。java

類加載器基本概念

顧名思義，類加載器（class loader）用來加載 Java 類到 Java 虛擬機中。通常來講，Java 虛擬機使用 Java 類的方式以下：Java 源程序（.java 文件）在通過 Java 編譯器編譯以後就被轉換成 Java 字節代碼（.class 文件）。類加載器負責讀取 Java 字節代碼，並轉換成 java.lang.Class類的一個實例。每一個這樣的實例用來表示一個 Java 類。經過此實例的 newInstance()方法就能夠建立出該類的一個對象。實際的狀況可能更加複雜，好比 Java 字節代碼多是經過工具動態生成的，也多是經過網絡下載的。算法

一、ClassLoader分類：

Java 應用環境中不一樣的class 分別由不一樣的ClassLoader 進行加載，以下：api

一個jvm中默認的classloader有Bootstrap ClassLoader、Extension ClassLoader、App ClassLoader，分別各司其職，除此以外，用戶還能夠自定義ClassLoader，具體以下：瀏覽器

1.一、BootStrap ClassLoader

稱爲啓動類加載器，是Java類加載層次中最頂層的類加載器，負責加載JDK中的核心類庫，如：rt.jar、resources.jar、charsets.jar等，可經過以下程序得到該類加載器從哪些地方加載了相關的jar或class文件，因爲JVM會自動加載這些jar包，因此這些jar包不用在classpath中指定。緩存

package com.jason.classload;
import java.net.URL;
/**
 * Created by jason on 2017/11/30.
 */
public class TestBootStrapClassLoader {
    public static void main(String[] args) {
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (int i = 0; i < urls.length; i++) {
            System.out.println(urls[i].toExternalForm());
        }
        System.out.println(System.getProperty("sun.boot.class.path"));
        System.out.println(System.getProperty("java.class.path"));
        System.out.println(System.getProperty("java.ext.dirs"));
    }
}

打印結果以下：tomcat

file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/classes安全

從結果中，能夠看到，該類加載器加載了jdk中的java基礎類，主要是 %JRE_HOME/lib/ 目錄下的rt.jar、resources.jar、charsets.jar等核心類庫的jar，另外還有classess。所以該結果也能夠經過查找sun.boot.class.path這個系統屬性所得知，代碼在前面已經貼出來，獲得的結果以下：網絡

/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/rt.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/sunrsasign.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/jre/classesapp

1.二、Extension ClassLoader

負責加載java擴展類，主要是 %JRE_HOME/lib/ext 目錄下的或者或者由java.ext.dirs系統屬性指定的jar和class

1.三、App（System） ClassLoader

稱爲應用（也稱爲系統）類加載器，負責加載應用程序classpath目錄下的全部jar和class文件。它負責在JVM被啓動時，加載來自在命令java中的-classpath或者java.class.path系統屬性或者 CLASSPATH操做系統屬性所指定的JAR類包和類路徑。總能經過靜態方法ClassLoader.getSystemClassLoader()找到該類加載器。若是沒有特別指定，則用戶自定義的任何類加載器都將該類加載器做爲它的父加載器。所以該結果也能夠經過查找java.class.path這個系統屬性所得知，代碼在前面已經貼出來，輸出結果則爲用戶在系統屬性裏面設置的CLASSPATH。

1.四、用戶自定義ClassLoader

除了Java默認提供的三個ClassLoader以外，用戶還能夠根據須要定義自已的ClassLoader，而這些自定義的ClassLoader都必須繼承自java.lang.ClassLoader類，並重寫父類的findClass方法。

二、ClassLoader之間的關係與啓動順序

其中Bootstrap ClassLoader是JVM級別的，不繼承自ClassLoader，由於它不是一個普通的Java類，底層由C++撰寫，已嵌入到了JVM內核當中，當JVM啓動後，Bootstrap ClassLoader也隨着啓動，負責加載完核心類庫後，而後初始化sun.misc.Launcher ，sun.misc.Launcher構造並初始化Extension ClassLoader、App ClassLoader類加載器。Extension ClassLoader、App ClassLoader都是java類，都繼承自URLClassLoader超類。另外，類加載採用了cache機制，就是每次加載的時候先從緩存中查找，若是能找到，則直接返回，這就是爲何每次修改了class時還須要重啓JVM才能生效的緣由。

三、ClassLoader的加載機制分析：

3.一、ClassLoader加載機制：

3.1.一、全盤負責：

一個classloader加載一個class後，這個class所引用或者依賴的類也由這個classloader載入，除非顯示的用另外一個classloader載入。

3.1.二、委託機制

先由父加載器加載，除非父加載器找不到時才從本身的類路徑中去尋找。

3.1.三、Cache機制

Classloader採用緩存機制，即先查Cache；若Cache中保存了這個Class就直接返回；若無，才從文件讀取和轉化爲Class並放入Cache

3.二、原理介紹

ClassLoader使用的是雙親委託模型來搜索類的，每一個ClassLoader實例都有一個父類加載器的引用（不是繼承的關係，是一個包含的關係），虛擬機內置的類加載器（Bootstrap ClassLoader）自己沒有父類加載器，但能夠用做其它ClassLoader實例的的父類加載器。當一個ClassLoader實例須要加載某個類時，它會試圖親自搜索某個類以前，先把這個任務委託給它的父類加載器，這個過程是由上至下依次檢查的，首先由最頂層的類加載器Bootstrap ClassLoader試圖加載，若是沒加載到，則把任務轉交給Extension ClassLoader試圖加載，若是也沒加載到，則轉交給App ClassLoader 進行加載，若是它也沒有加載獲得的話，則返回給委託的發起者，由它到指定的文件系統或網絡等URL中加載該類。若是它們都沒有加載到這個類時，則拋出ClassNotFoundException異常。不然將這個找到的類生成一個類的定義，並將它加載到內存當中，最後返回這個類在內存中的Class實例對象。

3.四、爲何要使用雙親委託這種模型呢？

由於這樣能夠避免重複加載，當父親已經加載了該類的時候，就沒有必要子ClassLoader再加載一次。考慮到安全因素，咱們試想一下，若是不使用這種委託模式，那咱們就能夠隨時使用自定義的String來動態替代java核心api中定義的類型，這樣會存在很是大的安全隱患，而雙親委託的方式，就能夠避免這種狀況，由於String已經在啓動時就被引導類加載器（Bootstrap ClassLoader）加載，因此用戶自定義的ClassLoader永遠也沒法加載一個本身寫的String，除非你改變JDK中ClassLoader搜索類的默認算法。

3.4.一、類關係

由圖看到Bootstrap ClassLoader並不在繼承鏈上，由於它是java虛擬機內置的類加載器，對外不可見。能夠看到頂層ClassLoader有一個parent屬性，用來表示着類加載器之間的層次關係（雙親委派模型）；注意，ExtClassLoader類在初始化時顯式指定了parent爲null，因此它的父類加載器默認爲Bootstrap ClassLoader。在tomcat中都是經過擴展URLClassLoader來實現本身的類加載器。

這3種類加載器之間存在着父子關係(區別於java裏的繼承)，子加載器保存着父加載器的引用。當一個類加載器須要加載一個目標類時，會先委託父加載器去加載，而後父加載器會在本身的加載路徑中搜索目標類，父加載器在本身的加載範圍中找不到時，纔會交還給子加載器加載目標類。

採用雙親委託模式能夠避免類加載混亂，並且還將類分層次了，例如java中lang包下的類在jvm啓動時就被啓動類加載器加載了，而用戶一些代碼類則由應用程序類加載器(AppClassLoader)加載，基於雙親委託模式，就算用戶定義了與lang包中同樣的類，最終仍是由應用程序類加載器委託給啓動類加載器去加載，這個時候啓動類加載器發現已經加載過了lang包下的類了，因此二者都不會再從新加載。固然，若是使用者經過自定義的類加載器能夠強行打破這種雙親委託模型，但也不會成功的，java安全管理器拋出將會拋出java.lang.SecurityException異常。

啓動類加載器是擴展類加載器的父類加載器：擴展類加載器在sun.misc.Launcher構造函數中被初始化，它的父類加載器被設置了爲null，那爲何還說啓動類加載器是它的父加載器？看一下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) {  // 父類加載器不爲null，則調用父類加載器嘗試加載
                        c = parent.loadClass(name, false);
                    } else {   // 父類加載器爲null，則調用本地方法，交由啓動類加載器加載，因此說ExtClassLoader的父類加載器爲Bootstrap ClassLoader
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                }
                if (c == null) { //仍然加載不到，只能由本加載器經過findClass去加載
                    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;
        }
    }

從代碼中看到，若是parent==null，將會由啓動類加載器嘗試加載，因此擴展類加載器的父類加載器是啓動類加載器。

擴展類加載器是應用程序類加載器的父類加載器：這個比較好理解，依然是在sun.misc.Launcher構造函數初始化應用程序類加載器時，指定了ExtClassLoader爲AppClassLoader的父類加載器:

Launcher.ExtClassLoader var1;
try {
    var1 = Launcher.ExtClassLoader.getExtClassLoader();
} catch (IOException var10) {
    throw new InternalError("Could not create extension class loader");
}

try {
    this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
} catch (IOException var9) {
    throw new InternalError("Could not create application class loader");
}

應用程序類加載器是自定義類加載器的父類加載器：這裏指的是使用默認構造函數進行自定義類加載器(不然你能夠指定parent來構造一個父加載器爲ExtClassLoader的自定義類加載器)，不管是經過擴展ClassLoader仍是URLClassLoader最終都會獲取系統類加載器(AppClassLoader)做爲父類加載器：

protected ClassLoader() {
        //調用getSystemClassLoader方法獲取系統類加載器做爲父類加載器
        this(checkCreateClassLoader(), getSystemClassLoader()); 
    }
public static ClassLoader getSystemClassLoader() {
        initSystemClassLoader(); //初始化系統類加載器
        .....
        return scl;
    }
private static synchronized void initSystemClassLoader() {
        ......
        sun.misc.Launcher l = sun.misc.Launcher.getLauncher();
        ......
        scl = l.getClassLoader();  //這裏拿到的就是在Launcher構造函數中構造的AppClassLoader實例
        ......
        }
    }

3.五、 JVM在搜索類的時候，又是如何斷定兩個class是相同的呢？

JVM在斷定兩個class是否相同時，不只要判斷兩個類名是否相同，並且要判斷是否由同一個類加載器實例加載的。只有二者同時知足的狀況下，JVM才認爲這兩個class是相同的。就算兩個class是同一份class字節碼，若是被兩個不一樣的ClassLoader實例所加載，JVM也會認爲它們是兩個不一樣class。好比網絡上的一個Java類org.classloader.simple.NetClassLoaderSimple，javac編譯以後生成字節碼文件NetClassLoaderSimple.class，ClassLoaderA和ClassLoaderB這兩個類加載器並讀取了NetClassLoaderSimple.class文件，並分別定義出了java.lang.Class實例來表示這個類，對於JVM來講，它們是兩個不一樣的實例對象，但它們確實是同一份字節碼文件，若是試圖將這個Class實例生成具體的對象進行轉換時，就會拋運行時異常java.lang.ClassCaseException，提示這是兩個不一樣的類型。如今經過實例來驗證上述所描述的是否正確：

在JVM中，如何肯定一個類型實例？答：全類名嗎？不是，是類加載器加上全類名

參考文獻：

https://www.ibm.com/developerworks/cn/java/j-lo-classloader/

參考：http://blog.csdn.net/lovingprince/article/details/4238695

http://www.blogjava.net/crazycy/archive/2007/02/01/97350.html ClassLoader基礎

http://www.blogjava.net/crazycy/archive/2006/11/24/83379.html ClassLoader 之 Servlet妙用

http://longdick.iteye.com/blog/442213

http://ifeve.com/classloader/ 深刻淺出ClassLoader

http://www.cnblogs.com/kindevil-zx/p/5603643.html Dubbo源碼之SPI