一，類的加載過程詳解

1，概述

在Java中數據類型分為基本數據類型和引用數據類型。基本數據類型由虛擬機預先定義，引用數據類型則需要進行類的加載。

(接口，注解，枚舉類，類的加載都統稱為類的加載)

按照Java虛擬機規范，從class文件到加載到內存中的類，到類卸載出內存為止，它的整個生命周期包括如下7個階段:

其中，驗證、準備、解析3個部分統稱為鏈接（Linking）

從程序中類的使用過程看:

2，Loading

1）加載完成的操作

加載的理解

所謂加載，簡而言之就是將 Java 類的字節碼文件加載到機器內存中，并在內存中構建出 Java 類的原型——類模板對象。所謂類模板對象，其實就是 Java 類在 JVM 內存中的一個快照，JVM 將從字節碼文件中解析出的常量池、類字段、類方法等信息存儲到模板中，這樣 JVM 在運行期便能通過類模板而獲取 Java 類中的任意信息，能夠對 Java 類的成員變量進行遍歷，也能進行Java 方法的調用。

反射的機制即基于這一基礎。如果 JVM 沒有將 Java 類的聲明信息存儲起來，則 JVM 在運行期也無法反射。

加載完成的操作

加載階段，簡言之，查找并加載類的二進制數據，生成 Class 的實例。

在加載類時，Java 虛擬機必須完成以下3件事情：

①通過類的全名，獲取類的二進制數據流

②解析類的二進制數據流為方法區內的數據結構(Java 類模型)

③創建 java.lang.Class 類的實例，表示該類型。作為方法區這個類的各種數據的訪問入口

2）二進制流的獲取方式

對于類的二進制數據流，虛擬機可以通過多種途徑產生或獲得。(只要所讀取的字節碼符合 JVM 規范即可)

①虛擬機可能通過文件系統讀入一個 class 后綴的文件(最常見)。

②讀入 jar、zip 等歸檔數據包，提取類文件。

③事先存放在數據庫中的類的二進制數據。

④使用類似于 HTTP 之類的協議通過網絡進行加載。

⑤在運行時生成一段 Class 的二進制信息等。

在獲取到類的二進制信息后，Java 虛擬機就會處理這些數據，并最終轉為一個 java.lang.Class 的實例。

如果輸入數據不是 ClassFile 的結構，則會拋出 ClassFormatError。

3）類模型與class實例的位置

①類模型的位置

加載的類在 JVM 中創建相應的類結構，類結構會存儲在方法區(JDK 1.8之前：永久代；JDK 1.8之后：元空間)

②Class 實例的位置

類將 .class 文件加載至元空間后，會在堆中創建一個 java.lang.Class 對象，用來封裝類位于方法區內的數據結構，該 Class 對象是在加載類的過程中創建的，每個類都對應有一個 Class 類型的對象。

③圖示

外部可以通過訪問代表 Order 類的 Class 對象來獲取 Order 的類數據結構。

④說明

Class 類的構造方法是私有的，只有 JVM 能夠創建。

java.lang.Class 實例是訪問類型元數據的接口，也是實現反射的關鍵數據、入口。通過 Class 類提供的接口，可以獲得目標類所關聯的 .class 文件中具體的數據結構：方法、字段等信息。

4）數組類的加載

創建數組類的情況稍微有些特殊，因為數組類本身并不是由類加載器負責創建，而是由 JVM 在運行時根據需要而直接創建的，但數組的元素類型仍然需要依靠類加載器去創建。創建數組類(下述簡稱 A)的過程：

1.如果數組的元素類型是引用類型，那么就遵循定義的加載過程遞歸加載和創建數組 A 的元素類型。

2.JVM 使用指定的元素類型和數組維度來創建新的數組類。

如果數組的元素類型是引用類型，數組類的可訪問性就由元素類型的可訪問性決定。否則數組類的可訪問性將被缺省定義為 public。

3，Linking

1）Verification

當類加載到系統后，就開始鏈接操作，驗證是鏈接操作的第一步。

它的目的是保證加載的字節碼是合法、合理并符合規范的。

驗證的步驟比較復雜，實際要驗證的項目也很繁多，大體上 Java 虛擬機需要做以下檢查，如圖所示：

整體說明

驗證的內容則涵蓋了類數據信息的格式驗證、語義檢查、字節碼驗證，以及符號引用驗證等。

其中格式驗證會和加載階段一起執行。驗證通過之后，類加載器才會成功將類的二進制數據信息加載到方法區中。

格式驗證之外的驗證操作將會在方法區中進行。

鏈接階段的驗證雖然拖慢了加載速度，但是它避免了在字節碼運行時還需要進行各種檢查。

具體說明

①格式驗證：是否以魔數 0xCAFEBABE 開頭，主版本和副版本號是否在當前 Java 虛擬機的支持范圍內，數據中每一個項是否都擁有正確的長度等

②Java 虛擬機會進行字節碼的語義檢查，但凡在語義上不符合規范的，虛擬機也不會給予驗證通過。比如：

是否所有的類都有父類的存在(在 Java 里，除了 Object 外，其他類都應該有父類)

是否一些被定義為 final 的方法或者類被重寫或繼承了

非抽象類是否實現了所有抽象方法或者接口方法

是否存在不兼容的方法(比如方法的簽名除了返回值不同，其他都一樣，這種方法會讓虛擬機無從下手調度；absract 情況下的方法，就不能是final 的了)

③Java 虛擬機還會進行字節碼驗證，字節碼驗證也是驗證過程中最為復雜的一個過程。它試圖通過對字節碼流的分析，判斷字節碼是否可以被正確地執行。比如：

在字節碼的執行過程中，是否會跳轉到一條不存在的指令

函數的調用是否傳遞了正確類型的參數

變量的賦值是不是給了正確的數據類型等

棧映射幀(StackMapTable)就是在這個階段，用于檢測在特定的字節碼處，其局部變量表和操作數棧是否有著正確的數據類型。但遺憾的是，100%準確地判斷一段字節碼是否可以被安全執行是無法實現的，因此，該過程只是盡可能地檢查出可以預知的明顯的問題。如果在這個階段無法通過檢查，虛擬機也不會正確裝載這個類。但是，如果通過了這個階段的檢查，也不能說明這個類是完全沒有問題的

在前面3次檢查中，已經排除了文件格式錯誤、語義錯誤以及字節碼的不正確性。但是依然不能確保類是沒有問題的

④校驗器還將進行符號引用的驗證。Class 文件在其常量池會通過字符串記錄自己將要使用的其他類或者方法。因此，在驗證階段，虛擬機就會檢查這些類或者方法確實是存在的，并且當前類有權限訪問這些數據，如果一個需要使用類無法在系統中找到，則會拋出 NoClassDefFoundError，如果一個方法無法被找到，則會拋出 NoSuchMethdError。

此階段在解析環節才會執行

2）Preparation

準備階段(Preparation)，簡言之，為類的靜態變量分配內存，并將其初始化為默認值。

當一個類驗證通過時，虛擬機就會進入準備階段。在這個階段，虛擬機就會為這個類分配相應的內存空間，并設置默認初始值。

Java 虛擬機為各類型變量默認的初始值如表所示：

注意：Java 并不支持 boolean 類型，對于 boolean 類型，內部實現是 int，由于 int 的默認值是0，故對應的，boolean 的默認值就是 false。

注意：

①這里不包含基本數據類型的字段用 static final 修飾的情況，因為 final 在編譯的時候就會分配了，準備階段會顯式賦值。

②注意這里不會為實例變量分配初始化，類變量會分配在方法區中，而實例變量是會隨著對象一起分配到 Java 堆中。

③在這個階段不會像初始化階段中那樣會有初始化或者代碼被執行。

3）Resolution

在準備階段完成后，就進入了解析階段。

解析階段(Resolution)，簡言之，將類、接口、字段和方法的符號引用轉為直接引用。

①具體描述

符號引用就是一些字面量的引用，和虛擬機的內部數據結構和內存分布無關。比較容理解的就是在 Class 類文件中，通過常量池進行了大量的符號引用。但是在程序實際運行時，只有符號引用是不夠的，比如當如下 println() 方法被調用時，系統需要明確知道該方法的位置。

舉例:輸出操作System.out.println()對應的字節碼:

invokevirtual #24 <java/io/PrintStream.println>

以方法為例，Java 虛擬機為每個類都準備了一張方法表，將其所有的方法都列在表中，當需要調用一個類的方法的時候，只要知道這個方法在方法表中的偏移量就可以直接調用該方法。通過解析操作，符號引用就可以轉變為目標方法在類中方法表中的位置，從而使得方法被成功調用。

②小結

所謂解析就是將符號引用轉為直接引用，也就是得到類、字段、方法在內存中的指針或者偏移量。因此，可以說，如果直接引用存在，那么可以肯定系統中存在該類、方法或者字段。但只存在符號引用，不能確定系統中一定存在該結構。

不過 Java 虛擬機規范并沒有明確要求解析階段一定要按照順序執行。在 HotSpot VM 中，加載、驗證、準備和初始化會按照順序有條不紊地執行，但鏈接階段中的解析操作往往會伴隨著 JVM 在執行完初始化之后再執行。

③字符串的復習

最后，再來看一下 CONSTANT_String 的解析。由于字符串在程序開發中有著重要的作用，因此，讀者有必要了解一下 String 在 Java 虛擬機中的處理。當在 Java 代碼中直接使用字符串常量時，就會在類中出現 CONSTANT_String，它表示字符串常量，并且會引用一個 CONSTANT_UTF8 的常量項。在 Java 虛擬機內部運行中的常量池，會維護一張字符串拘留表(intern)，它會保存所有出現過的字符串常量，并且沒有重復項。只要以 CONSTANT_String 形式出現的字符串也都會在這張表中。使用 String.intern() 方法可以得到一個字符串在拘留表中的引用，因為該表中沒有重復項，所以任何字面相同的字符串的 String.intern() 方法返回總是相等的。

4,Initialization

初始化階段，簡言之，為類的靜態變量賦予正確的初始值

①具體描述

類的初始化是類裝載的最后一個階段。如果前面的步驟都沒有問題，那么表示類可以順利裝載到系統中。此時，類才會開始執行 Java 字節碼。(即：到了初始化階段，才真正開始執行類中定義的 Java 程序代碼)

初始化階段的重要工作是執行類的初始化方法：() 方法

該方法僅能由 Java 編譯器生成并由 JVM 調用，程序開發者無法自定義一個同名的方法，更無法直接在 Java 程序中調用該方法，雖然該方法也是由字節碼指令所組成

它是類靜態成員的賦值語句以及 static 語句塊合并產生的

②說明

在加載一個類之前，虛擬機總是會試圖加載該類的父類，因此父類的 總是在子類 之前被調用，也就是說，父類的 static 塊優先級高于子類

Java 編譯器并不會為所有的類都產生() 初始化方法。哪些類在編譯為字節碼后，字節碼文件中將不會包含 () 方法？

一個類中并沒有聲明任何的類變量，也沒有靜態代碼塊時。

一個類中聲明類變量，但是沒有明確使用類變量的初始化語句以及靜態代碼塊來執行初始化操作時。

一個類中包含 static final 修飾的基本數據類型的字段，這些類字段初始化語句采用編譯時常量表達式。

1）static與final的搭配問題

/*** 說明：使用static + final修飾的字段的顯式賦值的操作，到底是在哪個階段進行的賦值？* 情況1：在鏈接階段的準備環節賦值* 情況2：在初始化階段<clinit>()中賦值** 結論：* 在鏈接階段的準備環節賦值的情況：* 1. 對于基本數據類型的字段來說，如果使用static final修飾，則顯式賦值(直接賦值常量，而非調用方法）通常是在鏈接階段的準備環節進行* 2. 對于String來說，如果使用字面量的方式賦值，使用static final修飾的話，則顯式賦值通常是在鏈接階段的準備環節進行** 在初始化階段<clinit>()中賦值的情況：* 排除上述的在準備環節賦值的情況之外的情況。** 最終結論：使用static + final修飾，且顯式賦值中不涉及到方法或構造器調用的基本數據類型或String類型的顯式賦值，是在鏈接階段的準備環節進行。*/ public class InitializationTest2 {public static int a = 1;//在初始化階段<clinit>()中賦值public static final int INT_CONSTANT = 10;//在鏈接階段的準備環節賦值public static final Integer INTEGER_CONSTANT1 = Integer.valueOf(100);//在初始化階段<clinit>()中賦值public static Integer INTEGER_CONSTANT2 = Integer.valueOf(1000);//在初始化階段<clinit>()中賦值public static final String s0 = "helloworld0";//在鏈接階段的準備環節賦值public static final String s1 = new String("helloworld1");//在初始化階段<clinit>()中賦值public static String s2 = "helloworld2";public static final int NUM1 = new Random().nextInt(10);//在初始化階段<clinit>()中賦值 }

2）<clinit>()的線程安全性

對于<clinit>() 方法的調用，也就是類的初始化，虛擬機會在內部確保其多線程環境中的安全性

虛擬機會保證一個類的<clinit>()方法在多線程環境中被正確地加鎖、同步，如果多個線程同時去初始化一個類，那么只會有一個線程去執行這個類的<clinit>()方法，其他線程都需要阻塞等待，直到活動線程執行<clinit>()方法完畢

正是因為函數<clinit>()帶鎖線程安全的，因此，如果一個在類的<clinit>()方法中有耗時很長的操作，就可能造成多個線程阻塞，引發死鎖。并且這種死鎖是很難發現的，因為看起來它們并沒有可用的鎖信息

如果之前的線程成功加載了類，則等在隊列中的線程就沒有機會再執行<clinit>()方法了。那么，當需要使用這個類時，虛擬機會直接返回給它已經準備好的信息

3）類的初始化情況：主動使用vs被動使用

-XX:TraceClassLoading //如果針對代碼，設置參數 -XX:+TraceClassLoading，可以追蹤類的加載信息并打印出來

Java 程序對類的使用分為兩種：主動使用 和 被動使用

①主動使用

Class 只有在必須要首次使用的時候才會被裝載，Java 虛擬機不會無條件地裝載 Class 類型。Java 虛擬機規定，一個類或接口在初次使用前，必須要進行初始化。這里指的"使用"，是指主動使用，主動使用只有下列幾種情況：(即：如果出現如下的情況，則會對類進行初始化操作。而初始化操作之前的加載、驗證、準備已經完成)

1.當創建一個類的實例時，比如使用 new 關鍵字，或者通過反射、克隆、反序列化

2.當調用類的靜態方法時，即當使用了字節碼 invokestatic 指令

3.當使用類、接口的靜態字段時(final 修飾特殊考慮)，比如，使用 getstatic 或者 putsttic 指令。(對應訪問變量、賦值變量操作)

4.當使用 java.lang.reflect 包中的方法反射類的方法時。比如：Class.forname("com.atguigu.java.Test")

5.當初始化子類時，如果發現其分類還沒有進行過初始化，則需要先觸發其父類的初始化

6.如果一個接口定義了 default 方法，那么直接實現或者間接實現該接口的類的初始化，該接口要在其之前被初始化

7.當虛擬機啟動時，用戶需要指定一個要執行的主類(包含 main() 方法的那個類)，虛擬機會先初始化這個主類

8.當初次調用 MethodHandle 實例時，初始化該 MethodHandle 指向的方法所在的類。(涉及解析 REF_getStatic、REF_putStatic、REF_invokeStatic 方法句柄對應的類)（8了解，掌握以上7點即可）

針對5，說明

當 Java 虛擬機初始化一個類時，要求它的所有父類都已經被初始化，但是這條規則并不適用于接口

在初始化一個類時，并不會先初始化它所實現的接口

在初始化一個接口時，并不會先初始化它的父接口

因此，一個父接口并不會因為它的子接口或者實現類的初始化而初始化，只有當程序首次使用特定接口的靜態字段時，才會導致該接口的初始化

針對7，說明

JVM 啟動的時候通過引導類加載器加載一個初始類。這個類在調用 public static void main(String[]) 方法之前被鏈接和初始化。這個方法的執行將依次導致所需的類的加載、鏈接和初始化

②被動使用

除了以上的情況屬于主動使用，其他的情況均屬于被動使用。被動使用不會引起類的初始化

也就是說：并不是在代碼中出現的類，就一定會被加載或者初始化。如果不符合主動使用的條件，類就不會初始化

1.當訪問一個靜態字段時，只有真正聲明這個字段的類才會被初始化

• 當通過子類引用父類的靜態變量，不會導致子類初始化

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

Parent[] parents = new Parent[10]; //不會觸發Parent類的初始化，但會加載Parent類parents[0] = new Parent(); //給數組元素賦值時，才開始加載Parent類

3.引用變量不會觸發此類或接口的初始化。因為常量在鏈接階段就已經被顯式賦值了

4.調用 ClassLoader 類的 loadClass() 方法加載一個類，并不是對類的主動使用，不會導致類的初始化

5，Using

任何一個類型在使用之前都必須經歷過完整的加載、鏈接和初始化3個類加載步驟。一旦一個類型成功經歷過這3個步驟之后，便“萬事俱備，只欠東風”，就等著開發者使用了。

開發人員可以在程序中訪問和調用它的靜態類成員信息（比如:靜態字段、靜態方法)），或者使用new關鍵字為其創建對象實例。

6，Unloading

1）類、類的加載器、類的實例之間的引用關系

在類加載器的內部實現中，用一個 Java 集合來存放所加載類的引用。另一方面，一個 Class 對象總是會引用它的類加載器，調用 Class 對象的 getClassLoader() 方法，就能獲得它的類加載器。由此可見，代表某個類的 Class 實例與其類的加載器之間為雙向關聯關系

一個類的實例總是引用代表這個類的 Class 對象。在 Object 類中定義了 getClass() 方法，這個方法返回代表對象所屬類的 Class 對象的引用。此外，所有的 Java 類都有一個靜態屬性 Class，它引用代表這個類的 Class 對象

2）類的生命周期

當 Sample 類被加載、鏈接和初始化后，它的生命周期就開始了。當代表 Sample 類的 Class 對象不再被引用，即不可觸及時，Class 對象就會結束生命周期，Sample 類在方法區內的數據也會被卸載，從而結束 Sample 類的生命周期

一個類何時結束生命周期，取決于代表它的 Class 對象何時結束生命周期

3）具體例子

Loader1 變量和 obj 變量間接應用代表 Sample 類的 Class 對象，而 objClass 變量則直接引用它

如果程序運行過程中，將上圖左側三個引用變量都置為 null，此時 Sample 對象結束生命周期，MyClassLoader 對象結束生命周期，代表 Sample 類的 Class 對象也結束生命周期，Sample 類在方法區內的二進制數據被卸載

當再次有需要時，會檢查 Sample 類的 Class 對象是否存在，如果存在會直接使用，不再重新加載；如果不存在 Sample 類會被重新加載，在 Java 虛擬機的堆區會生成一個新的代表 Sample 類的 Class 實例(可以通過哈希碼查看是否是同一個實例)

4）類的卸載

啟動類加載器加載的類型在整個運行期間是不可能被卸載的(JVM 和 JSL 規范)

被系統類加載器和擴展類加載器加載的類型在運行期間不太可能被卸載，因為系統類加載器實例或者擴展類的實例基本上在整個運行期間總能直接或者間接的訪問的到，其達到 unreachable 的可能性極小

被開發者自定義的類加載器實例加載的類型只有在很簡單的上下文環境中才能被卸載，而且一般還要借助于強制調用虛擬機的垃圾收集功能才可以做到。可以預想，稍微復雜點的應用場景(比如：很多時候用戶在開發自定義類的加載器實例的時候采用緩存的策略以提高系統性能)，被加載的類型在運行期間也是幾乎不太可能被卸載的(至少卸載的時間是不確定的)

綜合以上三點，一個已經加載的類型被卸載的幾率很小至少被卸載的時間是不確定的。同時我們可以看的出來，開發者在開發代碼時候，不應該以虛擬機的類型卸載為前提，去實現系統中的特定功能。

5）方法區的垃圾回收

方法區的垃圾收集主要回收兩部分內容：常量池中廢棄的常量和不再使用的類型

HotSpot 虛擬機對常量池的回收策略是很明確的，只要常量池中的常量沒有被任何地方引用，就可以被回收

判定一個常量是否"廢棄"還是相對簡單，而要判定一個類型是否屬于"不再被使用的類"的條件就比較苛刻了。需要同時滿足下面三個條件：

①該類所有的實例都已經被回收。也就是 Java 堆中不存在該類及其任何派生子類的實例

②加載該類的類加載器已經被回收。這個條件除非是經過精心設計的可替換類加載器的場景，如 OSGI、JSP 的重加載等，否則通常是很難達成的

③該類對應的 java.lang.Class 對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法

Java 虛擬機被允許對滿足上述三個條件的無用類進行回收，這里說的僅僅是"被允許"，而并不是和對象一樣，沒有引用了就必然會回收

二，深入類的加載器

1，概述

類加載器是 JVM 執行類加載機制的前提

ClassLoader 的作用：

ClassLoader 是 Java 的核心組件，所有的 Class 都是由 ClassLoader 進行加載的，ClassLoader 負責通過各種方式將 Class 信息的二進制數據流讀入 JVM 內部，轉換為一個與目標類對應的 java.lang.Class 對象實例。然后交給 Java 虛擬機盡心鏈接、初始化等操作。因此，ClassLoader 在整個裝載階段，只能影響到類的加載，而無法通過 ClassLoader 去改變類的鏈接和初始化行為。至于它是否可以運行，則由 Execution Engine 決定。

類加載器最早出現在 Java 1.0 版本中，那個時候只是單純地為了滿足 Java Applet 應用而被研發出來，但如今類加載器卻在 OSGI、字節碼加解密領域大放異彩。

這主要歸功于 Java 虛擬機的設計者們當初在設計類加載器的時候，并沒有考慮將它綁定在 JVM 內部，這樣做的好處就是能夠更加靈活和動態地執行類加載操作。

1）類加載的分類

類的加載分類：顯式加載 vs 隱式加載

Class 文件的顯式加載與隱式加載的方式是指 JVM 加載 Class 文件到內存的方式

顯式加載指的是在代碼中通過調用 ClassLoader 加載 Class 對象，如直接使用 Class.forName(name) 或 this.getClass().getClassLoader().loadClass() 加載 Class對象

隱式加載則是不直接在代碼中調用 ClassLoader 的方法加載 Class 對象，而是通過虛擬機自動加載到內存中，如在加載某個類的 Class 文件時，該類的 Class 文件中引用了另外一個類的對象，此時額外引用的類將通過 JVM 自動加載到內存中。

在日常開發中以上兩種方式一般會混合使用。

2）類加載的必要性

一般情況下，Java 開發人員并不需要在程序中顯式地使用類加載器，但是了解類加載器的加載機制卻顯得至關重要。從以下幾個方面說：

• 避免在開發中遇到 java.lang.ClassNotFoundException 異常或 java.lang.NoClassDeFoundError 異常時手足無措。只有了解類加載器的加載機制才能夠在出現異常的時候快速地根據錯誤異常日志定位問題和解決問題

• 需要支持類的動態加載或需要對編譯后的字節碼文件進行加解密操作時，就需要與類加載器打交道了

• 開發人員可以在程序中編寫自定義類加載器來重新定義類的加載規則，以便實現一些自定義的處理邏輯

3）命名空間

①何為類的唯一性？

對于任意一個類，都需要由加載它的類加載器和這個類本身一同確認其在 Java 虛擬機中的唯一性。每一個類加載器，都擁有一個獨立的類名稱空間：比較兩個類是否相等，只有在這兩個類是由同一個類加載器加載的前提下才有意義。否則，即使這兩個類源自同一個 Class 文件，被同一個虛擬機加載，只要加載他們的類加載器不同，那這兩個類就必定不相等

②命名空間

• 每個類加載器都有自己的命名空間，命名空間由該加載器以及所有的父加載器所加載的類組成
• 在同一命名空間中，不會出現類的完整名字(包括類的包名)相同的兩個類
• 在不同的命名空間中，有可能會出現類的完整名字(包括類的包名)相同的兩個類

在大型應用中，我們往往借助這一特性，來運行同一個類的不同版本。

4）類加載機制的基本特征

• 雙親委派模型。但不是所有類加載都遵守這個模型，有的時候，啟動類加載器所加載的類型，是可能要加載用戶代碼的，比如 JDK 內部的 ServiceProvider/ServiceLoader 機制，用戶可以在標準 API 框架上，提供自己的實現，JDK 也需要提供些默認的參考實現。例如，Java 中 JNDI、JDBC、文件系統、Cipher 等很多方面，都是利用的這種機制，這種情況就不會用雙親委派模型去加載，而是利用所謂的上下文加載器

• 可見性，子類加載器可以訪問父加載器加載的類型，但是反過來是不允許的。不然，因為缺少必要的隔離，我們就沒有辦法利用類加載器去實現容器的邏輯

• 單一性，由于父加載器的類型對于子加載器是可見的，所以父加載器中加載過的類型，就不會在子加載器中重復加載。但是注意，類加載器"鄰居"間，同一類型仍然可以被加載多次，因為相互并不可見

2,類加載器分類

JVM 支持兩種類型的類加載器，分別為引導類加載器(Bootstrap ClassLoader)和自定義類加載器(User-Defined ClassLoader)

從概念上來講，自定義類加載器一般指的是程序中由開發人員自定義的一類類加載器，但是 Java 虛擬機規范卻沒有這么定義，而是將所有派生于抽象類 ClassLoader 的類加載器都劃分為自定義類加載器。無論類加載器的類型如何劃分，在程序中我們最常見的類加載器結構主要是如下情況：

• 除了頂層的啟動類加載器外，其余的類加載器都應當有自己的"父類"加載器
• 不同類加載器看似是繼承(Inheritance)關系，實際上是包含關系。在下層加載器中，包含著上層加載器的引用

“父類加載器”并非下層加載器extends上層加載器，而且包含了上層加載器的引用。

具體代碼

class ClassLoader {ClassLoader parent; //父類加載器public ClassLoader(ClassLoader parent) {this.parent = parent;} }class ParentClassLoader extends ClassLoader {public ParentClassLoader(ClassLoader parent) {super(parent);} }class ChildClassLoader extends ClassLoader {public ChildClassLoader(ClassLoader parent) { //parent = new ParentClassLoader();super(parent);} }

1）Bootstrap ClassLoader

• 這個類加載使用 C/C++ 語言實現的，嵌套在 JVM 內部
• 它用來加載 Java 的核心庫(JAVA_HOME/jre/lib/rt.jar 或 sun.boot.class.path 路徑下的內容)。用于提供 JVM 自身需要的類
• 并不繼承自 java.lang.ClassLoader，沒有父加載器
• 出于安全考慮，Bootstrap 啟動類加載器之加載包名為 java、javax、sun 等開頭的類
• 加載擴展類和應用程序類加載器，并指定為他們的父類加載器。

使用 -XX:+TraceClassLoading 參數

啟動類加載器使用 C++ 編寫的？Yes！

C/C++：指針函數 & 函數指針、C++ 支持多繼承、更加高效

Java ：由 C++ 演變而來，(C++)-- 版，單繼承

2）Extension ClassLoader

Java 語言編寫，由 sun.misc.Launcher$ExtClassLoader 實現

繼承于 ClassLoader 類

父類加載器為啟動類加載器

從 java.ext.dirs 系統屬性所指定的目錄中加載類庫，或從 JDK 的安裝目錄的 jre/lib/ext 子目錄下加載類庫。如果用戶創建的 JAR 放在此目錄下，也會自動由擴展類加載器加載

3）AppClassLoader

• Java 語言編寫，由 sun.misc.Launcher$AppClassLoader 實現
• 繼承于 ClassLoader 類
• 父類加載器為擴展類加載器
• 它負責加載環境變量 classpath 或系統屬性 java.class.path 指定路徑下的類庫
• 應用程序中的類加載器默認是系統類加載器
• 它是用戶自定義類加載器的默認父加載器
• 通過 ClassLoader 的 getSystemClassLoader() 方法可以獲取到該類加載器

4）User DIY ClassLoader

• 在 Java 的日常應用程序開發中，類的加載幾乎是由上述3種類加載器相互配合執行的。在必要時，我們還可以自定義類加載器，來定制類的加載方式
• 體現 Java 語言強大生命力和巨大魅力的關鍵因素之一便是，Java 開發者可以自定義類加載器來實現類庫的動態加載，加載源可以是本地的 JAR 包，也可以是網絡上的遠程資源
• 通過類加載器可以實現非常絕妙的插件機制，這方面的實際應用案例不勝枚舉。例如，著名的 OSGI 組件框架，再如 Eclipse 的插件機制。類加載器為應用程序提供了一種動態增加新功能的機制，這種機制無需重新打包發布應用程序就能實現
• 同時，自定義加載器能夠實現應用隔離，例如 Tomcat、Spring 等中間件和組件框架都在內部實現了自定義的加載器，并通過自定義加載器隔離不同的組件模塊。這種機制比 C/C++ 程序要好太多，想不修改 C/C++ 程序就能為其新增功能，幾乎是不可能的，僅僅一個兼容性便能阻擋所有美好的設想
• 自定義類加載器通常需要繼承于 ClassLoader

3，測試不同的類加載器

每個 Class 對象都會包含一個定義它的 ClassLoader 的一個引用

獲取 ClassLoader 的途徑

說明：
站在程序的角度看，引導類加載器與另外兩種類加載器(系統類加載器和擴展類加載器)并不是同一個層次意義上的加載器，引導類加載器是使用 C++ 語言編寫而成的，而另外兩種類加載器則是使用 Java 語言編寫的。由于引導類加載器壓根兒就不是一個 Java 類，因此在 Java 程序中只能打印出空值

數組類的 Class 對象，不是由類加載器去創建的，而是在 Java 運行期 JVM 根據需要自動創建的。對于數組類的類加載器來說，是通過 Class.geetClassLoader() 返回的，與數組當中元素類型的類加載器是一樣的：如果數組當中的元素類型是基本數據類型，數組類是沒有類加載器的

String[] strArr = new String[6]; System.out.println(strArr.getClass().getClassLoader()); //運行結果：nullClassLoaderTest[] test = new ClassLoaderTest[1]; System.out.println(test.getClass().getClassLoader()); //運行結果：sun.misc.Launcher$AppClassLoader@18b4aac2int[] inst = new int[2]; System.out.println(inst.getClass().getClassLoader()); //運行結果：null

4，ClassLoader源碼解析

ClassLoader 與現有類加載的關系：

除了以上虛擬機自帶的加載器外，用戶還可以定制自己的類加載器。Java 提供了抽象類 java.lang.ClassLoader，所有用戶自定義的類加載器都應該繼承 ClassLoader 類。

1）ClassLoader的主要方法

public final ClassLoader getParent()返回該類加載器的超類加載器

public Class<?> loadClass(String name) throws ClassNotFoundException加載名稱為name的類，返回結果為java.lang.Class類的實例。如果找不到類，則返回ClassNotFoundException異常。

該方法中的邏輯就是雙親委派模式的實現。

protected Class<?> findClass(String name) throws ClassNotFoundException查找二進制名稱為name的類，返回結果為java.lang.Class類的實例。這是一個受保護的方法，JVM鼓勵我們重寫此方法，需要自定義加載器遵循雙親委托機制，該方法會在檢查完父類加載器之后被loadClass()方法調用。

在JDK1.2之前，在自定義類加載時，總會去繼承ClassLoader類并重寫loadClass方法，從而實現自定義的類加載類。但是在JDK1.2之后已不再建議用戶去覆蓋loadClass()方法，而是建議把自定義的類加載邏輯寫在findClass()方法中，從前面的分析可知， findClass()方法是在loadClass()方法中被調用的，當loadClass()方法中父加載器加載失敗后，則會調用自己的findClass()方法來完成類加載，這樣就可以保證自定義的類加載器也符合雙親委托模式。需要注意的是ClassLoader類中并沒有實現findClass()方法的具體代碼邏輯，取而代之的是拋出ClassNotFoundException異常，同時應該知道的是findClass方法通常是和defineClass方法一起使用的。一般情況下，在自定義類加載器時，會直接覆蓋ClassLoader的findClass()方法并編寫加載規則，取得要加載類的字節碼后轉換成流，然后調用defineClass()方法生成類的Class對象。

protected final Class<?> defineClass(byte[] b, int off, int len)根據給定的字節數組b轉換為Class的實例，off和len參數表示實際Class信息在byte數組中的位置和長度，其中byte數組b是ClassLoader從外部獲取的。這是受保護的方法，只有在自定義ClassLoader子類中可以使用。

defineClass()方法是用來將byte字節流解析成JVM能夠識別的Class對象(ClassLoader中已實現該方法邏輯)，通過這個方法不僅能夠通過class文件實例化class對象，也可以通過其他方式實例化class對象，如通過網絡接收一個類的字節碼，然后轉換為byte字節流創建對應的Class對象。
defineClass()方法通常與findClass()方法一起使用，一般情況下，在自定義類加載器時，會直接覆蓋ClassLoader的findClass()方法并編寫加載規則，取得要加載類的字節碼后轉換成流，然后調用defineClass()方法生成類的Class對象。

/*** 編寫findClass方法的邏輯*/@Overrideprotected Class<?> findClass(String name) throws ClassNotFoundException {// 獲取類的class文件字節數組byte[] classData = getClassData(name);if (classData == null) {throw new ClassNotFoundException();} else {//直接生成class對象return defineClass(name, classData, 0, classData.length);}}

protected final void resolveClass(Class<?> c)鏈接指定的一個Java類。使用該方法可以使用類的Class對象創建完成的同時也被解析(即加載的同時也進行解析)。前面我們說鏈接階段主要是對字節碼進行驗證，為類變量分配內存并設置初始值同時將字節碼文件中的符號引用轉換為直接引用。

protected final Class<?> findLoadedClass(String name)查找名稱為name的已經被加載過的類，返回結果為java.lang.Class類的實例。這個方法是final方法，無法被修改。

private final ClassLoader parent它也是一個ClassLoader的實例，這個字段所表示的ClassLoader也稱為這個ClassLoader的雙親。在類加載的過程中,ClassLoader可能會將某些請求交予自己的雙親處理。

①loadClass()的剖析

測試代碼

ClassLoader.getSystemClassLoader().loadClass("com.atguig.java.User");

涉及到對如下方法的調用

protected Class<?> loadClass(String name, boolean resolve)//resolve:true-加載class的同時進行解析操作。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 {//parent為null:父類加載器是引導類加教器c = findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c == null) {//當前類的加載器的父類加載器未加載此類or此類的加載器未加載此類// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();//調用當前ClassLoader的findClass()c = findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) { //是否進行解析操作resolveClass(c);}return c;} }

2）SecureClassLoader與URLClassLoader

接著SecureClassLoader擴展了ClassLoader，新增了幾個與使用相關的代碼源(對代碼源的位置及其證書的驗證)和權限定義類驗證(主要指對class源碼的訪問權限)的方法，一般我們不會直接跟這個類打交道，更多是與它的子類URLClassLoader有所關聯。

前面說過，ClassLoader是一個抽象類，很多方法是空的沒有實現，比如 findClass()、findResource()等。而URLClassLoader這個實現類為這些方法提供了具體的實現。并新增了URLClassPath類協助取得Class字節碼流等功能。在編寫自定義類加載器時，如果沒有太過于復雜的需求，可以直接繼承URLClassLoader類，這樣就可以避免自己去編寫findClass()方法及其獲取字節碼流的方式，使自定義類加載器編寫更加簡潔。

3）ExtClassLoader與AppClassLoader

了解完URLClassLoader后接著看看剩余的兩個類加載器，即拓展類加載器ExtClassLoader和系統類加載AppClassLoader，這兩個類都繼承自URLClassLoader，是sun.misc.Launcher的靜態內部類。

sun.misc.Launcher主要被系統用于啟動主應用程序，ExtClassLoader和AppClassLoader都是由sun.misc.Launcher創建的，其類主要類結構如下:

我們發現ExtClassLoader并沒有重寫loadClass()方法，這足矣說明其遵循雙親委派模式，而AppClassLoader重載了loadclass()方法，但最終調用的還是父類loadClass()方法，因此依然遵守雙親委派模式。

4）Class.forName與ClassLoader.loadClass()

Class.forName():是一個靜態方法,最常用的是Class.forName(String className);根據傳入的類的全限定名返回一個Class對象。該方法在將Class文件加載到內存的同時,會執行類的初始化。
如:Class.forName( "com.atguigu.java.Helloworld") ;

ClassLoader.loadClass():這是一個實例方法,需要一個ClassLoader對象來調用該方法。該方法將class文件加載到內存時,并不會執行類的初始化,直到這個類第一次使用時才進行初始化。該方法因為需要得到個ClassLoader對象,所以可以根據需要指定使用哪個類加載器.如: ClassLoader cl=......;
cl.loadClass ("com.atguigu.java.Helloworld" );

5,雙親委派模型

1)定義與本質

類加載器用來把類加載到Java虛擬機中。從JDK1.2版本開始，類的加載過程采用雙親委派機制，這種機制能更好地保證java平臺的安全。

①定義

如果一個類加載器在接到加載類的請求時，它首先不會自己嘗試去加載這個類，而是把這個請求任務委托給父類加載器去完成，依次遞歸，如果父類加載器可以完成類加載任務，就成功返回。只有父類加載器無法完成此加載任務時，才自己去加載。

②本質

規定了類加載的順序是:引導類加載器先加載，若加載不到，由擴展類加載器加載，若還加載不到，才會由系統類加載器或自定義的類加載器進行加載。

2）優勢與劣勢

①雙親委派機制優勢

避免類的重復加載，確保一個類的全局唯一性

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

保護程序安全，防止核心API被隨意篡改

②代碼支持

雙親委派機制在java.lang.ClassLoader.loadClass(String,boolean)接口中體現。該接口的邏輯如下:

(1)先在當前加載器的緩存中查找有無目標類，如果有，直接返回。

(2)判斷當前加載器的父加載器是否為空，如果不為空，則調用parent.loadClass(name，false)接口進行加載。

(3)反之，如果當前加載器的父類加載器為空，則調用findBootstrapClassOrNull(name)接口，讓引導類加載器進加載。

(4)如果通過以上3條路徑都沒能成功加載，則調用findClass(name)接口進行加載。該接口最終會調用java.lang.ClassLoader接口的defineClass系列的native接口加載目標Java類。

雙親委派的模型就隱藏在這第2和第3步中。

③舉例

假設當前加載的是java.lang.Object這個類，很顯然，該類屬于JDK中核心得不能再核心的一個類，因此一定只能由引導類加載器進行加載。當JVM準備加載java.lang.Object時，JVM默認會使用系統類加載器去加載，按照上面4步加載的邏輯，在第1步從系統類的緩存中肯定查找不到該類，于是進入第2步。由于從系統類加載器的父加載器是擴展類加載器，于是擴展類加載器繼續從第1步開始重復。由于擴展類加載器的緩存中也一定查找不到該類，因此進入第2步。擴展類的父加載器是null,因此系統調用findClass(String)，最終通過引導類加載器進行加載。

④思考

如果在自定義的類加載器中重寫java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String, boolean)方法,抹去其中的雙親委派機制,僅保留上面這4步中的第1步與第4步，那么是不是就能夠加載核心類庫了呢?

這也不行!因為JDK還為核心類庫提供了一層保護機制。不管是自定義的類加載器，還是系統類加載器還是擴展類加載器，最終都必須調用java.lang.classLoader.defineClass(String,byte[], int, int, ProtectionDomain)方法，而該方法會執行preDefineClass()接口，該接口中提供了對JDK核心類庫的保護。

⑤雙親委托模式的弊端

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

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

⑥結論:

由于Java虛擬機規范并沒有明確要求類加載器的加載機制一定要使用雙親委派模型，只是建議采用這種方式而己。

比如在Tomcat中，類加載器所采用的加載機制就和傳統的雙親委派模型有一定區別，當缺省的類加載器接收到一個類的加載任務時，首先會由它自行加載，當它加載失敗時，才會將類的加載任務委派給它的超類加載器去執行，這同時也是Servlet規范推薦的一種做法。

3）破壞雙親委派機制

①破壞雙親委派機制1

雙親委派模型并不是一個具有強制性約束的模型，而是Java設計者推薦給開發者們的類加載器實現方式。

在Java的世界中大部分的類加載器都遵循這個模型，但也有例外的情況，直到Java模塊化出現為止，雙親委派模型主要出現過3次較大規模“被破壞”的情況。

第一次破壞雙親委派機制:

雙親委派模型的第一次“被破壞”其實發生在雙親委派模型出現之前–即JDK1.2面世以前的“遠古”時代。

由于雙親委派模型在JDK 1.2之后才被引入，但是類加載器的概念和抽象類java.lang.ClassLoader則在Java的第一個版本中就已經存在，面對已經存在的用戶自定義類加載器的代碼，Java設計者們引入雙親委派模型時不得不做出一些妥協，為了兼容這些已有代碼，無法再以技術手段避免loadClass()被子類覆蓋的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一個新的protected方法findClass()，并引導用戶編寫的類加載邏輯時盡可能去重寫這個方法，而不是在loadClass()中編寫代碼。上節我們已經分析過loadClass()方法，雙親委派的具體邏輯就實現在這里面，按照loadClass()方法的邏輯，如果父類加載失敗，會自動調用自己的findClass()方法來完成加載，這樣既不影響用戶按照自己的意愿去加載類，又可以保證新寫出來的類加載器是符合雙親委派規則的。

②破壞雙親委派機制2

第二次破壞雙親委派機制:線程上下文類加載器

雙親委派模型的第二次“被破壞”是由這個模型自身的缺陷導致的，雙親委派很好地解決了各個類加載器協作時基礎類型的一致性問題〈越基礎的類由越上層的加載器進行加載），基礎類型之所以被稱為“基礎”，是因為它們總是作為被用戶代碼繼承、調用的API存在，但程序設計往往沒有絕對不變的完美規則，如果有基礎類型又要調用回用戶的代碼,那該怎么辦呢?

這并非是不可能出現的事情，一個典型的例子便是JNDI服務，JNDI現在已經是Java的標準服務，它的代碼由啟動類加載器來完成加載（在JDK 1.3時加入到rt.jar的)，肯定屬于Java中很基礎的類型了。但JNDI存在的目的就是對資源進行查找和集中管理，它需要調用由其他廠商實現并部署在應用程序的ClassPath下的NDI服務提供者接口（Service Provider Interface，SPI）的代碼，現在問題來了，啟動類加載器是絕不可能認識、加載這些代碼的，那該怎么辦?(SPI:在Java平臺中，通常把核心類rt.jar中提供外部服務、可由應用層自行實現的接口稱為SPI)

為了解決這個困境，Java的設計團隊只好引入了一個不太優雅的設計:線程上下文類加載器（Thread ContextClassLoader)。這個類加載器可以通過java.lang.Thread類的setContextClassLoader()方法進行設置，如果創建線程時還未設置，它將會從父線程中繼承一個，如果在應用程序的全局范圍內都沒有設置過的話，那這個類加載器默認就是應用程序類加載器。

有了線程上下文類加載器，程序就可以做一些“舞弊”的事情了。JNDI服務使用這個線程上下文類加載器去加載所需的SPI服務代碼，這是一種父類加載器去請求子類加載器完成類加載的行為，這種行為實際上是打通了雙親委派模型的層次結構來逆向使用類加載器，已經違背了雙親委派模型的一般性原則，但也是無可奈何的事情。Java中涉及SPI的加載基本上都采用這種方式來完成，例如NDI、JDBC、JCE、JAXB和BT等。不過，當SPI的服務提供者多于一個的時候，代碼就只能根據具體提供者的類型來硬編碼判斷，為了消除這種極不優雅的實現方式，在JDK 6時，JDK提供了java.util.ServiceLoader類，以META-INF/services中的配置信息，輔以責任鏈模式，這才算是給SPI的加載提供了一種相對合理的解決方案。

默認上下文加載器就是應用類加載器，這樣以上下文加載器為中介，使得啟動類加載器中的代碼也可以訪問應用類加載器中的類。

③破壞雙親委派機制3

第三次破壞雙親委派機制:

雙親委派模型的第三次“被破壞”是由于用戶對程序動態性的追求而導致的。如:代碼熱替換（Hot Swap)、模塊熱部署（Hot Deployment）等

IBM公司主導的JSR-291(即OSGi R4.2）實現模塊化熱部署的關鍵是它自定義的類加載器機制的實現，每一個程序模塊（OSGi中稱為Bundle)都有一個自己的類加載器，當需要更換一個Bundle時，就把Bundle連同類加載器一起換掉以實現代碼的熱替換。在OSGi環境下，類加載器不再雙親委派模型推薦的樹狀結構，而是進一步發展為更加復雜的網狀結構。

當收到類加載請求時，OSGi將按照下面的順序進行類搜索:（不細講）

1）將以java.*開頭的類，委派給父類加載器加載。

2）否則，將委派列表名單內的類，委派給父類加載器加載。

3）否則，將Import列表中的類，委派給Export這個類的Bundle的類加載器加載。

4）否則，查找當前Bundle的ClassPath，使用自己的類加載器加載。

5）否則，查找類是否在自己的Fragment Bundle中，如果在，則委派給Fragment Bundle的類加載器加載。

6）否則，查找Dynamic Import列表的Bundle，委派給對應Bundle的類加載器加載。

7）否則，類查找失敗。

說明:只有開頭兩點仍然符合雙親委派模型的原則，其余的類查找都是在平級的類加載器中進行的

小結:

這里，我們使用了“被破壞”這個詞來形容上述不符合雙親委派模型原則的行為，但這里“被破壞”并不一定是帶有貶義的。只要有明確的目的和充分的理由，突破舊有原則無疑是一種創新。

正如:OSGi中的類加載器的設計不符合傳統的雙親委派的類加載器架構，且業界對其為了實現熱部署而帶來的額外的高復雜度還存在不少爭議，但對這方面有了解的技術人員基本還是能達成一個共識，認為OSGi中對類加載器的運用是值得學習的，完全弄懂了OSGi的實現，就算是掌握了類加載器的精粹。

4）熱替換的實現

熱替換是指在程序的運行過程中，不停止服務，只通過替換程序文件來修改程序的行為。熱替換的關鍵需求在于服務不能中斷，修改必須立即表現正在運行的系統之中。基本上大部分腳本語言都是天生支持熱替換的，比如: PHP，只要替換了PHP源文件，這種改動就會立即生效，而無需重啟Web服務器。

但對Java來說，熱替換并非天生就支持，如果一個類已經加載到系統中，通過修改類文件，并無法讓系統再來加載并重新定義這個類。因此，在Java中實現這一功能的一個可行的方法就是靈活運用ClassLoader。

注意:由不同ClassLoader加載的同名類屬于不同的類型，不能相互轉換和兼容。即兩個不同的ClassLoader加載同個類，在虛擬機內部，會認為這2個類是完全不同的。

根據這個特點，可以用來模擬熱替換的實現，基本思路如下圖所示:

6，沙箱安全機制

• 保護程序安全
• 保護 Java 原生的 JDK 代碼

Java 安全模型的核心就是 Java 沙箱(Sandbox)。什么是沙箱？沙箱就是一個限制程序運行的環境

沙箱機制就是將 Java 代碼限定在虛擬機(JVM)特定的運行范圍中，并且嚴格限制代碼對本地系統資源訪問。通過這樣的措施來保證對代碼的有限隔離，防止對本地系統造成破壞

沙箱主要限制系統資源訪問，那系統資源包括什么？CPU、內存、文件系統、網絡。不同級別的沙箱對這些資源訪問的限制也可以不一樣

所有的 Java 程序運行都可以指定沙箱，可以定制安全策略

1）JDK1.0時期

在Java中將執行程序分成本地代碼和遠程代碼兩種，本地代碼默認視為可信任的，而遠程代碼則被看作是不受信的。對于授信的本地代碼，可以訪問一切本地資源。而對于非授信的遠程代碼在早期的Java實現中，安全依賴于沙箱（Sandbox）機制。如下圖所示JDK1.0安全模型

2）JDK1.1時期

JDK1.0中如此嚴格的安全機制也給程序的功能擴展帶來障礙，比如當用戶希望遠程代碼訪問本地系統的文件時候，就無法實現。

因此在后續的Java1.1版本中，針對安全機制做了改進，增加了安全策略。允許用戶指定代碼對本地資源的訪問權限。如下圖所示JDK1.1安全模型

3）JDK1.2時期

在Java1.2版本中，再次改進了安全機制，增加了代碼簽名。不論本地代碼或是遠程代碼，都會按照用戶的安全策略設定，由類加載器加載到虛擬機中權限不同的運行空間，來實現差異化的代碼執行權限控制。如下圖所示JDK1.2安全模型

4）JDK1.6時期

虛擬機會把所有代碼加載到不同的系統域和應用域。系統域部分專門負責與關鍵資源進行交互，而各個應用域部分則通過系統域的部分代理來對各種需要的資源進行訪問。虛擬機中不同的受保護域(Protected Domain)，對應不一樣的權限（Permission)。存在于不同域中的類文件就具有了當前域的全部權限，如下圖所示，最新的安全模型（jdk1.6)

7，自定義類加載器

1）為什么要自定義類加載器?

• 隔離加載類

在某些框架內進行中間件與應用的模塊隔離，把類加載到不同的環境。比如:阿里內某容器框架通過自定義類加載器確保應用中依賴的jar包不會影響到中間件運行時使用的jar包。再比如: Tomcat這類web應用服務器，內部自定義了好幾種類加載器，用于隔離同一個web應用服務器上的不同應用程序。（類的仲裁–>類沖突）
修改類加載的方式

類的加載模型并非強制，除Bootstrap外，其他的加載并非一定要引入，或者根據實際情況在某個時間點進行按需進行動態加載

• 擴展加載源

比如從數據庫、網絡、甚至是電視機機頂盒進行加載

• 防止源碼泄漏

Java代碼容易被編譯和篡改，可以進行編譯加密。那么類加載也需要自定義，還原加密的字節碼。

2）常見的場景

• 實現類似進程內隔離，類加載器實際上用作不同的命名空間，以提供類似容器、模塊化的效果。例如，兩個模塊依賴于某個類庫的不同版本，如果分別被不同的容器加載，就可以互不干擾。這個方面的集大成者是Java EE和OSGI、JPMS等框架。

• 應用需要從不同的數據源獲取類定義信息，例如網絡數據源，而不是本地文件系統。或者是需要自己操縱字節碼，動態修改或者生成類型。

3）注意:

在一般情況下，使用不同的類加載器去加載不同的功能模塊，會提高應用程序的安全性。但是，如果涉及Java類型轉換，則加載器反而容易產生不美好的事情。在做Java類型轉換時，只有兩個類型都是由同一個加載器所加載，才能進行類型轉換，否則轉換時會發生異常。

4）實現方式

用戶通過定制自己的類加載器，這樣可以重新定義類的加載規則，以便實現一些自定義的處理邏輯。

①實現方式

Java提供了抽象類java.lang.ClassLoader，所有用戶自定義的類加載器都應該繼承ClassLoader類。

在自定義ClassLoader 的子類時候，我們常見的會有兩種做法:

• 方式一:重寫loadclass()方法
• 重寫findClass()方法【推薦】

②對比

這兩種方法本質上差不多，畢竟loadClass()也會調用findClass()，但是從邏輯上講我們最好不要直接修改loadClass()的內部邏輯。建議的做法是只在findClass()里重寫自定義類的加載方法，根據參數指定類的名字，返回對應的Class對象的引用。

• loadClass()這個方法是實現雙親委派模型邏輯的地方，擅自修改這個方法會導致模型被破壞，容易造成問題。因此我們最好是在雙親委派模型框架內進行小范圍的改動，不破壞原有的穩定結構。同時，也避免了自己重寫loadClass()方法的過程中必須寫雙親委托的重復代碼，從代碼的復用性來看，不直接修改這個方法始終是比較好的選擇。

• 當編寫好自定義類加載器后，便可以在程序中調用loadClass(）方法來實現類加載操作。

③說明

• 其父類加載器是系統類加載器

• JVM中的所有類加載都會使用java.lang.ClassLoader.loadClass(String)接口(自定義類加載器并重寫java.lang.ClassLoader.loadClass(String)接口的除外)，連JDK的核心類庫也不能例外。

8，Java9新特性

為了保證兼容性，JDK 9沒有從根本上改變三層類加載器架構和雙親委派模型，但為了模塊化系統的順利運行，仍然發生了一些值得被注意的變動。

1.擴展機制被移除，擴展類加載器由于向后兼容性的原因被保留，不過被重命名為平臺類加載器（platform classloader)。可以通過ClassLoader的新方法getPlatformClassLoader()來獲取。

JDK 9時基于模塊化進行構建（原來的 rt.jar 和 tools.jar 被拆分成數十個 JMOD 文件)，其中的Java類庫就已天然地滿足了可擴展的需求，那自然無須再保留<JAVA_HONE>\lib\ext 目錄，此前使用這個目錄或者 java.ext.dirs系統變量來擴展JDK功能的機制已經沒有繼續存在的價值了。

2.平臺類加載器和應用程序類加載器都不再繼承自 java.net.URLClassLoader。

現在啟動類加載器、平臺類加載器、應用程序類加載器全都繼承于jdk.internal.loader.BuiltinClassLoader。

如果有程序直接依賴了這種繼承關系，或者依賴了URLClassLoader類的特定方法，那代碼很可能會在 JDK9及更高版本的JDK中崩潰。

3.在Java 9中，類加載器有了名稱。該名稱在構造方法中指定，可以通過getName()方法來獲取。平臺類加載器的名稱是platform，應用類加載器的名稱是app。類加載器的名稱在調試與類加載器相關的問題時會非常有用。

4.啟動類加載器現在是在jvm內部和java類庫共同協作實現的類加載器〈以前是C++實現)，但為了與之前代碼兼容，在獲取啟動類加載器的場景中仍然會返回null，而不會得到BootClassLoader實例。

5.類加載的委派關系也發生了變動。

當平臺及應用程序類加載器收到類加載請求，在委派給父加載器加載前，要先判斷該類是否能夠歸屬到某一個系統模塊中，如果可以找到這樣的歸屬關系，就要優先委派給負責那個模塊的加載器完成加載。

在Java模塊化系統明確規定了三個類加載器負責各自加載的模塊。

總結

以上是生活随笔為你收集整理的JVM之类的加载与类加载器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。