摘要：如果需要支持類的動態(tài)加載或需要對編譯后的字節(jié)碼文件進(jìn)行解密操作等，就需要與類加載器打交道了。雙親委派模型，雙親委派模型，約定類加載器的加載機(jī)制。任何之類的字節(jié)碼都無法調(diào)用方法，因為該方法只能在類加載的過程中由調(diào)用。

jvm系列

垃圾回收基礎(chǔ)

JVM的編譯策略

GC的三大基礎(chǔ)算法

GC的三大高級算法

GC策略的評價指標(biāo)

JVM信息查看

GC通用日志解讀

jvm的card table數(shù)據(jù)結(jié)構(gòu)

Java類初始化順序

Java對象結(jié)構(gòu)及大小計算

Java的類加載機(jī)制

Java對象分配簡要流程

年老代過大有什么影響

Survivor空間溢出實例

關(guān)于Object=null

Java線程與Xss

本文主要講述Java類的加載機(jī)制，主要包括類加載器、加載過程、初始化時機(jī)。

類加載器的任務(wù)就是根據(jù)一個類的全限定名來讀取此類的二進(jìn)制字節(jié)流到JVM內(nèi)部，然后轉(zhuǎn)換為一個與目標(biāo)類對應(yīng)的java.lang.Class對象實例。

如果需要支持類的動態(tài)加載或需要對編譯后的字節(jié)碼文件進(jìn)行解密操作等，就需要與類加載器打交道了。

BootstrapClassLoader，由C++編寫嵌套在JVM內(nèi)部，負(fù)責(zé)加載“JAVA_HOME/lib”目錄中的所有類型，或者由“-Xbootclasspath”指定路徑中的所有類型。

ExtClassLoader和AppClassLoader都繼承至ClassLoader抽象類，由Java編寫。

ExtClassLoader負(fù)責(zé)加載“JAVA_HOME/lib/ext”目錄下的所有類型。

AppClassLoader負(fù)責(zé)加載ClassPath目錄中的所有類型。

defineClass方法將字節(jié)碼的byte數(shù)組轉(zhuǎn)換為一個類的Class對象實例，如果希望在類被加載到JVM內(nèi)部時就被鏈接，那么可以調(diào)用resolveClass方法。

Parents Delegation Model，雙親委派模型，約定類加載器的加載機(jī)制。

當(dāng)一個類加載器接收到一個類加載的任務(wù)時，不會立即展開加載，而是將加載任務(wù)委派給它的超類加載器去執(zhí)行，每一層的類都采用相同的方式，直至委派給最頂層的啟動類加載器為止。如果超類加載器無法加載委派給它的類，便將類的加載任務(wù)退回給下一級類加載器去執(zhí)行加載。

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

使用這種方式的好處是：能夠有效確保一個類的全局唯一性，當(dāng)程序中出現(xiàn)多個全限定名相同的類時，類加載器在執(zhí)行加載時，始終只會加載其中的某一個類。

使用雙親委派模型來組織類加載器之間的關(guān)系，有一個顯而易見的好處就是Java類隨著它的類加載器一起具備了一種帶有優(yōu)先級的層次關(guān)系。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處于模型最頂端的啟動類加載器進(jìn)行加載，因此Object類在程序的各種類加載器環(huán)境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己編寫了一個稱為java.lang.Object的類，并放在程序的Class-Path中，那系統(tǒng)中將會出現(xiàn)多個不同的Object類，Java類型體系中最基礎(chǔ)的行為也就無法保證，應(yīng)用程序也將會變得一片混亂。如果自己去編寫一個與rt.jar類庫中已有類重名的Java類，將會發(fā)現(xiàn)可以正常編譯，但永遠(yuǎn)無法被加載運行。

雙親委派模型對于保證Java程序的穩(wěn)定運作很重要，但它的實現(xiàn)卻非常簡單，實現(xiàn)雙親委派的代碼都集中在java.lang.ClassLoader的loadClass()方法之中，邏輯清晰易懂：先檢查是否已經(jīng)被加載過，若沒有加載則調(diào)用父加載器的loadClass()方法，若父加載器為空則默認(rèn)使用啟動類加載器作為父加載器。如果父類加載失敗，拋出ClassNotFoundException異常后，再調(diào)用自己的findClass()方法進(jìn)行加載。

雙親委派機(jī)制只是Java虛擬機(jī)規(guī)范建議采用的加載機(jī)制，實際在tomcat中，類加載器所采用的加載機(jī)制與傳統(tǒng)的雙親委派模型有一定的區(qū)別，當(dāng)缺省的類加載器接收到一個類的加載任務(wù)時，首先會去由它自行加載，當(dāng)它加載失敗時，才會將類的加載任務(wù)委派給它的超類加載器去執(zhí)行。

程序中如果沒有顯式指定類加載器的話，默認(rèn)是AppClassLoader來加載，它負(fù)責(zé)加載ClassPath目錄中的所有類型，如果被加載的類型并沒有在ClassPath目錄中時，拋出java.lang.ClassNotFoundException異常。

一般是繼承ClassLoader，如果要符合雙親委派規(guī)范，則重寫findClass方法；要破壞的話，重寫loadClass方法。

雙親委派模型的第一次“被破壞”其實發(fā)生在雙親委派模型出現(xiàn)之前——即JDK 1.2發(fā)布之前。由于雙親委派模型在JDK 1.2之后才被引入，而類加載器和抽象類java.lang.ClassLoader則在JDK1.0時代就已經(jīng)存在，面對已經(jīng)存在的用戶自定義類加載器的實現(xiàn)代碼，Java設(shè)計者引入雙親委派模型時不得不做出一些妥協(xié)。

為了向前兼容，JDK 1.2之后的java.lang.ClassLoader添加了一個新的protected方法findClass()，在此之前，用戶去繼承java.lang.ClassLoader的唯一目的就是為了重寫loadClass()方法，因為虛擬機(jī)在進(jìn)行類加載的時候會調(diào)用加載器的私有方法loadClassInternal()，而這個方法的唯一邏輯就是去調(diào)用自己的load-Class()。

上一節(jié)我們已經(jīng)看過loadClass()方法的代碼，雙親委派的具體邏輯就實現(xiàn)在這個方法之中，JDK1.2之后已不提倡用戶再去覆蓋loadClass()方法，而應(yīng)當(dāng)把自己的類加載邏輯寫到findClass()方法中，在loadClass()方法的邏輯里如果父類加載失敗，則會調(diào)用自己的findClass()方法來完成加載，這樣就可以保證新寫出來的類加載器是符合雙親委派規(guī)則的。

一個完整的類加載過程必須經(jīng)歷加載、連接、初始化這三個步驟：

簡單的說，類加載階段就是由類加載器負(fù)責(zé)根據(jù)一個類的全限定名來讀取此類的二進(jìn)制字節(jié)流到JVM內(nèi)部，并存儲在運行時內(nèi)存區(qū)的方法區(qū)，然后將其轉(zhuǎn)換為一個與目標(biāo)類型對應(yīng)的java.lang.Class對象實例（Java虛擬機(jī)規(guī)范并沒有明確要求一定要存儲在堆區(qū)中，只是hotspot選擇將Class對象存儲在方法區(qū)中），這個Class對象在日后就會作為方法區(qū)中該類的各種數(shù)據(jù)的訪問入口。

連接階段要做的是將加載到JVM中的二進(jìn)制字節(jié)流的類數(shù)據(jù)信息合并到JVM的運行時狀態(tài)中，經(jīng)由驗證、準(zhǔn)備、解析三個階段。

（1）驗證階段
驗證類數(shù)據(jù)信息是否符合JVM規(guī)范，是否是一個有效的字節(jié)碼文件，驗證內(nèi)容涵蓋了類數(shù)據(jù)信息的格式驗證、語義分析、操作驗證等

格式驗證：驗證是否符合class文件規(guī)范，比如以0xCAFEBABE開頭，大小版本號等

語義驗證：
a、檢查一個被標(biāo)記為final的類型是否包含派生類
b、檢查一個類中的final方法是否被派生類進(jìn)行重寫
c、確保超類與派生類之間沒有不兼容的一些方法聲明（比如方法簽名相同，但方法的返回值不同）

操作驗證：
在操作數(shù)棧中的數(shù)據(jù)必須進(jìn)行正確的操作，對常量池中的各種符號引用執(zhí)行驗證（通常在解析階段執(zhí)行，檢查是否能通過符號引用中描述的全限定名定位到指定類型上，以及類成員信息的訪問修飾符是否允許訪問等）。

（2）準(zhǔn)備階段
為類中的所有靜態(tài)變量分配內(nèi)存空間，并為其設(shè)置一個初始值（由于還沒有產(chǎn)生對象，實例變量將不再此操作范圍內(nèi)）

（3）解析階段
將常量池中所有的符號引用轉(zhuǎn)為直接引用（得到類或者字段、方法在內(nèi)存中的指針或者偏移量，以便直接調(diào)用該方法）。這個階段可以在初始化之后再執(zhí)行。

將一個類中所有被static關(guān)鍵字標(biāo)識的代碼統(tǒng)一執(zhí)行一遍，如果執(zhí)行的是靜態(tài)變量，那么就會使用用戶指定的值覆蓋之前在準(zhǔn)備階段設(shè)置的初始值；如果執(zhí)行的是static代碼塊，那么在初始化階段，JVM就會執(zhí)行static代碼塊中定義的所有操作。

所有類變量初始化語句和靜態(tài)代碼塊都會在編譯時被前端編譯器放在收集器里頭，存放到一個特殊的方法中，這個方法就是方法，即類/接口初始化方法。該方法的作用就是初始化一個類中的變量，使用用戶指定的值覆蓋之前在準(zhǔn)備階段設(shè)定的初始值。任何invoke之類的字節(jié)碼都無法調(diào)用方法，因為該方法只能在類加載的過程中由JVM調(diào)用。

如果超類還沒有被初始化，那么優(yōu)先對超類初始化，但在方法內(nèi)部不會顯示調(diào)用超類的方法，由JVM負(fù)責(zé)保證一個類的方法執(zhí)行之前，它的超類方法已經(jīng)被執(zhí)行。

JVM必須確保一個類在初始化的過程中，如果是多線程需要同時初始化它，僅僅只能允許其中一個線程對其執(zhí)行初始化操作，其余線程必須等待，只有在活動線程執(zhí)行完對類的初始化操作之后，才會通知正在等待的其他線程。

只有那些需要執(zhí)行java代碼來為類變量執(zhí)行賦值操作的類型在編譯之后才會在字節(jié)碼中存在生成的方法。如果一個類并沒有聲明任何的類變量，也沒有靜態(tài)代碼塊，那么這個類在編譯為字節(jié)碼后，字節(jié)碼文件中將不會包含方法；同樣如果一個類聲明類變量，但沒有明確使用類變量的初始化語句以及靜態(tài)代碼塊來執(zhí)行初始化操作，編譯后的字節(jié)碼中也不會有方法；只有final的靜態(tài)變量也不會有該方法。

（1）為一個類型創(chuàng)建一個新的對象實例時（比如new、反射、序列化）

（2）調(diào)用一個類型的靜態(tài)方法時（即在字節(jié)碼中執(zhí)行invokestatic指令）

（3）調(diào)用一個類型或接口的靜態(tài)字段，或者對這些靜態(tài)字段執(zhí)行賦值操作時（即在字節(jié)碼中，執(zhí)行g(shù)etstatic或者putstatic指令），不過用final修飾的靜態(tài)字段除外，它被初始化為一個編譯時常量表達(dá)式

（4）調(diào)用JavaAPI中的反射方法時（比如調(diào)用java.lang.Class中的方法，或者java.lang.reflect包中其他類的方法）

（5）初始化一個類的派生類時（Java虛擬機(jī)規(guī)范明確要求初始化一個類時，它的超類必須提前完成初始化操作，接口例外）

（6）JVM啟動包含main方法的啟動類時。

數(shù)組本身并不是由類加載器負(fù)責(zé)創(chuàng)建，而是由JVM在運行時根據(jù)需要而直接創(chuàng)建的，但數(shù)組的元素類型仍然需要依靠類加載器去創(chuàng)建。