JVM類加載機制

一、JVM類加載機制

　虛擬機把描述類的資料從 .class 檔案加載到記憶體，并對資料進行校驗，決議和初始化，最終形成可以被虛擬機直接使用的 java 型別， 

 

　JVM 類加載機制分為五個部分：加載，驗證，準備，決議，初始化，下面我們就分別來看一下這五個程序，

　

　1.1 加載

　　加載是類加載程序中的一個階段，這個階段會把 .class 檔案位元組碼內容加載到記憶體中，并將這些靜態資料轉換成方法區中的運行資料結構，在堆記憶體中生成一個代表這個類的 java.lang.Class 物件，作為方法區這個類的各種資料的入口，注意這里不一定非得要從一個 Class 檔案獲取，這里既可以從 ZIP 包中讀取（比如從 jar 包和 war 包中讀取），也可以在運行時計算生成（動態代理），也可以由其它檔案生成（比如將 JSP 檔案轉換成對應的 Class 類），

　　即該階段主要完成以下三件事：

　　　1.1.1 通過一個類的全限定名獲取該類的二進制流，

　　　1.1.2 將該二進制流中的靜態存盤結構轉化為方法去運行時資料結構，

　　　1.1.3 在記憶體中生成該類的 Class 物件，作為該類的資料訪問入口，

　1.2 驗證

　　這一階段的主要目的是為了確保 Class 檔案的位元組流中包含的資訊符合當前虛擬機的要求，并且不會危害虛擬機自身的安全， 

　　在該階段主要完成以下四鐘驗證:

　　　1.2.1 檔案格式驗證：驗證位元組流是否符合 Class 檔案的規范，如主次版本號是否在當前虛擬機范圍內，常量池中的常量是否有不被支持的型別.

　　　1.2.2 元資料驗證:  對位元組碼描述的資訊進行語意分析，如這個類是否有父類，是否集成了不被繼承的類等，

　　　1.2.3 位元組碼驗證：是整個驗證程序中最復雜的一個階段，通過驗證資料流和控制流的分析，確定程式語意是否正確，主要針對方法體的驗證，如：方法中的型別轉換是否正確，跳轉指令是否正確等，

　　　1.2.4 符號參考驗證：這個動作在后面的決議程序中發生，主要是為了確保決議動作能正確執行，

　1.3 準備 

　　準備階段是正式為類變數分配記憶體并設定類變數的初始值階段，即在方法區中分配這些變數所使用的記憶體空間，注意這里所說的初始值概念，比如一個類變數定義為：　

　　public static int v = 8080;

　　實際上變數 v 在準備階段過后的初始值為 0 而不是 8080，即這里的初始值是默認值而不是自己賦的值，將 v 賦值為 8080 的 put static 指令是程式被編譯后，存放于類構造器<client>方法之中，

　　但是注意如果宣告為： 　

　　public static final int v = 8080;

　　在編譯階段會為 v 生成 ConstantValue 屬性，在準備階段虛擬機會根據 ConstantValue 屬性將 v賦值為 8080， 

　1.4 決議

　　決議階段是指虛擬機將常量池中的符號參考替換為直接參考的程序，符號參考就是 class 檔案中的： CONSTANT_Class_info　； CONSTANT_Field_info  ； CONSTANT_Method_info   等型別的常量，

　　1.4.1 符號參考 

　　　符號參考與虛擬機實作的布局無關，參考的目標并不一定要已經加載到記憶體中，各種虛擬機實作的記憶體布局可以各不相同，但是它們能接受的符號參考必須是一致的，因為符號參考的字面量形式明確定義在 Java 虛擬機規范的 Class 檔案格式中， 

　　1.4.2 直接參考 

　　　直接參考可以是指向目標的指標，相對偏移量或是一個能間接定位到目標的句柄，如果有了直接參考，那參考的目標必定已經在記憶體中存在， 

　1.5 初始化

　　初始化階段是類加載最后一個階段，前面的類加載階段之后，除了在加載階段可以自定義類加載器以外，其它操作都由 JVM 主導，到了初始階段，才開始真正執行類中定義的 Java 程式代碼， 

　　初始化階段是執行類構造器<client>方法的程序，<client>方法是由編譯器自動收集類中的類變數（靜態變數）的賦值操作和靜態陳述句塊中的陳述句合并而成的，虛擬機會保證子<client>方法執行之前，父類的<client>方法已經執行完畢；如果一個類中沒有對類變數賦值也沒有靜態陳述句塊，那么編譯器可以不為這個類生成<client>()方法；虛擬機會保證一個類的<client> 方法在多執行緒環境下被正確的加鎖和同步；當訪問一個類的靜態域時，只有真正宣告這個域的類才會被加載，

　　1.5.1 注意以下幾種情況不會執行類初始化，類的被動參考不會觸發此類的初始化： 

　　　　1. 通過子類參考父類的靜態欄位，只會觸發父類的初始化，而不會觸發子類的初始化，

　　　　2. 定義物件陣列即通過陣列定義類參考，不會觸發該類的初始化，

　　　　3. 參考常量不會觸發此類的初始化，常量在編譯期間會存入呼叫類的常量池中，本質上并沒有直接參考定義常量的類，不會觸發定義常量所在的類，

　　　　4. 通過類名獲取 Class 物件，不會觸發類的初始化，

　　　　5. 通過 Class.forName 加載指定類時，如果指定引數 initialize 為 false 時，也不會觸發類初始化，其實這個引數是告訴虛擬機，是否要對類進行初始化，

　　　　6. 通過 ClassLoader 默認的 loadClass 方法，也不會觸發初始化動作， 

　　1.5.2 類的主動參考（一定會發生類的初始化）

　　　　1. new一個類的物件

　　　　2. 呼叫類的靜態成員(除了final常量)和靜態方法

　　　　3. 使用java.lang.reflect包的方法對類進行反射呼叫（引數 initialize 為 true ）

　　　　4. 當虛擬機啟動，java Hello，則一定會初始化Hello類，說白了就是先啟動main方法所在的類

　　　　5. 當初始化一個類，如果其父類沒有被初始化，則先會初始化他的父類

二、類加載器

　實作通過類的全限定名獲取該類的二進制位元組流的代碼塊叫做類加載器，

　類快取： 標準的Java SE類加載器可以按要求查找類，但一旦某個類被加載到類加載器中，它將維持加載（快取）一段時間，不過，JVM垃圾收集器可以回收這些Class物件，

　2.1 主要有一下四種類加載器:

　　

　　2.1.1 啟動類加載器(Bootstrap ClassLoader)

　　　負責加載 JAVA_HOME\lib 目錄中的，或通過-Xbootclasspath 引數指定路徑中的，且被虛擬機認可（按檔案名識別，如 rt.jar）的類，用來加載 java 核心類別庫，無法被 java 程式直接參考，是用原生代碼來實作的，并不繼承自 java.lang.ClassLoader，

　　　加載擴展類和應用程式類加載器，并指定他們的父類加載器，

　　2.1.2 擴展類加載器(Extension ClassLoader)

　　　負責加載 JAVA_HOME\lib\ext 目錄中的，或通過 java.ext.dirs 系統變數指定路徑中的類別庫，它用來加載 Java 的擴展庫，Java 虛擬機的實作會提供一個擴展庫目錄，該類加載器在此目錄里面查找并加載 Java 類，

　　2.1.3 應用程式類加載器(Application ClassLoader)

　　　負責加載用戶路徑（classpath）上的類別庫，一般來說，Java 應用的類都是由它來完成加載的，JVM 通過雙親委派模型進行類的加載，當然我們也可以通過繼承 java.lang.ClassLoader實作自定義的類加載器，

　　2.1.4 自定義類加載器

　　　開發人員可以通過繼承 java.lang.ClassLoader類的方式實作自己的類加載器，以滿足一些特殊的需求，

　　

　2.2 java.class.ClassLoader類

　　2.2.1 作用

　　　java.lang.ClassLoader類的基本職責就是根據一個指定的類的名稱，找到或者生成其對應的位元組代碼，然后從這些位元組代碼中定義出一個Java 類，即 java.lang.Class類的一個實體，

　　2.2.2 相關方法

　　　getParent() ：回傳該類加載器的父類加載器，

　　　loadClass(String name) ：加載名稱為 name的類，回傳的結果是 java.lang.Class類的實體，

　　　findClass(String name) ：查找名稱為 name的類，回傳的結果是 java.lang.Class類的實體，

　　　findLoadedClass(String name) ：查找名稱為 name的已經被加載過的類，回傳的結果是 java.lang.Class類的實體，

　　　defineClass(String name, byte[] b, int off, int len) ：把位元組陣列 b中的內容轉換成 Java 類，回傳的結果是java.lang.Class類的實體，這個方法被宣告為 final的，

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

　　對于以上給出的方法，表示類名稱的 name引數的值是類的二進制名稱，需要注意的是內部類的表示，如com.example.Sample$1和com.example.Sample$Inner等表示方式，

 

　2.3 類加載器的代理模式------雙親委派機制

　　2.3.1 代理模式：交給其他加載器來加載指定的類

　　2.3.2 雙親委托機制

　　　就是某個特定的類加載器在接到加載類的請求時，首先將加載任務委托給父類加載器，依次追溯，直到最高的爺爺輩的，如果父類加載器可以完成類加載任務，就成功回傳；只有父類加載器無法完成此加載任務時，才自己去加載，

　　　雙親委托機制是為了保證 Java 核心庫的型別安全，這種機制就保證不會出現用戶自己能定義java.lang.Object類的情況，

　　　采用雙親委派的一個好處是比如加載位于 rt.jar 包中的類 java.lang.Object，不管是哪個加載器加載這個類，最終都是委托給頂層的啟動類加載器進行加載，這樣就保證了使用不同的類加載器最終得到的都是同樣一個 Object 物件，

　　　類加載器除了用于加載類，也是安全的最基本的屏障，

　　2.3.3 雙親委托機制是代理模式的一種，并不是所有的類加載器都采用雙親委托機制，tomcat服務器類加載器也使用代理模式，所不同的是它是首先嘗試去加載某個類，如果找不到再代理給父類加載器，

這與一般類加載器的順序是相反的，

 

　2.4 自定義類加載器的流程

　　1、首先檢查請求的型別是否已經被這個類裝載器裝載到命名空間中了，如果已經裝載，直接回傳；否則轉入步驟2

　　2、委派類加載請求給父類加載器（更準確的說應該是雙親類加載器，真個虛擬機中各種類加載器最侄訓呈現樹狀結構），如果父類加載器能夠完成，則回傳父類加載器加載的Class實體；否則轉入步驟3

　　3、呼叫本類加載器的findClass（…）方法，試圖獲取對應的位元組碼，如果獲取的到，則呼叫defineClass（…）匯入型別到方法區；如果獲取不到對應的位元組碼或者其他原因失敗，回傳例外給loadClass（…）， loadClass（…）轉拋例外，終止加載程序（注意：這里的例外種類不止一種），

　　 注意：被兩個類加載器加載的同一個類，JVM不認為是相同的類，

 

　2.5 執行緒背景關系類加載器

　　2.5.1 雙親委托機制以及默認類加載器的問題

　　　一般情況下, 保證同一個類中所關聯的其他類都是由當前類的類加載器所加載的.，比如，ClassA本身在Ext下找到，那么他里面new出來的一些類也就只能用Ext去查找了（不會低一個級別），所以有些明明App可以找到的，卻找不到了，

　　　JDBC API，他有實作的driven部分（mysql/sql server），我們的JDBC API都是由Boot或者Ext來載入的，但是JDBC driver卻是由Ext或者App來載入，那么就有可能找不到driver了，在Java領域中，其實只要分成這種Api+SPI（Service Provide Interface，特定廠商提供）的，都會遇到此問題，

　　　常見的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等，這些 SPI 的介面由 Java 核心庫來提供，如 JAXP 的 SPI 介面定義包含在 javax.xml.parsers 包中，SPI 的介面是 Java 核心庫的一部分，是由啟動類加載器來加載的;SPI 實作的Java 類一般是由應用程式類加載器來加載的，啟動類加載器是無法找到 SPI 的實作類的，因為它只加載 Java 的核心庫，

　　2.5.2 通常當你需要動態加載資源的時候 , 你至少有三個 ClassLoader 可以選擇 :

　　　1.系統類加載器或叫作應用類加載器 (system classloader or application classloader)

　　　2.當前類加載器

　　　3.當前執行緒類加載器

　　2.5.3 ? Thread.currentThread().getContextClassLoader()

　　　當前執行緒類加載器是為了拋棄雙親委派加載鏈模式，每個執行緒都有一個關聯的背景關系類加載器，如果你使用new Thread()方式生成新的執行緒，新執行緒將繼承其父執行緒的背景關系類加載器，如果程式對執行緒背景關系類加載器沒有任何改動的話，程式中所有的執行緒將都使用系統類加載器作為背景關系類加載器，

 

　2.6 TOMCAT服務器的類加載機制

　　一切都是為了安全！TOMCAT不能使用系統默認的類加載器，

　　　　　　

　　　　? 如果TOMCAT跑你的WEB專案使用系統的類加載器那是相當危險的，你可以直接是無忌憚是作業系統的各個目錄了，

　　　　? 對于運行在 Java EE?容器中的 Web 應用來說，類加載器的實作方式與一般的 Java 應用有所不同，

　　　　? 每個 Web 應用都有一個對應的類加載器實體，該類加載器也使用代理模式(不同于前面說的雙親委托機制)，所不同的是它是首先嘗試去加載某個類，如果找不到再代理給父類加載器，這與一般類加載器的順序是相反的，但也是為了保證安全，這樣核心庫就不在查詢范圍之內，

　　　　? 為了安全TOMCAT需要實作自己的類加載器，

　　　　? 我可以限制你只能把類寫在指定的地方，否則我不給你加載！

 

三、OSGI（動態模型系統）

　OSGI (Open Service Gateway Initiative)，是面向 Java 的動態模型系統，是 Java 動態化模塊化系統的一系列規范，

　它為開發人員提供了面向服務和基于組件的運行環境，并提供標準的方式用來管理軟體的生命周期，OSGI 已經被實作和部署在很多產品上，在開源社區也得到了廣泛的支持，Eclipse就是基于 OSGI 技術來構建的，

　3.1 原理

　　OSGI 中的每個模塊（bundle）都包含 Java 包和類，模塊可以宣告它所依賴的需要匯入（import）的其它模塊的 Java 包和類（通過 Import-Package），也可以宣告匯出（export）自己的包和類，供其它模塊使用（通過 Export-Package），也就是說需要能夠隱藏和共享一個模塊中的某些 Java 包和類，這是通過 OSGI 特有的類加載器機制來實作的，OSGI 中的每個模塊都有對應的一個類加載器，它負責加載模塊自己包含的Java 包和類，當它需要加載 Java 核心庫的類時（以 java開頭的包和類），它會代理給父類加載器（通常是啟動類加載器）來完成，當它需要加載所匯入的 Java 類時，它會代理給匯出此 Java 類的模塊來完成加載，模塊也可以顯式的宣告某些 Java 包和類，必須由父類加載器來加載，只需要設定系統屬性 org.osgi.framework.bootdelegation的值即可，

　3.2 特點

　　3.2.1 動態改變構造

　　　OSGI 服務平臺提供在多種網路設備上無需重啟的動態改變構造的功能，為了最小化耦合度和促使這些耦合度可管理，OSGI 技術提供一種面向服務的架構，它能使這些組件動態地發現對方，

　　3.2.2 模塊化編程與熱插拔

　　　OSGI 旨在為實作 Java 程式的模塊化編程提供基礎條件，基于 OSGI 的程式很可能可以實作模塊級的熱插拔功能，當程式升級更新時，可以只停用、重新安裝然后啟動程式的其中一部分，這對企業級程式開發來說是非常具有傭訓力的特性，

　　　OSGI 描繪了一個很美好的模塊化開發目標，而且定義了實作這個目標的所需要服務與架構，同時也有成熟的框架進行實作支持，但并非所有的應用都適合采用 OSGI 作為基礎架構，它在提供強大功能同時，也引入了額外的復雜度，因為它不遵守了類加載的雙親委托模型，

 

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/142938.html

標籤：Java

上一篇：小書MybatisPlus第4篇-表格分頁與下拉分頁查詢

下一篇：拯救狗屎代碼：基于 Gitlab 的代碼審查，簡單實用