類檔案的結構、JVM 的類載入過程、類載入機制、類載入器、雙親委派模型
阿新 • • 發佈：2020-09-06
# 一、類檔案的結構
我們都知道，各種不同平臺的虛擬機器，都支援 “位元組碼 Byte Code” 這種程式儲存格式，這構成了 Java 平臺無關性的基石。甚至現在平臺無關性也開始演變出 “語言無關性” ，就是其他語言也可以執行在 Java 虛擬機器之上，比如現在的 Kotlin、Scala 等。
實現語言無關性的基礎仍然是虛擬機器和位元組碼儲存格式，Java 虛擬機器步包括 Java 語言在內的任何語言繫結，他只和 “Class 檔案” 這種特定的二進位制檔案格式所關聯，Class 檔案中包含了 Java 虛擬機器指令集、符號表以及其他若干輔助資訊。
Java 的各種語法、關鍵字、常量變數和運算子號的語義最終都會由多條位元組碼指令組合來表達，這決定了位元組碼指令所能提供的語言描述能力必須比 Java 語言本身更強大才行。
jvm 提供的語言無關性如下圖所示：
接下來看詳細過程。
### 2.3.1 載入
注意啊，“載入”只是整個“類載入”中的一個階段。
載入階段，虛擬機器主要做三件事：
1. 通過一個類的全限定名來**獲取定義此類的二進位制位元組流**；
2. 將這個位元組流代表的靜態儲存結構轉化為方法區的執行時資料結構；
3. 在記憶體中生成一個代表這個類的 java.lang.Class 物件，作為方法區這個類的各種資料的訪問入口。
其中，第一點的來源可以是各種各樣，zip包，網路中，也可以利用動態代理技術在執行時計算生成。
第二點是要用到類載入器的，相對於五個階段的其他階段：
1. 非陣列型別的載入階段（就是當前階段）是可控性最強的，可以通過 jvm 內建的引導**類載入器**，也可以自定義**類載入器**，開發人員通過定義自己的類載入器去控制位元組流的獲取方式（重寫一個類載入器的 findClass() 或 loadClass() 方法）。
2. 陣列型別來說，陣列類不通過類載入器建立，而是由 jvm 直接在記憶體中動態構造出來，但是陣列的元素類本身最終還是要靠類載入器來完成載入，這個過程就是 jvm 把陣列降一個維度，然後決定繼續遞迴還是直接可以和類載入器關聯。
第三點就是如上面所說。
### 2.3.2 驗證（連線之 1 ）
驗證是連線階段的第一步，這一階段的目的是確保 Class 檔案的位元組流中包含的資訊符合《Java虛擬機器規範》的全部約束要求，保證這些資訊被當作程式碼執行後不會危害虛擬機器自身的安全。
為什麼要驗證？
結合上一個步驟，就是因為 Class 檔案不一定就是 java 原始碼編譯來的，可能是各種途徑，甚至是自己手敲的 01 碼，所以有必要驗證位元組碼。
一般驗證的內容分為四個：
1. **檔案格式驗證**：檢查位元組流是否符合 Class 檔案格式的規範，就是魔數啊、版本號之類的；
2. **元資料驗證**：上一步格式沒問題，然後對位元組碼描述的資訊進行語義分析，看類關係、欄位方法有沒有矛盾之類；
3. **位元組碼驗證**：最複雜的一步，通過資料流分析和控制流分析，確定程式語義合法、合邏輯，上一步資料型別等到沒問題，這一步就要進入方法體的邏輯分析；
4. **符號引用驗證**：發生在虛擬機器將符號引用轉化為直接引用的時候，轉化動作本身實在連線之3階段——解析階段發生的。（所以前面說這些順序只是開始順序，執行的時候是互相切換的），目的是驗證引用的類、欄位等內容是否能找到並訪問之類的。
驗證階段很重要，卻不一定必須執行，因為通過了驗證階段，後面對程式執行就沒有影響了，如果程式反覆被驗證和使用過就可以用引數關閉大部分的類驗證措施：
```
-Xverify: none
```
### 2.3.3 準備（連線之 2 ）
準備階段是**正式為類中定義的變數（即靜態變數，被 static 修飾的變數）分配記憶體、並設定類變數初始值**的階段。
從概念上講，這些變數所使用的記憶體都應當在方法區中進行分配，但**方法區本身是一個邏輯上的區域**。
> 在上一篇，jvm 的記憶體結構裡多次強調。在 JDK7及之前, HotSpot 使用永久代來實現方法區，所以還可以勉強把方法區這個概念保留；而在 JDK8 及之後，永久代也沒有了，所以類變數隨著 Class 物件一起存放在 Java 堆中，這時候 “類變數在方法區” 就有點牽強。
注意：
1. 這個階段進行記憶體分配的**僅包括類變數，不包括例項變數**。現在講的整個過程都只是類載入的過程，例項變數會在物件例項化的時候隨物件一起分配在 java 堆中。
2. 設定初始值通常指的是資料型別的 0 值。
比如：
```java
public static int value = 123;
```
經過這裡的準備階段，初始值 value 是 0，因為這個時候任何 java 方法都沒有執行，初始化的指令是 putstatic ，這個指令是在類構造器的 \() 方法裡的。
所以 value 變成 123 是在類的初始化階段才會執行的，就是 **2.3.5** 。
### 2.3.4 解析（連線之 3 ）
解析階段是 Java 虛擬機器將常量池內的**符號引用**替換為**直接引用**的過程。
前面的 Class 檔案格式部分提過一次，那解析階段中所說的直接引用與符號引用又有什麼關聯呢？
- **符號引用**（Symbolic References）：一組符號來描述引用目標，任何字面量，只要能定位就行。
- **直接引用**（Direct References）：直接指向目標的指標、相對偏移量或者一個間接定位到目標的控制代碼。
解析動作主要針對 7 類符號引用進行轉換：
1. 類或介面；
2. 欄位；
3. 類方法；
4. 介面方法；
5. 方法型別；
6. 方法控制代碼；
7. 呼叫點限定符。
### 2.3.5 初始化
類的初始化階段是類載入過程的最後一個步驟。
之前介紹的幾個類載入的動作裡，除了在載入階段使用者應用程式可以通過自定義類載入器的方式區域性參與外，其餘動作都完全由Java虛擬機器來主導控制。直到初始化階段，**Java 虛擬機器才真正開始執行類中編寫的Java程式程式碼，將主導權移交給應用程式**。
2.3.3 的準備階段，已經給變數賦過值了，是初始 0 值，而初始化階段，會根據程式碼初始化類變數和其他資源，另一種更直接的形式來表達這個過程：
初始化階段就是執行類構造器的 \() 方法的過程，這個方法不是程式設計師自己寫的，是 javac 編譯器的自動生成物。
## 2.4 類載入器
Java虛擬機器設計團隊有意把類載入階段中的：
**“通過一個類的全限定名來獲取描述該類的二進位制位元組流”**
這個動作放到 Java 虛擬機器外部去實現，以便讓應用程式自己決定如何去獲取所需的類。（就是上面講的類載入過程的第一個步驟）
實現這個動作的程式碼被稱為 **“類載入器”** ( Class loader)。
### 2.4.1 類與類載入器
類載入器雖然只用於實現類的載入動作，但它在Java程式中起到的作用卻遠超類載入階段。
對於任意一個類，都必須由**載入它的類載入器、和這個類本身**一起共同確立其在Java虛擬機器中的唯一性，**每個類載入器，都擁有一個獨立的類名稱空間**。
> 這句話可以表達得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類載入器載入的前提下才有意義，否則，即使這兩個類來源於同一個Class檔案，被同一個Java虛擬機器載入，只要載入它們的類載入器不同，那這兩個類就必定不**相等**。
>
> 這裡的相等，包括比較物件的 equals() 方法，isInstance() 方法、isAssignableFrom() 等的返回結果，以及 instanceof 關鍵字的判定結果。
### 2.4.2 雙親委派模型
站在Java虛擬機器的角度來看，只存在兩種不同的類載入器：
- 一種是啟動類載入器( BootstrapClassloader)，這個類載入器使用C++語言實現，是虛擬機器自身的一部分；
- 另外一種就是其他所有類載入器，這些類載入器都由 Java 語言實現，獨立存在於虛擬機器外部，並且全都繼承自抽象類 java.lang.ClassLoader 。
站在Java開發人員的角度來看，類載入器就應當劃分得更細緻一些。自 JDK12 以來，**Java 一直保著三層類載入器、雙親委派的類載入架構。**
#### 2.4.2.1 三層類載入器
注意：下面提及的原始碼目錄在JDK9之後，因為模組化的改變，所以按照這些目錄大概率自己的 jdk 檔案裡找不到的。
1. **啟動類載入器 ( Bootstrap Class Loader)**
前面已經介紹過，這個類載入器負責**載入存放在 \\lib 目錄，或者被 -Xbootclasspath 引數所指定的路徑中存放的**，而且是 Java 虛擬機器能夠識別的（按照檔名) 類庫載入到虛擬機器的記憶體中。
啟動類載入器無法被 Java 程式直接引用，使用者在編寫自定義類載入器時，如果需要把載入請求委派給引導類載入器去處理，那直接使用 null 代替即可。
2. **擴充套件類載入器（Extension Class Loader）**
這個類載入器是在類 sun.misc.Launcher$ExtClassLoader 中以 Java 程式碼的形式實現的。
它負責**載入 \\lib\ext 目錄中，或者被 java.ext.dirs 系統變數所指定的路徑中所有的類庫**。
> 根據 “擴充套件類載入器” 這個名稱，就可以推斷出這是一種 Java 系統類庫的擴充套件機制，JDK 的開發團隊允許使用者將具有通用性的類庫放置在 ext 目錄裡以擴充套件 JavaSe 的功能，在JDK9之後，這種擴充套件機制被模組化帶來的天然的擴充套件能力所取代。由於擴充套件類載入器是由 Java 程式碼實現的，開發者可以直接在程式中使用擴充套件類載入器來載入 Class 檔案。
3. **應用程式類載入器（Application Class Loader）**
這個類載入器由 sun.misc.LaunchersappClassloader 來實現。由於這個類載入器是 Classloader 類中的 getSystemClassloader() 方法的返回值，所以有些場合中也稱它為“系統類載入器”。
它負責**載入使用者類路徑 (ClassPath) 上所有的類庫**，開發者同樣可以直接在程式碼中使用這個類載入器。如果應用程式中沒有自定義過自己的類載入器，一般情況下這個就是程式中預設的類載入器。
除了這三種外，如果使用者有必要，還可以自定義來進行擴充套件：
