類加載過程

類加載的五個過程：加載、驗證、準備、解析、初始化。

加載

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

1. 通過一個類的全限定名來獲取定義此類的二進制字節流。
2. 將這個字節流所代表的靜態存儲結構轉化為方法區域的運行時數據結構。
3. 在JAVA堆中生成一個代表這個類的java.lang.Class對象，作為方法區域數據的訪問入口。

驗證

驗證階段作用是保證Class文件的字節流包含的信息符合JVM規范，不會給JVM造成危害。如果驗證失敗，就會拋出一個java.lang.VerifyError異常或其子類異常。驗證過程分為四個階段：

1. 文件格式驗證：驗證字節流文件是否符合Class文件格式的規范，并且能被當前虛擬機正確的處理。
2. 元數據驗證：是對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言的規范要求
3. 字節碼驗證：主要是進行數據流和控制流的分析，保證被校驗類的方法在運行時不會危害虛擬機。
4. 符號引用驗證：符號引用驗證發生在虛擬機將符號引用轉化為直接引用的時候，這個轉化動作將在解析階段中發生。

準備

準備階段為變量分配內存并設置類變量的初始化。在這個階段分配的僅為類的變量（static修飾的變量），而不包括類的實例變量。對已非final的變量，JVM會將其設置成“零值”，而不是其賦值語句的值：pirvate static int size = 12;。那么在這個階段，size的值為0，而不是12。但final修飾的類變量將會賦值成真實的值。

解析

解析過程是將常量池內的符號引用替換成直接引用。主要包括四種類型引用的解析。類或接口的解析、字段解析、方法解析、接口方法解析。

初始化

在準備階段，類變量已經經過一次初始化了，在這個階段，則是通過程序制定的計劃去初始化類的變量和其他資源。這些資源有static{}塊，構造函數，父類的初始化等。

至于使用和卸載階段階段，這里不再過多說明，使用過程就是根據程序定義的行為執行，卸載由GC完成。

雙親委派模型

類加載器按照層次，從頂層到底層，分為以下三種：

1. 啟動類加載器（BootstrapClassLoader）
2. 這個類加載器負責加載%JRE_HOME%lib下的rt.jar、resources.jar、charsets.jar和class等。可以通System.getProperty("sun.boot.class.path")查看加載的路徑。
3. 擴展類加載器（ExtensionClassLoader）
4. 負責加載目錄%JRE_HOME%libext目錄下的jar包和class文件。也可以通過System.out.println(System.getProperty("java.ext.dirs"))查看加載類文件的路徑。
5. 應用程序類加載器（ApplicationClassLoader）
6. 這個加載器是ClassLoader中getSystemClassLoader()方法的返回值，所以一般也稱它為系統類加載器。它負責加載用戶類路徑（Classpath）上所指定的類庫，可直接使用這個加載器，如果應用程序沒有自定義自己的類加載器，一般情況下這個就是程序中默認的類加載。

上圖只是類加載的順序，和類繼承無關。ExtClassLoader，AppClassLoder繼承URLClassLoader，而URLClassLoader繼承ClassLoader。BoopStrap ClassLoder是由C/C++編寫的，它本身是虛擬機的一部分，并不是一個java類。

AppClassLoader的父加載器為ExtClassLoader，ExtClassLoader的父加載器為null，BoopStrap ClassLoader為頂級加載器

工作過程

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

相對應的實現邏輯：先檢查類是否被加載過，若沒有就調用父加載器的loadClass方法，若父加載器為空則默認使用啟動類加載器作為父加載器。如果父加載器加載失敗，拋出異常，再調用自己的findClass方法進行加載。

具體示例：

假如我們自定義Test class文件，jvm要加載Test.class的時候：

1. 首先會到自定義加載器中查找，看是否已經加載過，如果已經加載過，則返回字節碼。
2. 如果自定義加載器沒有加載過，則詢問上一層加載器(即AppClassLoader)是否已經加載過Test.class。
3. 如果沒有加載過，則詢問上一層加載器（ExtClassLoader）是否已經加載過。
4. 如果沒有加載過，則繼續詢問上一層加載（BoopStrap ClassLoader）是否已經加載過。
5. 如果BoopStrap ClassLoader依然沒有加載過，則到自己指定類加載路徑下（"sun.boot.class.path"）查看是否有Test.class字節碼，有則返回，沒有通知下一層加載器ExtClassLoader到自己指定的類加載路徑下（java.ext.dirs）查看。
6. 依次類推，最后到自定義類加載器指定的路徑還沒有找到Test.class字節碼，則拋出異常ClassNotFoundException。

雙親委派的好處

Java類隨著它的類加載器一起具備了一種帶有優先級的層次關系。例如類Object，它放在rt.jar中，無論哪一個類加載器要加載這個類，最終都是委派給啟動類加載器進行加載，因此Object類在程序的各種類加載器環境中都是同一個類。

判斷兩個類是否相同是通過classloader.class這種方式進行的，所以哪怕是同一個class文件如果被兩個classloader加載，那么他們也是不同的類。

實現自己的加載器，只需要繼承ClassLoader，并覆蓋findClass方法。

對象創建過程

對象的流程

1. 類加載檢查

JVM遇到一條new指令時，首先檢查這個指令的參數是否能在常量池中定位到一個類的符號引用，并且檢查這個符號引用代表的類是否已被加載、解析和初始化過。

如果沒有，那必須先執行相應的類的加載過程。

2. 對象分配內存

對象所需內存的大小在類加載完成后便完全確定（對象內存布局），為對象分配空間的任務等同于把一塊確定大小的內存從Java堆中劃分出來。

根據Java堆中是否規整有兩種內存的分配方式：（Java堆是否規整由所采用的垃圾收集器是否帶有壓縮整理功能決定）。

• 指針碰撞(Bump the pointer)
• Java堆中的內存是規整的，所有用過的內存都放在一邊，空閑的內存放在另一邊，中間放著一個指針作為分界點的指示器，分配內存也就是把指針向空閑空間那邊移動一段與內存大小相等的距離。例如：Serial、ParNew等收集器。
• 空閑列表(Free List)
• Java堆中的內存不是規整的，已使用的內存和空閑的內存相互交錯，就沒有辦法簡單的進行指針碰撞了。虛擬機必須維護一張列表，記錄哪些內存塊是可用的，在分配的時候從列表中找到一塊足夠大的空間劃分給對象實例，并更新列表上的記錄。例如：CMS這種基于Mark-Sweep算法的收集器。

3. 并發處理

對象創建在虛擬機中時非常頻繁的行為，即使是僅僅修改一個指針指向的位置，在并發情況下也并不是線程安全的，可能出現正在給對象A分配內存，指針還沒來得及修改，對象B又同時使用了原來的指針來分配內存的情況。解決這個問題有兩種方案：

• 同步
• 虛擬機采用CAS配上失敗重試的方式保證更新操作的原子性
• 本地線程分配緩沖（Thread Local Allocation Buffer, TLAB）
• 把內存分配的動作按照線程劃分為在不同的空間之中進行，即每個線程在Java堆中預先分配一小塊內存（TLAB）。哪個線程要分配內存，就在哪個線程的TLAB上分配。只有TLAB用完并分配新的TLAB時，才需要同步鎖定。

虛擬機是否使用TLAB，可以通過-XX：+/-UseTLAB參數來設定。

4. 內存空間初始化

虛擬機將分配到的內存空間都初始化為零值（不包括對象頭）,如果使用了TLAB，這一工作過程也可以提前至TLAB分配時進行。

內存空間初始化保證了對象的實例字段在Java代碼中可以不賦初始值就直接使用，程序能訪問到這些字段的數據類型所對應的零值。

注意：類的成員變量可以不顯示地初始化（Java虛擬機都會先自動給它初始化為默認值）。方法中的局部變量如果只負責接收一個表達式的值，可以不初始化，但是參與運算和直接輸出等其它情況的局部變量需要初始化。

5. 對象設置

虛擬機對對象進行必要的設置，例如這個對象是哪個類的實例、如何才能找到類的元數據信息、對象的哈希碼、對象的GC分代年齡等信息。這些信息存放在對象的對象頭之中。

6. 執行init()

在上面的工作都完成之后，從虛擬機的角度看，一個新的對象已經產生了。但是從Java程序的角度看，對象的創建才剛剛開始init()方法還沒有執行，所有的字段都還是零。

所以，一般來說（由字節碼中是否跟隨invokespecial指令所決定），執行new指令之后會接著執行init()方法，把對象按照程序員的意愿進行初始化，這樣一個真正可用的對象才算產生出來。

對象的內存布局

在HotSpot虛擬機中。對象在內存中存儲的布局分為：

1. 對象頭
2. 實例數據
3. 對齊填充

對象頭

HotSpot虛擬機的對象頭包括兩部分信息：運行時數據和類型指針。

• 運行時數據：用于存儲對象自身的運行時數據，如哈希碼（HashCode）、GC分代年齡、鎖狀態標志、線程持有的鎖、偏向線程ID、偏向時間戳等。
• 類型指針：對象指向它的類元數據的指針，虛擬機通過這個指針來確定這個對象是哪個類的實例。

如果對象是一個Java數組，那在對象頭中還必須有一塊用于記錄數組長度的數據，因為虛擬機可以通過普通Java對象的元數據信息確定Java對象的大小，但是從數組的元數據中無法確定數組的大小。

(并不是所有的虛擬機實現都必須在對象數據上保留類型指針，換句話說，查找對象的元數據并不一定要經過對象本身，可參考對象的訪問定位)

HotSpot底層通過markOop實現Mark word，具體實現位于markOop.hpp文件。markOop中提供了大量方法用于查看當前對象頭的狀態，以及更新對象頭的數據，為synchronized鎖的實現提供了基礎。[比如說我們知道synchronized鎖的是對象而不是代碼，而鎖的狀態保存在對象頭中，進而實現鎖住對象]。

有關synchronized的進一步介紹，可以點擊查看：詳解Java多線程鎖之synchronized

實例數據

實例數據部分是對象真正存儲的有效信息，也是在程序代碼中所定義的各種類型的字段內容。無論是從父類中繼承下來的，還是在子類中定義的，都需要記錄下來。HotSpot虛擬機默認的分配策略為longs/doubles、ints、shorts/chars、bytes/booleans、oop，從分配策略中可以看出，相同寬度的字段總是分配到一起。

對齊填充

HotSpot虛擬機要求對象的起始地址必須是8字節的整數倍，也就是對象的大小必須是8字節的整數倍。而對象頭部分正好是8字節的倍數（1倍或者2倍），因此，當對象實例數據部分沒有對齊的時候，就需要通過對齊填充來補全。

對象的訪問定位

java程序需要通過引用(ref)數據來操作堆上面的對象，那么如何通過引用定位、訪問到對象的具體位置。

對象的訪問方式由虛擬機決定，java虛擬機提供兩種主流的方式

1.句柄訪問對象

2.直接指針訪問對象。(Sun HotSpot使用這種方式)

句柄訪問

簡單來說就是java堆劃出一塊內存作為句柄池,引用中存儲對象的句柄地址,句柄中包含對象實例數據、類型數據的地址信息。

優點:引用中存儲的是穩定的句柄地址，在對象被移動【垃圾收集時移動對象是常態】只需改變句柄中實例數據的指針，不需要改動引用【ref】本身。

直接指針

在這種方式中，JVM棧中的棧幀中的本地變量表中所存儲的引用地址就是實例數據的地址。通過這個引用就能直接獲取到實例數據的地址。

其實引用所指向的對內存中的對象數據有兩部分組成，一部分就是這個對象實例本身，另一部分是對象類型在方法區中的地址。

優點：優勢很明顯，就是速度快，相比于句柄訪問少了一次指針定位的開銷時間。由于對象的訪問在Java中非常頻繁，因此這類開銷積少成多后也是一項非常可觀的執行成本。虛擬機Sun HotSpot而言，它是使用第二種方式進行對象訪問的，但從整個軟件開發的范圍來看，各種語言和框架使用句柄來訪問的情況也十分常見。