jvm雙親委派模型

其實，雙親委派模型並不複雜。自定義類加載器也不難！隨便從網上搜一下就能搜出一大把結果，而後copy一下就能用。可是，若是每次想自定義類加載器就必須搜一遍別人的文章，而後複製，這樣顯然不行。但是自定義類加載器又不常常用，時間久了容易忘記。相信你常常會記不太清loadClass、findClass、defineClass這些函數我到底應該重寫哪個？它們主要是作什麼的？本文大體分析了各個函數的流程，目的就是讓你看完以後，難以忘記！或者說，延長你對自定義類加載器的記憶時間！隨時隨地想自定義就自定義！

1. 雙親委派模型

關於雙親委派模型，網上的資料有不少。我這裏只簡單的描述一下，就當是複習。

1.1 什麼是雙親委派模型？

首先，先要知道什麼是類加載器。簡單說，類加載器就是根據指定全限定名稱將class文件加載到JVM內存，轉爲Class對象。若是站在JVM的角度來看，只存在兩種類加載器:

• 啓動類加載器（Bootstrap ClassLoader）：由C++語言實現（針對HotSpot）,負責將存放在<JAVA_HOME>\lib目錄或-Xbootclasspath參數指定的路徑中的類庫加載到內存中。

• 其餘類加載器：由Java語言實現，繼承自抽象類ClassLoader。如：

  • 擴展類加載器（Extension ClassLoader）：負責加載<JAVA_HOME>\lib\ext目錄或java.ext.dirs系統變量指定的路徑中的全部類庫。
  • 應用程序類加載器（Application ClassLoader）。負責加載用戶類路徑（classpath）上的指定類庫，咱們能夠直接使用這個類加載器。通常狀況，若是咱們沒有自定義類加載器默認就是用這個加載器。

雙親委派模型工做過程是：若是一個類加載器收到類加載的請求，它首先不會本身去嘗試加載這個類，而是把這個請求委派給父類加載器完成。每一個類加載器都是如此，只有當父加載器在本身的搜索範圍內找不到指定的類時（即ClassNotFoundException），子加載器纔會嘗試本身去加載。

類加載器的雙親委派模型

1.2 爲何須要雙親委派模型？

爲何須要雙親委派模型呢？假設沒有雙親委派模型，試想一個場景：

黑客自定義一個java.lang.String類，該String類具備系統的String類同樣的功能，只是在某個函數稍做修改。好比equals函數，這個函數常用，若是在這這個函數中，黑客加入一些「病毒代碼」。而且經過自定義類加載器加入到JVM中。此時，若是沒有雙親委派模型，那麼JVM就可能誤覺得黑客自定義的java.lang.String類是系統的String類，致使「病毒代碼」被執行。

而有了雙親委派模型，黑客自定義的java.lang.String類永遠都不會被加載進內存。由於首先是最頂端的類加載器加載系統的java.lang.String類，最終自定義的類加載器沒法加載java.lang.String類。

或許你會想，我在自定義的類加載器裏面強制加載自定義的java.lang.String類，不去經過調用父加載器不就行了嗎?確實，這樣是可行。可是，在JVM中，判斷一個對象是不是某個類型時，若是該對象的實際類型與待比較的類型的類加載器不一樣，那麼會返回false。

舉個簡單例子：

ClassLoader1、ClassLoader2都加載java.lang.String類，對應Class一、Class2對象。那麼Class1對象不屬於ClassLoad2對象加載的java.lang.String類型。

1.3 如何實現雙親委派模型？

雙親委派模型的原理很簡單，實現也簡單。每次經過先委託父類加載器加載，當父類加載器沒法加載時，再本身加載。其實ClassLoader類默認的loadClass方法已經幫咱們寫好了，咱們無需去寫。

2. 自定義類加載器

2. 1幾個重要函數

2.1.1 loadClass

loadClass默認實現以下：

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
}

再看看loadClass(String name, boolean resolve)函數：

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        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 thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                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;
    }
}

從上面代碼能夠明顯看出，loadClass(String, boolean)函數即實現了雙親委派模型！整個大體過程以下：

1. 首先，檢查一下指定名稱的類是否已經加載過，若是加載過了，就不須要再加載，直接返回。
2. 若是此類沒有加載過，那麼，再判斷一下是否有父加載器；若是有父加載器，則由父加載器加載（即調用parent.loadClass(name, false);）.或者是調用bootstrap類加載器來加載。
3. 若是父加載器及bootstrap類加載器都沒有找到指定的類，那麼調用當前類加載器的findClass方法來完成類加載。

話句話說，若是自定義類加載器，就必須重寫findClass方法！

2.1.1 find Class

findClass的默認實現以下：

protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
}

能夠看出，抽象類ClassLoader的findClass函數默認是拋出異常的。而前面咱們知道，loadClass在父加載器沒法加載類的時候，就會調用咱們自定義的類加載器中的findeClass函數，所以咱們必需要在loadClass這個函數裏面實現將一個指定類名稱轉換爲Class對象.

若是是是讀取一個指定的名稱的類爲字節數組的話，這很好辦。可是如何將字節數組轉爲Class對象呢？很簡單，Java提供了defineClass方法，經過這個方法，就能夠把一個字節數組轉爲Class對象啦~

2.1.1 defineClass

defineClass主要的功能是：

將一個字節數組轉爲Class對象，這個字節數組是class文件讀取後最終的字節數組。如，假設class文件是加密過的，則須要解密後做爲形參傳入defineClass函數。

defineClass默認實現以下：

protected final Class<?> defineClass(String name, byte[] b, int off, int len)
        throws ClassFormatError  {
        return defineClass(name, b, off, len, null);
}

 

雙親模式的問題

頂層ClassLoader，沒法加載底層ClassLoader的類

Java框架(rt.jar)如何加載應用的類？

好比：javax.xml.parsers包中定義了xml解析的類接口
Service Provider Interface SPI 位於rt.jar
即接口在啓動ClassLoader中。
而SPI的實現類，在AppLoader。

這樣就沒法用BootstrapClassLoader去加載SPI的實現類。

 

解決

JDK中提供了一個方法：

1:  Thread. setContextClassLoader()

用以解決頂層ClassLoader沒法訪問底層ClassLoader的類的問題；
基本思想是，在頂層ClassLoader中，傳入底層ClassLoader的實例。

 

線程上下文類加載器（context class loader）是從 JDK 1.2 開始引入的。類 java.lang.Thread中的方法 getContextClassLoader()和setContextClassLoader(ClassLoader cl)用來獲取和設置線程的上下文類加載器。若是沒有經過 setContextClassLoader(ClassLoader cl)方法進行設置的話，線程將繼承其父線程的上下文類加載器。Java 應用運行的初始線程的上下文類加載器是系統類加載器(appClassLoader)。在線程中運行的代碼能夠經過此類加載器來加載類和資源。

　　前面提到的類加載器的代理模式並不能解決 Java 應用開發中會遇到的類加載器的所有問題。Java 提供了不少服務提供者接口（Service Provider Interface，SPI），容許第三方爲這些接口提供實現。常見的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。這些 SPI 的接口由 Java 核心庫來提供，如 JAXP 的 SPI 接口定義包含在 javax.xml.parsers包中。這些 SPI 的實現代碼極可能是做爲 Java 應用所依賴的 jar 包被包含進來，能夠經過類路徑（CLASSPATH）來找到，如實現了 JAXP SPI 的 Apache Xerces所包含的 jar 包。SPI 接口中的代碼常常須要加載具體的實現類。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory類中的 newInstance()方法用來生成一個新的DocumentBuilderFactory的實例。這裏的實例的真正的類是繼承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的實現所提供的。如在 Apache Xerces 中，實現的類是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而問題在於，SPI 的接口是 Java 核心庫的一部分，是由引導類加載器來加載的；SPI 實現的 Java 類通常是由系統類加載器來加載的。引導類加載器是沒法找到 SPI 的實現類的，由於它只加載 Java 的核心庫。它也不能代理給系統類加載器，由於它是系統類加載器的祖先類加載器。也就是說，類加載器的代理模式沒法解決這個問題。

　　線程上下文類加載器正好解決了這個問題。若是不作任何的設置，Java 應用的線程的上下文類加載器默認就是系統上下文類加載器。在 SPI 接口的代碼中使用線程上下文類加載器，就能夠成功的加載到 SPI 實現的類。線程上下文類加載器在不少 SPI 的實現中都會用到。

JNDI，JDBC的訴求是：

　　爲了能讓應用程序訪問到這些jar包中的實現類，即用appClassLoarder去加載這些實現類。能夠用getContextClassLoader取得當前線程的ClassLoader（即appClassLoarder），而後去加載這些實現類，就能讓應用訪問到。