一、概述
虛擬機把描述類的資料從Class檔案(一串二進制的檔案流)加載到記憶體，并對資料進行校驗、轉換決議和初始化，最終形成可以被虛擬機直接使用的java型別，這就是虛擬機的類加載機制，
二、類的生命周期
類從被加載到虛擬機記憶體中開始，到卸載出記憶體為止，它的整個生命周期包括:加載、驗證、準備、 決議、初始化、使用 和卸載 7個階段，其中驗證、準備、決議3個部分統稱為連接， 這7個階段的發生順序如圖7-1所示，
型別的加載、連接和初始化程序都是在程式運行期間完成的，這種策略雖然會令類加載時稍微增加一些性能開銷，但是會為Java應用程式提供高度的靈活性，Java里天生可以動態擴展的語言特性就是依賴運行期間動態加載和動態連接這個特點實作的，
1. 什么時候會開始類的"加載"、"初始化"?
Java 虛擬機規范中并沒有對"加載"進行強制約束，這點可以交給虛擬機的具體實作來自由把握，但是對于初始化階段，虛擬機規范則是嚴格規定了有且只有5種情況必須立即對類進行“初始化”(而加載、驗證、準備自然需要在此之前開始):
1）遇到new、getstatic、 putstatic 或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化
2）使用java.lang reflect包的方法對類進行反射呼叫的時候，如果類沒有進行過初始化，則需要先觸發其初始化，
3）當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化，
4）當虛擬機啟動時，用戶需要指定一個要執行的主類(包含main()方法的那個類)，虛擬機會先初始化這個主類，
5）當使用JDK 1.7 的動態語言支持時，如果一個java.lang invoke.MethodHandle實體最后的決議結果REF_ getStatic、 REF_ putStatic、 REF_ invokeStatic 的方法句柄，并且這個方法句柄所對應的類沒有進行過初始化，則需要先觸發其初始化，
這5種場景中的行為稱為對一個類進行主動參考，除此之外，所有參考類的方式都不會觸發初始化，稱為被動參考，
主動參考，通俗的講，有以下幾種情況：
- 創建類的實體
- 訪問某個類或介面的靜態變數，或者對該靜態變數賦值
- 呼叫類的靜態方法
- 反射（如 Clss.forName("com.demo.test.MyTest")）
- 初始化一個類的子類
- Java虛擬機啟動是被標明為啟動類的類（如 執行命令：java MyTest）
解釋下被動參考，如：
1.通過子類參考父類的靜態欄位，不會導致子類初始化，如：SubClass.value （value為父類SuperClass中的靜態變數）
2.通過陣列定義來參考類，不會觸發此類的初始化 ，如：SuperClass[] sca = new SuperClass[10];
3.常量在編譯階段會存入呼叫類的常量池中，本質上并沒有直接參考到定義常量的類，因此不會觸發定義常量的類的初始化，如：
雖然在Java原始碼中參考了ConstClass類中的常量HELLOWORED,但其實在編譯階段通過常量傳播優化，已經將此常量的值“hello world”存盤到了NotInitialization 類(呼叫ConstClass.HEELOWORLD的類)的常量池中，以后NotInitialization對常量ConstClass.HEELOWORLD的參考實際都被轉化為Notlnitialization類對自身常量池的參考，
4.補充：呼叫ClassLoader類的loadClass方法加載一個類，并不是對類的主動使用，不會導致類的初始化，
2. 介面的加載程序與類加載程序少有不同，主要區別在于：
“有且僅有”需要開始初始化場景中的第3種：當一個類在初始化時，要求其父類全部都已經初始化過了，但是一個介面在初始化時，并不要求其父介面全部都完成了初始化，只有在真正使用到父介面的時候(如參考介面中定義的常量)才會初始化，
3.類加載的程序 （加載、驗證、準備、決議和初始化）
（1）加載
1）通過一個類的全限定名來獲取定義此類的二進制位元組流，
2）將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構，
3）在記憶體中生成一個代表這個類的java.lang.Class 物件，作為方法區這個類的各種資料的訪問入口，
注：加載階段與連接階段的部分內容( 如一部分位元組碼檔案格式驗證動作)是交叉進行的，加載階段尚未完成，連接階段可能已經開始，但這些夾在加載階段之中進行的動作，仍然屬于連接階段的內容，這兩個階段的開始時間仍然保持著固定的先后順序，
自己一句話描述：類的加載指的是將類的.class檔案的二進制位元組流讀入到記憶體中，將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構，然后在堆區創建一個java.lang.Class物件，作為方法區這個類的各種資料的訪問入口，
（2）驗證
驗證是連接階段的第一步，這一階段的目的是為了確保Class檔案的位元組流中包含的資訊符合當前虛擬機的要求，并且不會危害虛擬機自身的安全，
驗證階段大致上會完成下面4個階段的檢驗動作: 檔案格式驗證、元資料驗證、位元組碼驗證、符號參考驗證，
1）檔案格式驗證
第-階段要驗證位元組流是否符合Class檔案格式的規范，并且能被當前版本的虛擬機處理，
2）元資料驗證
第二階段是對類的元資料資訊進行語意校驗，保證不存在不符合Java語言規范的元資料資訊，
3）位元組碼驗證
第三階段是整個驗證程序中最復雜的一個階段，主要目的是通過資料流和控制流分析，確定程式語意是合法的、符合邏輯的，在第二階段對元資料資訊中的資料型別做完校驗后，這個階段將對類的方法體進行校驗分析，保證被校驗類的方法在運行時不會做出危害虛擬機安全的事件，
4） 符號參考驗證
最后一個階段的校驗發生在虛擬機將符號參考轉化為直接參考的時候，這個轉化動作將在連接的第三階段--決議階段中發生，符號參考驗證可以看做是對類自身以外(常量池中的各種符號參考)的資訊進行匹配性校驗，如：類、欄位、方法的訪問性是否可以被當前類訪問； 能否找到欄位對應的類；
（3）準備
準備階段是正式為類變數分配記憶體并設定類變數初始值的階段，這些變數所使用的記憶體都將在方法區中進行分配，這個階段中有兩個容易產生混淆的概念需要強調一下，首先，這時候進行內存分配的僅包括類變數(被static修飾的變數)，而不包括實體變數，實體變數將會在物件實體化時隨著物件一起分配在Java堆中，其次，這里所說的初始值“通常情況”下是資料型別的零值，假設一個類變數的定義為：
public static int value = https://www.cnblogs.com/dong320/p/123;
那變數value在準備階段過后的初始值為0而不是123，因為這時候尚未開始執行任何Java方法，而把value賦值為123的putstatic指令是程式被編譯后，存放于類構造器<clinit>()方法之中，所以把value賦值為123的動作將在初始化階段才會執行，
上面提到，在“通常情況”下初始值是零值，那相對的會有一些“特殊情況”：如果類欄位的欄位屬性表中存在ConstantValue屬性，那在準備階段變數value就會被初始化為ConstantValue屬性所指定的值，假設上面類變數value 的定義變為:
public static final int value = https://www.cnblogs.com/dong320/p/123;
編譯時Javac將會為value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設定將value 賦值為123，
（4） 決議
決議階段是虛擬機將常量池內的符號參考替換為直接參考的程序，
1）符號參考：符號參考以一組符號來描述所參考的目標，符號可以是任何形式的字面量，只要使用時能無歧義地定位到目標即可，符號參考與虛擬機實作的記憶體布局無關，參考的目標并不一定已經加載到記憶體中，各種虛擬機實作的記憶體布局可以各不相同，但是它們能接受的符號參考必須都是一致的， 因為符號參考的字面量形式明確定義在Java虛擬機規范的Class檔案格式中，
2）直接參考：直接參考可以是直接指向目標的指標、相對偏移量或是一個能間接定位 到目標的句柄，直接參考是和虛 擬機實作的記憶體布局相關的，同-個符號參考在不同虛擬機實體上翻譯出來的直接參考-般不會相同，如果有了直接參考，那參考的目標必定已經在記憶體中存在，
決議動作主要針對類或介面、欄位、類方法、介面方法、方法型別、方法句柄和呼叫點限定符7類符號參考進行，分別對應常量池中的7種常量型別，
（5）初始化
類初始化階段是類加載程序的最后一步，前面的類加載程序中，除了在加載階段用戶應用程式可以通過自定義類加載器參與之外，其余動作完全由虛擬機主導和控制，到了初始化階段，才真正開始執行類中定義的Java程式代碼(或者說是位元組碼)，在準備階段，變數已經賦過一次系統要求的初始值（零值，或者指定的常量初始值），而在初始化階段，則根據程式員通程序式制定的主觀計劃去初始化類變數和其他資源，
或者可以從另外一個角度來表達：初始化階段是執行類構造器<clinit>()方法的程序，
1）<clinit>()方法是由編譯器自動收集類中的所有類變數的賦值動作和靜態陳述句塊(static{}塊)中的陳述句合并產生的，編譯器收集的順序是由陳述句在源檔案中出現的順序所決定的，靜態陳述句塊中只能訪問到定義在靜態陳述句塊之前的變數，定義在它之后的變數，在前面的靜態陳述句塊可以賦值，但是不能訪問，如下例子所示，
public class Test { static { i = 0; // 給變數賦值可以正常編譯通過 System.out.print(i); // 這句編譯器會提示"非法向前參考" } static int i = 1; }
2）<clinit>()方法與類的建構式(或者說實體構造器<init>()方法)不同，它不需要顯式地呼叫父類構造器，虛擬機會保證在子類的<clinit>()方法執行之前，父類的<clinit>()方法已經執行完畢，因此在虛擬機中第一個被執行的<clinit>()方法的類肯定是java.lang.Object.
3）由于父類的<clinit>()方法先執行，也就意味著父類中定義的靜態陳述句塊要優先于子類的變數賦值操作
4）<clinit>()方法對于類或介面來說并不是必需的，如果一個類中沒有靜態陳述句塊，也沒有對變數的賦值操作，那么編譯器可以不為這個類生成<clinit>()方法，
5）介面中不能使用靜態陳述句塊，但仍然有變數初始化的賦值操作，因此介面與類一樣都會生成<clinit>()方法，但介面與類不同的是，執行介面的<clinit>()方法不需要先執行父介面的<clinit>()方法，只有當父介面中定義的變數使用時，父介面才會初始化，另外，介面的實作類在初始化時也一樣不會執行介面的<clinit>()方法，
6）虛擬機會保證一個類的<clinit>()方法在多執行緒環境中被正確地加鎖、同步，如果多個執行緒同時去初始化一個類，那么只會有一個執行緒去執行這個類的<clinit>()方法，其他執行緒都需要阻塞等待，直到活動執行緒執行<clinit>()方法完畢，如果在一個類的<clinit>()方法中有耗時很長的操作，就可能造成多個行程阻塞，在實際應用中這種阻塞往往是很隱蔽的，
三、類加載器
虛擬機設計團隊把類加載階段中的“通過一個類的全限定名來獲取描述此類的二進制位元組流”這個動作放到Java虛擬機外部去實作，以便讓應用程式自己決定如何去獲取所需要的類，實作這個動作的代碼模塊稱為“類加載器”，
類加載器雖然只用于實作類的加載動作，但它在Java程式中起到的作用卻遠遠不限于類加載階段，對于任意一個類，都需要由加載它的類加載器和這個類本身一同確立其在Java虛擬機中的唯一性，每一個類加載器，都擁有一個獨立的類名稱空間，這句話可以表達得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類加載器加載的前提下才有意義，否則，即使這兩個類來源于同一個Class檔案，被同一個虛擬機加載，只要加載它們的類加載器不同，那這兩個類就必定不相等，這里所指的“相等”，包括代表類的Class物件的equals()方法、isAssignableFrom()方法、isInstance()方法的回傳結果，也包括使用instanceof關鍵字做物件所屬關系判定等情況，如果沒有注意到類加載器的影響，在某些情況下可能會產生具有迷惑性的結果，
從Java虛擬機的角度來講，只存在兩種不同的類加載器：一種是啟動類加載器, 這個類加載器使用C++語言實作，是虛擬機自身的一部分；另一種就是所有其他的類加載器，這些類加載器都由Java語言實作，獨立于虛擬機外部，并且全都繼承自抽象類java.lang.ClassLoader，
從Java開發人員的角度來看，類加載器還可以劃分得更細致一些，絕大部分Java程式都會使用到以下3種系統提供的類加載器，
（1）啟動類加載器
這個類將器負責將存放在<JAVA_HOME>\lib 目錄中的，或者被-Xbootclasspath引數所指定的路徑中的，并且是虛擬機識別的(僅按照檔案名識別，如rtjar，名字不符合的類別庫即使放在lib目錄中也不會被加載)類別庫加載到虛擬機記憶體中，啟動類加載器無法被Java程式直接參考，用戶在撰寫自定義類加載器時，如果需要把加載請求委派給引導類加載器，那直接使用null代替即可（getClassLoader()回傳null），
（2）擴展類加載器
這個加載器由sun.misc.Launcher$ExtClassLoader實作，它負責加載<JAVA_HOME>\lib\ext 目錄中的，或者被java.ext.dirs系統變數所指定的路徑中的所有類別庫，開發者可以直接使用擴展類加載器，
（3）應用程式類加載器
這個類加載器由sun.misc.Launcher$App-ClassLoader實作，由于這個類加載器是ClassLoader中的getSystemClassLoader()方法的回傳值，所以一般也稱它為系統類加載器，它負責加載用戶類路徑(ClassPath) 上所指定的類別庫，開發者可以直接使用這個類加載器，如果應用程式中沒有自定義過自己的類加載器，一般情況下這個就是程式中默認的類加載器，
（4）自定義類加載器
我們的應用程式都是由上述這3種類加載器互相配合進行加載的，如果有必要，還可以加入自己定義的類加載器，
四、雙親委派模型(機制)
上述這些類加載器之間的關系一般如下圖所示：
圖7-2中展示的類加載器之間的這種層次關系，稱為類加載器的雙親委派模型(ParentsDelegation Model)，雙親委派模型要求除了頂層的啟動類加載器外，其余的類加載器都應當有自己的父類加載器，這里類加載器之間的父子關系一般不會以繼承的關系來實作，而是都使用組合關系來復用父加載器的代碼，
雙親委派模型的作業程序是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請求(它的搜索范圍中沒有找到所需的類)時，子加載器才會嘗試自己去加載，
使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是Java類隨著它的類加載器一起具備了一種帶有優先級的層次關系，例如類java.lang.Object,它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處于模型最頂端的啟動類加載器進行加載，因此Object類在程式的各種類加載器環境中都是同一個類，相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己撰寫了一個稱為java.lang.Object的類，并放在程式的ClassPath中，那系統中將會出現多個不同的Object類，Java型別體系中最基礎的行為也就無法保證，應用程式也將會變得一片混亂，
如果讀者有興趣的話，可以嘗試去撰寫一個與rt.jar類別庫中已有類重名的Java類，將會發現可以正常編譯，但永遠無法被加載運行，
雙親委派模型對于保證Java程式的穩定運作很重要，但它的實作卻非常簡單，實作雙親委派的代碼都集中在java.lang.ClassLoader的loadClass() 方法之中，如下代碼所示，
邏輯清晰易懂：先檢查是否已經被加載過，若沒有加載則呼叫父加載器的loadClass()方法，若父加載器為空則默認使用啟動類加載器作為父加載器，如果父類加載失敗，拋出ClassNotFoundException例外后，再呼叫自己的findClass()方法進行加載，
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { // 首先，檢查請求是否已經被加載過了 Class<?> c = findLoadedClass(name); if (c == null) {try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // 如果父類加載器拋出 ClassNotFoundException
// 說明父類加載器無法完成加載請求
}
if (c == null) {
// 在父類加載器無法加載的時候
// 再呼叫本身的findClass方法來進行加載
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
五、類的卸載
- 由Java虛擬機自帶的類加載器所加載的類，在虛擬機的生命周期中，始終不會被卸載，這些類加載器會始終參考它們所加載的類的Class物件，因此這些Class物件始終是可觸及的，
- 由用戶自定義的類加載器所加載的類是可以被卸載的
-- 參考資料：
《深入理解Java虛擬機--JVM高級特性與最佳實踐 第2版》 --周志明 著
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/125382.html
標籤：Java
上一篇：JVM記憶體區域