jvm系列學習之--Java的類加載機制
轉載：https://segmentfault.com/a/1190000004597758
本文主要講述Java類的加載機制，主要包括類加載器、加載過程、初始化時機。
一、類加載器
1、ClassLoader抽象類
類加載器的任務就是根據一個類的全限定名來讀取此類的二進制字節流到JVM內部，然後轉換為一個與目標類對應的java.lang.Class對象實例。
如果需要支持類的動態加載或需要對編譯後的字節碼文件進行解密操作等，就需要與類加載器打交道了。
-
BootstrapClassLoader，由C++編寫嵌套在JVM內部，負責加載“JAVA_HOME/lib”目錄中的所有類型，或者由“-Xbootclasspath”指定路徑中的所有類型。
-
ExtClassLoader和AppClassLoader都繼承至ClassLoader抽象類，由Java編寫。
-
ExtClassLoader負責加載“JAVA_HOME/lib/ext”目錄下的所有類型。
-
AppClassLoader負責加載ClassPath目錄中的所有類型。
defineClass方法將字節碼的byte數組轉換為一個類的Class對象實例，如果希望在類被加載到JVM內部時就被鏈接，那麽可以調用resolveClass方法。
2、雙親委派模型
Parents Delegation Model，雙親委派模型，約定類加載器的加載機制。
當一個類加載器接收到一個類加載的任務時，不會立即展開加載，而是將加載任務委派給它的超類加載器去執行，每一層的類都采用相同的方式，直至委派給最頂層的啟動類加載器為止。如果超類加載器無法加載委派給它的類，便將類的加載任務退回給下一級類加載器去執行加載。
雙親委派模型的工作過程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器中，只有當父加載器反饋自己無法完成這個加載請求（它的搜索範圍中沒有找到所需的類）時，子加載器才會嘗試自己去加載。
使用這種方式的好處是：能夠有效確保一個類的全局唯一性，當程序中出現多個全限定名相同的類時，類加載器在執行加載時，始終只會加載其中的某一個類。
使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是Java類隨著它的類加載器一起具備了一種帶有優先級的層次關系
雙親委派模型對於保證Java程序的穩定運作很重要，但它的實現卻非常簡單，實現雙親委派的代碼都集中在java.lang.ClassLoader的loadClass()方法之中，邏輯清晰易懂：先檢查是否已經被加載過，若沒有加載則調用父加載器的loadClass()方法，若父加載器為空則默認使用啟動類加載器作為父加載器。如果父類加載失敗，拋出ClassNotFoundException異常後，再調用自己的findClass()方法進行加載。
雙親委派機制只是Java虛擬機規範建議采用的加載機制，實際在tomcat中，類加載器所采用的加載機制與傳統的雙親委派模型有一定的區別，當缺省的類加載器接收到一個類的加載任務時，首先會去由它自行加載，當它加載失敗時，才會將類的加載任務委派給它的超類加載器去執行。
3、自定義類加載器
程序中如果沒有顯式指定類加載器的話，默認是AppClassLoader來加載，它負責加載ClassPath目錄中的所有類型，如果被加載的類型並沒有在ClassPath目錄中時，拋出java.lang.ClassNotFoundException異常。
一般是繼承ClassLoader，如果要符合雙親委派規範，則重寫findClass方法；要破壞的話，重寫loadClass方法。
雙親委派模型的第一次“被破壞”其實發生在雙親委派模型出現之前——即JDK 1.2發布之前。由於雙親委派模型在JDK 1.2之後才被引入，而類加載器和抽象類java.lang.ClassLoader則在JDK1.0時代就已經存在，面對已經存在的用戶自定義類加載器的實現代碼，Java設計者引入雙親委派模型時不得不做出一些妥協。
為了向前兼容，JDK 1.2之後的java.lang.ClassLoader添加了一個新的protected方法findClass()，在此之前，用戶去繼承java.lang.ClassLoader的唯一目的就是為了重寫loadClass()方法，因為虛擬機在進行類加載的時候會調用加載器的私有方法loadClassInternal()，而這個方法的唯一邏輯就是去調用自己的load-Class()。
上一節我們已經看過loadClass()方法的代碼，雙親委派的具體邏輯就實現在這個方法之中，JDK1.2之後已不提倡用戶再去覆蓋loadClass()方法，而應當把自己的類加載邏輯寫到findClass()方法中，在loadClass()方法的邏輯裏如果父類加載失敗，則會調用自己的findClass()方法來完成加載，這樣就可以保證新寫出來的類加載器是符合雙親委派規則的。
二、類加載過程
一個完整的類加載過程必須經歷加載、連接、初始化這三個步驟：
1、加載
簡單的說，類加載階段就是由類加載器負責根據一個類的全限定名來讀取此類的二進制字節流到JVM內部，並存儲在運行時內存區的方法區，然後將其轉換為一個與目標類型對應的java.lang.Class對象實例（Java虛擬機規範並沒有明確要求一定要存儲在堆區中，只是hotspot選擇將Class對象存儲在方法區中），這個Class對象在日後就會作為方法區中該類的各種數據的訪問入口。
2、連接
連接階段要做的是將加載到JVM中的二進制字節流的類數據信息合並到JVM的運行時狀態中，經由驗證、準備、解析三個階段。
（1）驗證階段
驗證類數據信息是否符合JVM規範，是否是一個有效的字節碼文件，驗證內容涵蓋了類數據信息的格式驗證、語義分析、操作驗證等
格式驗證：驗證是否符合class文件規範，比如以0xCAFEBABE開頭，大小版本號等
語義驗證：
a、檢查一個被標記為final的類型是否包含派生類
b、檢查一個類中的final方法是否被派生類進行重寫
c、確保超類與派生類之間沒有不兼容的一些方法聲明（比如方法簽名相同，但方法的返回值不同）
操作驗證：
在操作數棧中的數據必須進行正確的操作，對常量池中的各種符號引用執行驗證（通常在解析階段執行，檢查是否能通過符號引用中描述的全限定名定位到指定類型上，以及類成員信息的訪問修飾符是否允許訪問等）。
（2）準備階段
為類中的所有靜態變量分配內存空間，並為其設置一個初始值（由於還沒有產生對象，實例變量將不再此操作範圍內）
（3）解析階段
將常量池中所有的符號引用轉為直接引用（得到類或者字段、方法在內存中的指針或者偏移量，以便直接調用該方法）。這個階段可以在初始化之後再執行。
3、初始化
將一個類中所有被static關鍵字標識的代碼統一執行一遍，如果執行的是靜態變量，那麽就會使用用戶指定的值覆蓋之前在準備階段設置的初始值；如果執行的是static代碼塊，那麽在初始化階段，JVM就會執行static代碼塊中定義的所有操作。
所有類變量初始化語句和靜態代碼塊都會在編譯時被前端編譯器放在收集器裏頭，存放到一個特殊的方法中，這個方法就是<clinit>方法，即類/接口初始化方法。該方法的作用就是初始化一個類中的變量，使用用戶指定的值覆蓋之前在準備階段設定的初始值。任何invoke之類的字節碼都無法調用<clinit>方法，因為該方法只能在類加載的過程中由JVM調用。
如果超類還沒有被初始化，那麽優先對超類初始化，但在<clinit>方法內部不會顯示調用超類的<clinit>方法，由JVM負責保證一個類的<clinit>方法執行之前，它的超類<clinit>方法已經被執行。
JVM必須確保一個類在初始化的過程中，如果是多線程需要同時初始化它，僅僅只能允許其中一個線程對其執行初始化操作，其余線程必須等待，只有在活動線程執行完對類的初始化操作之後，才會通知正在等待的其他線程。
只有那些需要執行java代碼來為類變量執行賦值操作的類型在編譯之後才會在字節碼中存在生成的<clinit>方法。如果一個類並沒有聲明任何的類變量，也沒有靜態代碼塊，那麽這個類在編譯為字節碼後，字節碼文件中將不會包含<clinit>方法；同樣如果一個類聲明類變量，但沒有明確使用類變量的初始化語句以及靜態代碼塊來執行初始化操作，編譯後的字節碼中也不會有<clinit>方法；只有final的靜態變量也不會有該方法。
類初始化的6種時機
（1）為一個類型創建一個新的對象實例時（比如new、反射、序列化）
（2）調用一個類型的靜態方法時（即在字節碼中執行invokestatic指令）
（3）調用一個類型或接口的靜態字段，或者對這些靜態字段執行賦值操作時（即在字節碼中，執行getstatic或者putstatic指令），不過用final修飾的靜態字段除外，它被初始化為一個編譯時常量表達式
（4）調用JavaAPI中的反射方法時（比如調用java.lang.Class中的方法，或者java.lang.reflect包中其他類的方法）
（5）初始化一個類的派生類時（Java虛擬機規範明確要求初始化一個類時，它的超類必須提前完成初始化操作，接口例外）
（6）JVM啟動包含main方法的啟動類時。
數組本身並不是由類加載器負責創建，而是由JVM在運行時根據需要而直接創建的，但數組的元素類型仍然需要依靠類加載器去創建。
jvm系列學習之--Java的類加載機制