類加載器—Class Loader
通過上一篇博客，我們知道了
JVM 體系結構（👈可點擊查看）
但對於JVM體系結構中每個結構的詳細內容以及工作機制，我們還不瞭解。
所以，我們今天來說一下關於 類加載器 的具體內容以及工作機制。
先回顧一下 JVM 體系結構：
我們知道類加載器是用來將 .class 文件加載進內存。
那麼思考幾個問題：
- 加載過程有哪些步驟？總不會只是簡單將文件放到內存中去吧？
- 加載過程中做了什麼操作？是直接將 .class 文件放進內存嗎？如果是這樣的話，那就沒必要用這個加載器了，直接放進去放進去不就好了。既然不是將 .class 文件直接放進內存，那麼放進內存前對 .class 文件做了什麼處理呢？
- 類加載的時候有什麼機制嗎？遵循什麼規則嗎？
帶着這些問題往下看。
類加載過程
類加載過程： 加載→驗證→準備→解析→初始化
（過程中的這個加載指的是類加載過程中的一個步驟，不要弄混了。）
下面再來聊一聊過程中每個步驟的具體內容：
一、加載
- 加載這個步驟完成了三件事：
- 通過類的完全限定名稱獲取定義該類的二進制字節流。
- 將該字節流表示的靜態存儲結構轉換爲方法區的運行時存儲結構。
- 在內存中生成一個代表該類的 Class 對象，作爲方法區中該類各種數據的訪問入口。
- 其中獲取二進制字節流的方式有：
- 從 ZIP 壓縮包中去讀取，成爲 JAR、EAR、WAR 格式的基礎。
- 從網絡中獲取，最典型的應用是 Web Applet。
- 運行時計算生成，最典型的應用是動態代理技術。
- 由其他文件生產，最典型的應用是 JSP 。
- ……
二、驗證
- 驗證是連接的第一步，目的是確保 Class 文件的字節流中包含的信息符合當前虛擬機的要求，並保證這些信息被當作代碼運行後不會危害虛擬機自身的安全。
三、準備
- 準備是正式爲類中定義的變量（即靜態變量，被 static 修飾的變量）分配內存並設置變量初始值的階段。
四、解析
- 解析是將常量池的符號引用替換爲直接引用的過程。
五、初始化
- 初始化是類加載過程的最後一步，在這一步之前，幾乎所有動作都由Java虛擬機來主導控制，而到了這一步，Java虛擬機纔開始真正執行類中編寫的Java程序，並將主導控制權交給應用程序。
- 初始化的時機：一個類只有被主動引用的時候會觸發初始化。
- 主動引用的場景（6種情況）：
- 遇到 new、getstatic、putstatic、invokestatic 這四條字節碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化。能產生這個四條指令的典型 Java 代碼場景：
① 使用 new 關鍵字實例化對象的時候；
② 讀取或設置一個類的靜態字段（被 final 修飾、已在編譯期把結果放入常量池的靜態字段除外）的時候；
③ 調用一個類的靜態方法的時候。 - 使用 java.lang.reflect 包的方法對類進行反射調用的時候，如果類沒有進行過初始化，則需要先觸發其初始化。
- 當初始化類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化。
- 當虛擬機啓動時，用戶需要指定一個要執行的主類（包含 main() 方法的那個類），虛擬機會先初始化這個主類；
- 當使用 JDK 7 新加入的動態語言支持時，如果一個 java.lang.invoke.MethodHandle 實例最後的解析結果是 REF_getStatic、REF_putStatic、REF_invokeStatic、REF_newInvokeSpecial四種類型的方法句柄，並且這個方法句柄對應的類沒有進行初始化，則需要先觸發其初始化。
- 當一個接口中定義了 JDK 8 新加入的默認方法（被 default 關鍵字修飾的接口方法）時，如果有這個接口的實現類發生了初始化，那該接口要在其之前被初始化。
類加載器類型
JVM 中內置了三個重要的類加載器：
- Bootstrap Class Loader（啓動類加載器）
- Extension Class Loader（擴展類加載器）
- Application Class Loader（應用程序類加載器）
除了着這三個內置的類加載器，我們也可以自定義類加載器（User Class Loader）。
類加載器的進一步介紹：
一、Bootstrap Class Loader（啓動類加載器）
啓動類加載器是最頂層的加載類，由 C++ 實現，負責將 %JAVA_HOME%/lib目錄中，或者或被 -Xbootclasspath參數指定的路徑中的，且能被虛擬機識別的類庫 加載到虛擬機內存中。
二、Extension Class Loader（擴展類加載器）
擴展類加載器主要負責將 %JAVA_HOME%/lib/ext 目錄中，或被 java.ext.dirs 系統變量所指定的路徑下的類庫 加載到內存中。
三、Application Class Loader（應用程序類加載器）
應用程序類加載器負責將用戶類路徑（ClassPath）上所指定的類庫 加載到內存中
User Class Loader（自定義類加載器）
JVM內置這幾個類加載器之後加載指定的類庫，如果我們想加載自己的類庫，我們就可以來自定義一個Class Loader，並且還可以根據需求，對這些類庫進行加密解密等。
有這麼多類加載器，那麼當一個類需要加載進虛擬機內存時，是怎麼選擇類加載器的？接下來就是關於類加載器的選擇。
類加載器的選擇——雙親委派模型
上面那個類加載器的圖中其實包含了一個模型：雙親委派模型
我們拿出來看一下：
雙親委派模型介紹： 每個類加載器會首先將類加載請求轉發到父類加載器（也就是雙親委派模型中上一層的類加載器），直到最頂層的Bootstrap Class Loader，只有當父類加載器無法完成時才嘗試自己加載。
簡單來說就是：每個類加載器都會先看看自己的父類能不能完成這個類加載請求，父類不能完成再到自己。
雙親委派機制的好處： 沙箱安全，保證了Java 的核心 API 不被篡改，避免了類的重複加載，保證了Java程序的穩定運行。
比如，我們自己寫了個 java.lang.String 類，當程序運行的時候，雙親委派機制會保證程序加載進內存的是Java自帶的 java.lang.String 類，不會因爲我們寫的類而使得 Java 核心 API 被篡改。
關於 JVM 類加載器相關的內容就寫到這裏，想了解更深更細緻的內容，推薦大家可以去看看 周志明大神寫的 《深入理解Java虛擬機》。
注：如果猿兄這篇博客有任何錯誤和建議，歡迎大家留言，不勝感激！
這裏先將最近要更新的JVM相關博客碼在這裏，寫了之後再更新鏈接。
JVM 系列文章相關推薦：
持續更新，點個關注，不再迷路
這裏是 猿兄，爲你分享程序員的世界。
非常感謝各位優秀的程序員們能看到這裏，如果覺得文章還不錯的話，求點贊👍 求關注💗 求分享👬，對我來說真的 非常有用！！！