Java類加載機制（全套）

Java類加載機制（全套）

概述

在開始正文之前，我們先看兩張圖 。Java平臺的理解？Java最顯著的特性？Java是解釋執行？ 先看一下java程序的執行流程圖

再看一下jvm的大致物理結構圖

本文是我在學習jvm類加載機制的時候對網上的一些資料的整理和總結。本文將研究一下問題：

什麼是類加載？類的加載過程（生命週期）？類什麼時候初始化？類初始化順序？類加載器、反射、字節碼等一系列問題。

一、類加載機制概念

• Java虛擬機把描述類的數據從Class文件加載到內存，並對數據進行校驗、轉換解析和初始化，最終形成可以被虛擬機直接使用的Java類型，這就是虛擬機的加載機制。* Class文件由類裝載器裝載後，在JVM中將形成一份描述Class結構的元信息對象，通過該元信息對象可以獲知Class的結構信息：如構造函數，屬性和方法等，Java允許用戶藉由這個Class相關的元信息對象間接調用Class對象的功能,這裏就是我們經常能見到的Class類。

二、類加載過程

工作機制

類裝載器就是尋找類的字節碼文件，並構造出類在JVM內部表示的對象組件。在Java中，類裝載器把一個類裝入JVM中，要經過以下步驟：

  (1) 裝載：查找和導入Class文件；

  (2) 鏈接：把類的二進制數據合併到JRE中；

     (a)校驗：檢查載入Class文件數據的正確性；

     (b)準備：給類的靜態變量分配存儲空間；

     (c)解析：將符號引用轉成直接引用；

  (3) 初始化：對類的靜態變量，靜態代碼塊執行初始化操作

Java程序可以動態擴展是由運行期動態加載和動態鏈接實現的；比如：如果編寫一個使用接口的應用程序，可以等到運行時再指定其實際的實現(多態)，解析過程有時候還可以在初始化之後執行；比如：動態綁定(多態) 如上圖所示，加載、驗證、準備、初始化和卸載這五個階段的順序是確定的，類的加載過程必須按照這個順序來按部就班地開始，而解析階段則不一定，它在某些情況下可以在初始化階段後再開始。 類的生命週期的每一個階段通常都是互相交叉混合式進行的，通常會在一個階段執行的過程中調用或激活另外一個階段。

在我參考別人的資料的時候，發現都是先介紹的類的初始化這個過程，但是我覺得這樣會造成一種誤解什麼事類的初始化，和它應該發生的時機。這裏我就按照類的加載生命週期順序介紹每一個過程了。

1. 裝載(加載)

類的裝載指的是將類的.class文件中的二進制數據讀入到內存中，將其放在運行時數據區的方法區內，然後在堆區創建一個java.lang.Class對象，用來封裝類在方法區內的數據結構。類的加載的最終產品是位於堆區中的Class對象，Class對象封裝了類在方法區內的數據結構，並且向Java程序員提供了訪問方法區內的數據結構的接口。

類加載器並不需要等到某個類被“首次主動使用”時再加載它，JVM規範允許類加載器在預料某個類將要被使用時就預先加載它，如果在預先加載的過程中遇到了.class文件缺失或存在錯誤，類加載器必須在程序首次主動使用該類時才報告錯誤（LinkageError錯誤）如果這個類一直沒有被程序主動使用，那麼類加載器就不會報告錯誤。

加載.class文件的方式有:

1). 從本地系統中直接加載 2). 通過網絡下載.class文件 3). 從zip，jar等歸檔文件中加載.class文件 4). 從專有數據庫中提取.class文件 5). 將Java源文件動態編譯爲.class文件

在瞭解了什麼是類的加載後，回頭來再看jvm進行類加載階段都做了什麼。虛擬機需要完成以下三件事情：

1).通過一個類的全限定名稱來獲取定義此類的二進制字節流。

2).將這個字節流所代表的靜態存儲結構轉化爲方法區的運行時數據結構。

3).在java堆中生成一個代表這個類的java.lang.Class對象，作爲方法區這些數據的訪問入口。

相對於類加載過程的其他階段，加載階段是開發期相對來說可控性比較強，該階段既可以使用系統提供的類加載器完成，也可以由用戶自定義的類加載器來完成，開發人員可以通過定義自己的類加載器去控制字節流的獲取方式。關於這個過程的更多細節，我會在下一節細說，類的加載。 加載階段完成後，虛擬機外部的 二進制字節流就按照虛擬機所需的格式存儲在方法區之中，而且在Java堆中也創建一個java.lang.Class類的對象，這樣便可以通過該對象訪問方法區中的這些數據。

2. 驗證

驗證的目的是爲了確保Class文件中的字節流包含的信息符合當前虛擬機的要求，而且不會危害虛擬機自身的安全。不同的虛擬機對類驗證的實現可能會有所不同，但大致都會完成以下四個階段的驗證：文件格式的驗證、元數據的驗證、字節碼驗證和符號引用驗證。

1）文件格式的驗證：驗證字節流是否符合Class文件格式的規範，並且能被當前版本的虛擬機處理，該驗證的主要目的是保證輸入的字節流能正確地解析並存儲於方法區之內。經過該階段的驗證後，字節流纔會進入內存的方法區中進行存儲，後面的三個驗證都是基於方法區的存儲結構進行的。

2）元數據驗證：對類的元數據信息進行語義校驗（其實就是對類中的各數據類型進行語法校驗），保證不存在不符合Java語法規範的元數據信息。

3）字節碼驗證：該階段驗證的主要工作是進行數據流和控制流分析，對類的方法體進行校驗分析，以保證被校驗的類的方法在運行時不會做出危害虛擬機安全的行爲。

4）符號引用驗證：這是最後一個階段的驗證，它發生在虛擬機將符號引用轉化爲直接引用的時候（解析階段中發生該轉化，後面會有講解），主要是對類自身以外的信息（常量池中的各種符號引用）進行匹配性的校驗。

3. 準備

準備階段是正式爲類變量分配內存並設置類變量初始值的階段，這些內存都將在方法區中進行分配。 注：

1）這時候進行內存分配的僅包括類變量（static），而不包括實例變量，實例變量會在對象實例化時隨着對象一塊分配在Java堆中。

2）這裏所設置的初始值通常情況下是數據類型默認的零值（如0、0L、null、false等），而不是被在Java代碼中被顯式地賦予的值。

4. 解析

解析階段是虛擬機將常量池內的符號引用替換爲直接引用的過程。

符號引用（Symbolic Reference）：符號引用以一組符號來描述所引用的目標，符號引用可以是任何形式的字面量，符號引用與虛擬機實現的內存佈局無關，引用的目標並不一定已經在內存中。

直接引用（Direct Reference）：直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用是與虛擬機實現的內存佈局相關的，同一個符號引用在不同的虛擬機實例上翻譯出來的直接引用一般都不相同，如果有了直接引用，那引用的目標必定已經在內存中存在。

1)、類或接口的解析：判斷所要轉化成的直接引用是對數組類型，還是普通的對象類型的引用，從而進行不同的解析。 2)、字段解析：對字段進行解析時，會先在本類中查找是否包含有簡單名稱和字段描述符都與目標相匹配的字段，如果有，則查找結束；如果沒有，則會按照繼承關係從上往下遞歸搜索該類所實現的各個接口和它們的父接口，還沒有，則按照繼承關係從上往下遞歸搜索其父類，直至查找結束。

3)、類方法解析：對類方法的解析與對字段解析的搜索步驟差不多，只是多了判斷該方法所處的是類還是接口的步驟，而且對類方法的匹配搜索，是先搜索父類，再搜索接口。

4)、接口方法解析：與類方法解析步驟類似，只是接口不會有父類，因此，只遞歸向上搜索父接口就行了。

5. 初始化

類初始化階段是類加載過程的最後一步，前面的類加載過程中，除了加載（Loading）階段用戶應用程序可以通過自定義類加載器參與之外，其餘動作完全由虛擬機主導和控制。到了初始化階段，才真正開始執行類中定義的Java程序代碼。 初始化，爲類的靜態變量賦予正確的初始值，JVM負責對類進行初始化，主要對類變量進行初始化。在Java中對類變量進行初始值設定有兩種方式：

①聲明類變量時指定初始值

②使用靜態代碼塊爲類變量指定初始值

JVM初始化步驟

1)、假如這個類還沒有被加載和連接，則程序先加載並連接該類

2)、假如該類的直接父類還沒有被初始化，則先初始化其直接父類

3)、假如類中有初始化語句，則系統依次執行這些初始化語句

初始化階段時執行類構造器方法()的過程。

1）類構造器方法是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊（static{}塊）中的語句合併產生的，編譯器收集的順序由語句在源文件中出現的順序所決定。

2）類構造器方法與類的構造函數不同，它不需要顯式地調用父類構造器，虛擬機會保證在子類的類構造器方法執行之前，父類的類構造器方法已經執行完畢，因此在虛擬機中第一個執行的類構造器方法的類一定是java.lang.Object。

3）由於父類的類構造器方法方法先執行，也就意味着父類中定義的靜態語句塊要優先於子類的變量賦值操作。

4）類構造器方法對於類或者接口來說並不是必需的，如果一個類中沒有靜態語句塊也沒有對變量的賦值操作，那麼編譯器可以不爲這個類生成類構造器方法。

5）接口中可能會有變量賦值操作，因此接口也會生成類構造器方法。但是接口與類不同，執行接口的類構造器方法不需要先執行父接口的類構造器方法。只有當父接口中定義的變量被使用時，父接口才會被初始化。另外，接口的實現類在初始化時也不會執行接口的類構造器方法。

6）虛擬機會保證一個類的類構造器方法在多線程環境中被正確地加鎖和同步。如果有多個線程去同時初始化一個類，那麼只會有一個線程去執行這個類的類構造器方法，其它線程都需要阻塞等待，直到活動線程執行類構造器方法完畢。如果在一個類的類構造器方法中有耗時很長的操作，那麼就可能造成多個進程阻塞。

6.結束生命週期

在以下情況的時候，Java虛擬機會結束生命週期 1). 執行了System.exit()方法 2). 程序正常執行結束 3). 程序在執行過程中遇到了異常或錯誤而異常終止 4). 由於操作系統出現錯誤而導致Java虛擬機進程終止

三、 何時開始類的初始化

什麼情況下需要開始類加載過程的第一個階段:“加載”。虛擬機規範中並沒強行約束，這點可以交給虛擬機的的具體實現自由把握，但是對於初始化階段虛擬機規範是嚴格規定了如下幾種情況，如果類未初始化會對類進行初始化。

1、創建類的實例

2、訪問類的靜態變量(除常量【被final修辭的靜態變量】原因:常量一種特殊的變量，因爲編譯器把他們當作值(value)而不是域(field)來對待。如果你的代碼中用到了常變量(constant variable)，編譯器並不會生成字節碼來從對象中載入域的值，而是直接把這個值插入到字節碼中。這是一種很有用的優化，但是如果你需要改變final域的值那麼每一塊用到那個域的代碼都需要重新編譯。

3、訪問類的靜態方法

4、反射如(Class.forName(“my.xyz.Test”))

5、當初始化一個類時，發現其父類還未初始化，則先出發父類的初始化

6、虛擬機啓動時，定義了main()方法的那個類先初始化

以上情況稱爲稱對一個類進行“主動引用”，除此種情況之外，均不會觸發類的初始化，稱爲“被動引用” 接口的加載過程與類的加載過程稍有不同。接口中不能使用static{}塊。當一個接口在初始化時，並不要求其父接口全部都完成了初始化，只有真正在使用到父接口時（例如引用接口中定義的常量）纔會初始化。

被動引用例子

1、子類調用父類的靜態變量，子類不會被初始化。只有父類被初始化。。對於靜態字段，只有直接定義這個字段的類纔會被初始化.

2、通過數組定義來引用類，不會觸發類的初始化

3、 訪問類的常量，不會初始化類

class SuperClass {  
    static {  
        System.out.println("superclass init");  
    }  
    public static int value = 123;  
}  
  
class SubClass extends SuperClass {  
    static {  
        System.out.println("subclass init");  
    }  
}  
  
public class Test {  
    public static void main(String[] args) {  
        System.out.println(SubClass.value);// 被動應用1  
        SubClass[] sca = new SubClass[10];// 被動引用2  
    }  
}  

程序運行輸出 superclass init 123 從上面的輸入結果證明了被動引用1與被動引用2

class ConstClass {  
    static {  
        System.out.println("ConstClass init");  
    }  
    public static final String HELLOWORLD = "hello world";  
}  
  
public class Test {  
    public static void main(String[] args) {  
        System.out.println(ConstClass.HELLOWORLD);// 調用類常量  
    }  
}  

程序輸出結果 hello world 從上面的輸出結果證明了被動引用3

題目分析

上面很詳細的介紹了類的加載時機和類的加載過程，通過上面的理論來分析本文開門見上的題目

class SingleTon {  
    private static SingleTon singleTon = new SingleTon();  
    public static int count1;  
    public static int count2 = 0;  
  
    private SingleTon() {  
        count1++;  
        count2++;  
    }  
  
    public static SingleTon getInstance() {  
        return singleTon;  
    }  
}  
  
public class Test {  
    public static void main(String[] args) {  
        SingleTon singleTon = SingleTon.getInstance();  
        System.out.println("count1=" + singleTon.count1);  
        System.out.println("count2=" + singleTon.count2);  
    }  
}  

分析:

1:SingleTon singleTon = SingleTon.getInstance();調用了類的SingleTon調用了類的靜態方法，觸發類的初始化

2:類加載的時候在準備過程中爲類的靜態變量分配內存並初始化默認值 singleton=null count1=0,count2=0

3:類初始化化，爲類的靜態變量賦值和執行靜態代碼快。singleton賦值爲new SingleTon()調用類的構造方法

4:調用類的構造方法後count=1;count2=1

5:繼續爲count1與count2賦值,此時count1沒有賦值操作,所有count1爲1,但是count2執行賦值操作就變爲0

四、類初始化順序

現在我們知道什麼時候觸發類的初始化了，他精確地寫在Java語言規範中。但瞭解清楚 域（fields，靜態的還是非靜態的）、塊（block靜態的還是非靜態的）、不同類（子類和超類）和不同的接口（子接口，實現類和超接口）的初始化順序也很重要類。事實上很多核心Java面試題和SCJP問題都是基於這些概念，下面是類初始化的一些規則：

1.類從頂至底的順序初始化，所以聲明在頂部的字段的早於底部的字段初始化
2.超類早於子類和衍生類的初始化
3.如果類的初始化是由於訪問靜態域而觸發，那麼只有聲明靜態域的類才被初始化，而不會觸發超類的初始化或者子類的4.初始化即使靜態域被子類或子接口或者它的實現類所引用。
5.接口初始化不會導致父接口的初始化。
6.靜態域的初始化是在類的靜態初始化期間，非靜態域的初始化時在類的實例創建期間。這意味這靜態域初始化在非靜態域之前。
7.非靜態域通過構造器初始化，子類在做任何初始化之前構造器會隱含地調用父類的構造器，他保證了非靜態或實例變量（父類）初始化早於子類

原文鏈接：

類加載舉例：http://blog.csdn.net/mrzhoug/article/details/51581994

五、類加載器

JVM設計者把類加載階段中的“通過’類全名’來獲取定義此類的二進制字節流”這個動作放到Java虛擬機外部去實現，以便讓應用程序自己決定如何去獲取所需要的類。實現這個動作的代碼模塊稱爲“類加載器”。

1.類與類加載器

對於任何一個類，都需要由加載它的類加載器和這個類來確立其在JVM中的唯一性。也就是說，兩個類來源於同一個Class文件，並且被同一個類加載器加載，這兩個類才相等。

2.雙親委派模型

從虛擬機的角度來說，只存在兩種不同的類加載器：一種是啓動類加載器（Bootstrap ClassLoader），該類加載器使用C++語言實現，屬於虛擬機自身的一部分。另外一種就是所有其它的類加載器，這些類加載器是由Java語言實現，獨立於JVM外部，並且全部繼承自抽象類java.lang.ClassLoader。

從Java開發人員的角度來看，大部分Java程序一般會使用到以下三種系統提供的類加載器：

1)啓動類加載器（Bootstrap ClassLoader）：負責加載JAVA_HOME\lib目錄中並且能被虛擬機識別的類庫到JVM內存中，如果名稱不符合的類庫即使放在lib目錄中也不會被加載。該類加載器無法被Java程序直接引用。

2)擴展類加載器（Extension ClassLoader）：該加載器主要是負責加載JAVA_HOME\lib\，該加載器可以被開發者直接使用。

3)應用程序類加載器（Application ClassLoader）：該類加載器也稱爲系統類加載器，它負責加載用戶類路徑（Classpath）上所指定的類庫，開發者可以直接使用該類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

我們的應用程序都是由這三類加載器互相配合進行加載的，我們也可以加入自己定義的類加載器。這些類加載器之間的關係如下圖所示：

如上圖所示的類加載器之間的這種層次關係，就稱爲類加載器的雙親委派模型（Parent Delegation Model）。該模型要求除了頂層的啓動類加載器外，其餘的類加載器都應當有自己的父類加載器。子類加載器和父類加載器不是以繼承（Inheritance）的關係來實現，而是通過組合（Composition）關係來複用父加載器的代碼。

雙親委派模型的工作過程爲：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的加載器都是如此，因此所有的類加載請求都會傳給頂層的啓動類加載器，只有當父加載器反饋自己無法完成該加載請求（該加載器的搜索範圍中沒有找到對應的類）時，子加載器纔會嘗試自己去加載。

使用這種模型來組織類加載器之間的關係的好處是Java類隨着它的類加載器一起具備了一種帶有優先級的層次關係。例如java.lang.Object類，無論哪個類加載器去加載該類，最終都是由啓動類加載器進行加載，因此Object類在程序的各種類加載器環境中都是同一個類。否則的話，如果不使用該模型的話，如果用戶自定義一個java.lang.Object類且存放在classpath中，那麼系統中將會出現多個Object類，應用程序也會變得很混亂。如果我們自定義一個rt.jar中已有類的同名Java類，會發現JVM可以正常編譯，但該類永遠無法被加載運行。 在rt.jar包中的java.lang.ClassLoader類中，我們可以查看類加載實現過程的代碼，具體源碼如下：

protected synchronized Class loadClass(String name, boolean resolve)  
        throws ClassNotFoundException {  
    // 首先檢查該name指定的class是否有被加載  
    Class c = findLoadedClass(name);  
    if (c == null) {  
        try {  
            if (parent != null) {  
                // 如果parent不爲null，則調用parent的loadClass進行加載  
                c = parent.loadClass(name, false);  
            } else {  
                // parent爲null，則調用BootstrapClassLoader進行加載  
                c = findBootstrapClass0(name);  
            }  
        } catch (ClassNotFoundException e) {  
            // 如果仍然無法加載成功，則調用自身的findClass進行加載  
            c = findClass(name);  
        }  
    }  
    if (resolve) {  
        resolveClass(c);  
    }  
    return c;  
}  

通過上面代碼可以看出，雙親委派模型是通過loadClass()方法來實現的，根據代碼以及代碼中的註釋可以很清楚地瞭解整個過程其實非常簡單：先檢查是否已經被加載過，如果沒有則調用父加載器的loadClass()方法，如果父加載器爲空則默認使用啓動類加載器作爲父加載器。如果父類加載器加載失敗，則先拋出ClassNotFoundException，然後再調用自己的findClass()方法進行加載。

3.自定義類加載器

若要實現自定義類加載器，只需要繼承java.lang.ClassLoader 類，並且重寫其findClass()方法即可。java.lang.ClassLoader 類的基本職責就是根據一個指定的類的名稱，找到或者生成其對應的字節代碼，然後從這些字節代碼中定義出一個 Java 類，即 java.lang.Class 類的一個實例。除此之外，ClassLoader 還負責加載 Java 應用所需的資源，如圖像文件和配置文件等，ClassLoader 中與加載類相關的方法如下：

方法說明 getParent() 返回該類加載器的父類加載器。

loadClass(String name) 加載名稱爲 二進制名稱爲name 的類，返回的結果是 java.lang.Class 類的實例。

findClass(String name) 查找名稱爲 name 的類，返回的結果是 java.lang.Class 類的實例。

findLoadedClass(String name) 查找名稱爲 name 的已經被加載過的類，返回的結果是 java.lang.Class 類的實例。

resolveClass(Class<?> c) 鏈接指定的 Java 類。

注意：在JDK1.2之前，類加載尚未引入雙親委派模式，因此實現自定義類加載器時常常重寫loadClass方法，提供雙親委派邏輯，從JDK1.2之後，雙親委派模式已經被引入到類加載體系中，自定義類加載器時不需要在自己寫雙親委派的邏輯，因此不鼓勵重寫loadClass方法，而推薦重寫findClass方法。

在Java中，任意一個類都需要由加載它的類加載器和這個類本身一同確定其在java虛擬機中的唯一性，即比較兩個類是否相等，只有在這兩個類是由同一個類加載器加載的前提之下才有意義，否則，即使這兩個類來源於同一個Class類文件，只要加載它的類加載器不相同，那麼這兩個類必定不相等(這裏的相等包括代表類的Class對象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof關鍵字的結果)。例子代碼如下：

/** 
     * 一、ClassLoader加載類的順序 
     *  1.調用 findLoadedClass(String) 來檢查是否已經加載類。 
     *  2.在父類加載器上調用 loadClass 方法。如果父類加載器爲 null，則使用虛擬機的內置類加載器。 
     *  3.調用 findClass(String) 方法查找類。 
     * 二、實現自己的類加載器 
     *  1.獲取類的class文件的字節數組 
     *  2.將字節數組轉換爲Class類的實例 
     * @author lei 2011-9-1 
     */  
    public class ClassLoaderTest {  
        public static void main(String[] args) throws InstantiationException, IllegalAccessException, ClassNotFoundException {  
            //新建一個類加載器  
            MyClassLoader cl = new MyClassLoader("myClassLoader");  
            //加載類，得到Class對象  
            Class<?> clazz = cl.loadClass("classloader.Animal");  
            //得到類的實例  
            Animal animal=(Animal) clazz.newInstance();  
            animal.say();  
        }  
    }  
    class Animal{  
        public void say(){  
            System.out.println("hello world!");  
        }  
    }  
    class MyClassLoader extends ClassLoader {  
        //類加載器的名稱  
        private String name;  
        //類存放的路徑  
        private String path = "E:\\workspace\\Algorithm\\src";  
        MyClassLoader(String name) {  
            this.name = name;  
        }  
        MyClassLoader(ClassLoader parent, String name) {  
            super(parent);  
            this.name = name;  
        }  
        /** 
         * 重寫findClass方法 
         */  
        @Override  
        public Class<?> findClass(String name) {  
            byte[] data = loadClassData(name);  
            return this.defineClass(name, data, 0, data.length);  
        }  
        public byte[] loadClassData(String name) {  
            try {  
                name = name.replace(".", "//");  
                FileInputStream is = new FileInputStream(new File(path + name + ".class"));  
                ByteArrayOutputStream baos = new ByteArrayOutputStream();  
                int b = 0;  
                while ((b = is.read()) != -1) {  
                    baos.write(b);  
                }  
                return baos.toByteArray();  
            } catch (Exception e) {  
                e.printStackTrace();  
            }  
            return null;  
        }  
    }  
複製代碼

類加載器雙親委派模型是從JDK1.2以後引入的，並且只是一種推薦的模型，不是強制要求的，因此有一些沒有遵循雙親委派模型的特例：(瞭解)

(1).在JDK1.2之前，自定義類加載器都要覆蓋loadClass方法去實現加載類的功能，JDK1.2引入雙親委派模型之後，loadClass方法用於委派父類加載器進行類加載，只有父類加載器無法完成類加載請求時才調用自己的findClass方法進行類加載，因此在JDK1.2之前的類加載的loadClass方法沒有遵循雙親委派模型，因此在JDK1.2之後，自定義類加載器不推薦覆蓋loadClass方法，而只需要覆蓋findClass方法即可。

(2).雙親委派模式很好地解決了各個類加載器的基礎類統一問題，越基礎的類由越上層的類加載器進行加載，但是這個基礎類統一有一個不足，當基礎類想要調用回下層的用戶代碼時無法委派子類加載器進行類加載。爲了解決這個問題JDK引入了ThreadContext線程上下文，通過線程上下文的setContextClassLoader方法可以設置線程上下文類加載器。

JavaEE只是一個規範，sun公司只給出了接口規範，具體的實現由各個廠商進行實現，因此JNDI，JDBC,JAXB等這些第三方的實現庫就可以被JDK的類庫所調用。線程上下文類加載器也沒有遵循雙親委派模型。

(3).近年來的熱碼替換，模塊熱部署等應用要求不用重啓java虛擬機就可以實現代碼模塊的即插即用，催生了OSGi技術，在OSGi中類加載器體系被髮展爲網狀結構。OSGi也沒有完全遵循雙親委派模型。

4.動態加載Jar && ClassLoader 隔離問題

動態加載Jar：

Java 中動態加載 Jar 比較簡單，如下：

URL[] urls = new URL[] {new URL("file:libs/jar1.jar")};  
URLClassLoader loader = new URLClassLoader(urls, parentLoader);  
複製代碼

表示加載 libs 下面的 jar1.jar，其中 parentLoader 就是上面1中的 parent，可以爲當前的 ClassLoader。

ClassLoader 隔離問題：

大家覺得一個運行程序中有沒有可能同時存在兩個包名和類名完全一致的類？ JVM 及 Dalvik 對類唯一的識別是 ClassLoader id + PackageName + ClassName，所以一個運行程序中是有可能存在兩個包名和類名完全一致的類的。並且如果這兩個”類”不是由一個 ClassLoader 加載，是無法將一個類的示例強轉爲另外一個類的，這就是 ClassLoader 隔離。 如 Android 中碰到如下異常 [java] view plain copy

android.support.v4.view.ViewPager can not be cast to android.support.v4.view.ViewPager  
複製代碼

當碰到這種問題時可以通過 instance.getClass().getClassLoader(); 得到 ClassLoader，看 ClassLoader 是否一樣。

加載不同 Jar 包中公共類：

現在 Host 工程包含了 common.jar, jar1.jar, jar2.jar，並且 jar1.jar 和 jar2.jar 都包含了 common.jar，我們通過 ClassLoader 將 jar1, jar2 動態加載進來，這樣在 Host 中實際是存在三份 common.jar，如下圖：

我們怎麼保證 common.jar 只有一份而不會造成上面3中提到的 ClassLoader 隔離的問題呢，其實很簡單，在生成 jar1 和 jar2 時把 common.jar 去掉，只保留 host 中一份，以 host ClassLoader 爲 parentClassLoader 即可。

一道面試題

能不能自己寫個類叫java.lang.System？

答案：通常不可以，但可以採取另類方法達到這個需求。 解釋：爲了不讓我們寫System類，類加載採用委託機制，這樣可以保證爸爸們優先，爸爸們能找到的類，兒子就沒有機會加載。而System類是Bootstrap加載器加載的，就算自己重寫，也總是使用Java系統提供的System，自己寫的System類根本沒有機會得到加載。

但是，我們可以自己定義一個類加載器來達到這個目的，爲了避免雙親委託機制，這個類加載器也必須是特殊的。由於系統自帶的三個類加載器都加載特定目錄下的類，如果我們自己的類加載器放在一個特殊的目錄，那麼系統的加載器就無法加載，也就是最終還是由我們自己的加載器加載。

六、反射

原文鏈接：https://www.cnblogs.com/lakeslove/p/5978382.html（18.3章節）

七、字節碼

Java號稱是一門“一次編譯到處運行”的語言，但是我們對這句話的理解深度又有多少呢？從我們寫的java文件到通過編譯器編譯成java字節碼文件（也就是.class文件），這個過程是java編譯過程；而我們的java虛擬機執行的就是字節碼文件。不論該字節碼文件來自何方，由哪種編譯器編譯，甚至是手寫字節碼文件，只要符合java虛擬機的規範，那麼它就能夠執行該字節碼文件。