類加載機制：類的資料從Class檔案加載到記憶體，并對資料進行校驗、轉換決議和初始化，最 終形成可以被虛擬機直接使用的Java型別，

類的生命周期：一個型別從被加載到虛擬機記憶體中開始，到卸載出記憶體為止，它的整個生命周期將會經歷加載 （Loading）、驗證（Verification）、準備（Preparation）、決議（Resolution）、初始化 （Initialization）、使用（Using）和卸載（Unloading）七個階段，其中驗證、準備、決議三個部分統稱 為連接（Linking），
其中決議也可以在初始化之后再開始，位置并不是唯一的，

加載
在加載階段，虛擬機要完成三件事情

1.通過類的全限定名來獲取定義此類的二進制位元組流
2.將這個位元組流所代表的靜態存盤結構轉化為方法區的運行時資料結構
3.在記憶體中生成一個代表這個類的java.lang.class物件，作為方法區這個類的各種資料訪問的入口

這個階段需要用到加載器，“雙親委派模型”與此有關，陣列類物件是虛擬機直接在動態記憶體中構造出來，但這個陣列的組件型別由加載器加載，比如int[]，char[]組件型別不是參考型別，由引導類加載器加載，而類似Integer[]這種組件為參考型別的，就按照本文說的步驟加載，

而關于第一點，獲取類的二進制位元組流，并沒有規定必須從哪里獲取，從ZIP壓縮包讀取，從網路中獲取（例如Web Applet），運算時計算生成（如動態代理），其他檔案生成（如JSP），從加密檔案中獲取等等，

驗證
Class檔案可以由Java源代碼編譯而來，但它也可以由其他途徑產生，畢竟Class檔案只是一種格式，最底層的還是0/1，它可以使用包括靠鍵盤0和1直接在二進制編輯器中敲出 Class檔案在內的任何途徑產，Java虛擬機如果不檢查輸入的位元組流，對其完全信任的話，很可能會因為 載入了有錯誤或有惡意企圖的位元組碼流而導致整個系統受攻擊甚至崩潰，

檔案格式驗證：檢查是否符合Class檔案的格式，如Class檔案開頭的魔數，主次版本號是否可以被虛擬機接受、常量池是否正確等等

元資料驗證：對類的元資料資訊進行語意校驗，比如是否有父類，是否繼承了不被允許的類、是否實作了介面或者抽象類中的方法等等

位元組碼驗證：通過資料流分析和控制流分析，確定 程式語意是合法的、符合邏輯的，就是對將要執行的程式位元組碼驗證（即Class中的Code屬性），是否出現了邏輯性的錯誤，位元組碼驗證有問題，則程式一定不對，但位元組碼驗證沒問題，程式不一定能正確執行，通程序式去校驗程式邏輯是無法做到絕對準 確的，不可能用程式來準確判定一段程式是否存在Bug，這一階段很費時間，所以在編譯器生成Class檔案時就會生成StackMapTable，這樣虛擬機直接檢查StackMapTable記錄是否合法就行，

符號參考驗證：驗證將符號參考轉化為直接參考時候合法，判斷該類是否缺少或者被禁止訪問它依賴的某些外部 類、方法、欄位等資源，這個動作實在決議階段進行的，所以這7個步驟并不是嚴格的順序，很多時候是交替進行的，

驗證階段有點類似查殺病毒，確保虛擬機執行的Class檔案都是正確的，它很重要但并不是必須的，如果使用的Class類都是經過反復使用和驗證的，那就可以關閉類驗證措施，縮小類加載的時間，就像不開啟防火墻，不下載一些惡意軟體也能正常使用計算機，

準備
準備階段是為類中靜態變數分配記憶體并設定類變數初 始值的階段，此處僅包括靜態變數（static修飾），而不包括實體變數，實體變數實在物件實體化的時候隨著物件一起分配在堆中，而且此處的初始值指的資料型別默認的零指，比如 public static int a = 123, 準備階段會給a賦值為0，而不是123，a變成123是類構造器完成的，所以是在初始化階段才會執行，也有例外，如果此處類欄位屬性存在ConstantValue屬性，那么在準備階段就會賦值，例如public static final int value = 123， 添加final關鍵字后類會有ConstantValue屬性，此時在準備階段a就會被賦值為123.

決議
決議階段是Java虛擬機將常量池內的符號參考替換為直接參考的程序，符號參考是以一組符號來描述所參考的目標，它與虛擬機實作的記憶體布局無關，參考的目標并不一定是已經加載到虛擬機記憶體當中的內容，而直接參考是可以直接指向目標的指標、相對偏移量或者是一個能間接定位到目標的句柄，如果有了直接參考，那參考的目標必定已經在虛擬機 的記憶體中存在，

初始化
類加載程序最后一步，進行準備階段時，靜態變數已經賦過一次系統要求的初始零值，而在初始化階段，則會根據程式員通 程序式編碼制定的主觀計劃去初始化類變數和其他資源，通俗的說初始化就是執行類構造器()方法的程序，（）方法是由編譯器自動收集類中的所有類變數的賦值動作和靜態陳述句塊（static{}塊）中的 陳述句合并產生的，編譯器收集的順序是由陳述句在源檔案中出現的順序決定的，靜態陳述句塊中只能訪問 到定義在靜態陳述句塊之前的變數，定義在它之后的變數，在前面的靜態陳述句塊可以賦值，但是不能訪問，

public class Test {
static { i = 0; // 給變數復制可以正常編譯通過 可以給后面定義都賦值
System.out.print(i); // 這句編譯器會提示“非法向前參考” static int i=1在此之后才定義 無法訪問}
static int i = 1; //此處才定義
}

父類中的（）方法在子類之前執行，保證在子類執行前父類的（）已經執行完畢，()方法對于類或介面來說并不是必需的，如果一個類中沒有靜態陳述句塊，也沒有對變數的 賦值操作，那么編譯器可以不為這個類生成()方法，

類加載器

在類加載流程第一步“加載”階段，通過一個類的全限定名來獲取描述該類的二進制位元組流，實作這一功能的代碼叫做類加載器，Java中的任意一個類，都必須由加載它的類加載器和這個類本身一起共同確立其在Java虛擬機中的唯一性，每 一個類加載器，都擁有一個獨立的類名稱空間，

判斷兩個類是否相等，必須在這兩個類是被同一個加載器加載的前提下才有意義，否則即使Class檔案相同，被同一個虛擬機加載，但是使用不同的類加載器，那么兩個類也是不同的，

雙親委派模型

如果一個類被不同的加載器加載，那虛擬機會認定是不同的類，這樣Java體系最基礎的行為也無從保證，應用程式會變得混亂，所以有了雙親委派模型，雙親委派一共分了四層的加載器，求除了頂層的啟動類加載器外，其余的類加載器都應有自己的父類加載器，子類使用“組合”關系來復用父類加載器的代碼，而不是繼承，

雙親委派模型一共分四層：
啟動類加載器：負責加載存放在 <JAVA_HOME>\lib目錄，或者被-Xbootclasspath引數所指定的路徑中存放的類
擴展類加載器：它負責加載<JAVA_HOME>\lib\ext目錄中，或者被java.ext.dirs系統變數所 指定的路徑中所有的類別庫
應用類加載器：負責加載用戶類路徑 （ClassPath）上所有的類別庫，開發者同樣可以直接在代碼中使用這個類加載器，如果應用程式中沒有 自定義過自己的類加載器，一般情況下這個就是程式中默認的類加載器，
自定義加載器：用戶自行擴展，典型的如增加除了磁盤位置之外的Class檔案來源，或者通過類 加載器實作類的隔離、多載等功能，

果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加 載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的 加載請求最終都應該傳送到最頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請 求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去完成加載，

破壞雙親委派

親委派很好地解決了各個類 加載器協作時基礎型別的一致性問題（越基礎的類由越上層的加載器進行加載），但如果有基礎型別又要呼叫回用戶的代碼就不得不破壞雙親委派模型，也就是父類加載器需要去請求子類加載器去完成需要的類，典型例子如JNDI，JNDI的代碼由啟動類加載器完成加載，但是這個類需要應用程式ClassPath下的JNDI服務提供者介面，啟動類加載器無法加載這些代碼，為解決這個問題使用執行緒背景關系類加載器，JNDI服務使用這個執行緒背景關系類 加載器去加載所需的SPI服務代碼，這是一種父類加載器去請求子類加載器完成類加載的行為，這種行 為實際上是打通了雙親委派模型的層次結構來逆向使用類加載器，

OSGi實作模塊化熱部署：在OSGi環境下，類加載器不再雙親委派模型推薦的樹狀結構，而是進一步發展為更 加復雜的網狀結構，