【深入了解Java虛拟機】虛拟機類加載機制:類加載器&雙親委派模型&沙箱安全機制

1.類與類加載器

2.類加載機制的基本特征

3.類加載器的分類

1.啟動類加載器：C++實作，是虛拟機自身的一部分

2.其他所有類加載器：由Java實作，獨立于虛拟機外部，并且全部繼承自抽象類java.lang.ClassLoader。

4.類加載器的介紹

4.1 啟動類加載器

存放路徑：<JAVA_HOME>\lib，或者是-Xbootclasspath指定的路徑。（而且是虛拟機能夠識别的）

實作：C/C++實作

作用：提供JVM自身所需要的類

使用方法：啟動類加載器無法被Java程式直接引用。如果需要把加載請求委派給類加載器去處理，直接使用null代替即可。

4.2 擴充類加載器

存放路徑：<JAVA_HOME>\lib\ext目錄，或者被java.ext.dirs系統變量所指定的路徑中所有的類庫。

實作：Java

作用：是一種Java系統類庫的擴充機制，JDK的開發團隊允許使用者将具有通用性的類庫放置在ext目錄以擴充Java SE的功能。

使用方法：在程式中直接使用。

4.3 應用程式類加載器（系統類加載器）

實作：由sun.misc.Launcher$AppClassLoader實作。

作用：負責加載使用者類路徑（ClassPath）上所有的類庫。

是ClassLoader類中的getSystemClassLoader()方法的傳回值。

使用方法：直接使用。

4.4 自定義類加載器

5.雙親委派模型

5.1 類加載器雙親委派模型

5.2 雙親委派模型的工作過程

如果一個類收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，是以所有的加載請求都應該傳送到最頂層的啟動類加載器中，隻有當父加載器回報自己無法完成這個加載請求（它的搜尋範圍中沒有找到所需的類）時，子加載器才會嘗試自己去完成加載。

5.3 實作雙親委派模型的代碼

5.4 雙親委派模型的優點

1.避免類的重複加載，確定一個類的全局唯一性

Java類随着它的類加載器一起具備了一種帶有優先級的層次關系，通過這種層次關系可以避免類的重複加載，當父親已經加載了此類時，就沒有必要ClassLoader再加載一次。

2.保護程式安全，防止核心API被随意篡改

5.5 雙親委派模型的缺點

檢查類是否加載的委托過程是單向的，這個方式雖然從結構上說比較清晰，使各個ClassLoader的職責非常明确，但是同時會帶來一個問題，即頂層的ClassLoader無法通路底層的ClassLoader所加載的類。

通常情況下，啟動類加載器中的類為系統核心類，包括一些重要的系統接口，而在應用類加載器中為應用類。按照這種模式，應用類通路系統類自然是沒有問題，但是系統類通路應用類就會出現問題。比如在系統類中提供了一個接口，該接口需要在應用類中得以實作，該接口還綁定一個工廠方法，用于建立該接口的執行個體，而接口和工廠方法都在啟動類加載器中。這時，就會出現該工廠方法無法建立由應用類加載器的應用執行個體的問題。

6.三次雙親委派機制的破壞

6.1 第一次

第一次破壞發生在雙親委派模型出現之前（即jdk1.2）

6.2 第二次

由模型自身的缺陷導緻。

線程上下文類加載器：這個類加載器可以通過java.lang.Thread類的setContextClassLoader()方法進行設定，如果建立線程時還未設定，它将會從父線程繼承一個，如果在應用程式的全局範圍内都沒有設定過的話，那這個類加載器預設就是應用程式類加載器。

有了線程上下文類加載器，就可以父類加載器去請求子類加載器完成類加載。

Java 提供了很多服務提供者接口（Service Provider Interface，SPI），允許第三方為這些接口提供實作。常見的

SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。 這些 SPI 的接口由 Java 核心庫來提供，而這些 SPI

的實作代碼則是作為 Java 應用所依賴的 jar

包被包含進類路徑（CLASSPATH）裡。SPI接口中的代碼經常需要加載具體的實作類。那麼問題來了，SPI的接口是Java核心庫的一部分，是由**啟動類加載器(Bootstrap

Classloader)來加載的；SPI的實作類是由系統類加載器(System ClassLoader)**來加載的。引導類加載器是無法找到

SPI 的實作類的，因為依照雙親委派模型，BootstrapClassloader無法委派AppClassLoader來加載類。

而線程上下文類加載器破壞了“雙親委派模型”，可以在執行線程中抛棄雙親委派加載鍊模式，使程式可以逆向使用類加載器。

6.3 第三次

由使用者對程式動态性的追求導緻。

代碼熱替換

OSGI

7.沙箱安全機制

8.ClassLoader

9.JDK9的新特性