一、什麼是類加載機制？
虛拟機把描述類的資料從Class檔案加載到記憶體，并對資料進行校驗、轉換解析和初始化，最終形成可以被虛拟機直接使用的Java類型，這就是虛拟機的類加載機制。
二、類加載的時機
類從被加載到虛拟機記憶體中開始，到解除安裝出記憶體為止，它的整個生命周期包括：加載（Loading）、驗證（Verification）、準（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和解除安裝（Unloading）7個階段。其中驗證、準備、解析3個部分統稱為連接配接（Linking），這7個階段的發生順序如圖：
加載、驗證、準備、初始化和解除安裝這5個階段的順序是确定的，類的加載過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以在初始化階段之後再開始，這是為了支援Java語言的運作時綁定（也稱為動态綁定或晚期綁定）。
什麼情況下需要開始類加載過程的第一個階段：加載？Java虛拟機規範中并沒有進行強制限制，這點可以交給虛拟機的具體實作來自由把握。但是對于初始化階段，虛拟機規範則是嚴格規定了有且隻有5種情況必須立即對類進行“初始化”（而加載、驗證、準備自然需要在此之前開始）：
1）遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需要先觸發其初始化。生成這4條指令的最常見的Java代碼場景是：使用new關鍵字執行個體化對象的時候、讀取或設定一個類的靜态字段（被final修飾、已在編譯期把結果放入常量池的靜态字段除外）的時候，以及調用一個類的靜态方法的時候。
2）使用java.lang.reflect包的方法對類進行反射調用的時候，如果類沒有進行過初始化，則需要先觸發其初始化。
3）當初始化一個類的時候，如果發現其父類還沒有進行過初始化，則需要先觸發其父類的初始化。
4）當虛拟機啟動時，使用者需要指定一個要執行的主類（包含main（）方法的那個類），虛拟機會先初始化這個主類。
5）當使用JDK 1.7的動态語言支援時，如果一個java.lang.invoke.MethodHandle執行個體最後的解析結果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且這個方法句柄所對應的類沒有進行過初始化，則需要先觸發其初始化。
三、類加載過程
1、加載
“加載”是“類加載”（Class Loading）過程的一個階段。在加載階段，虛拟機需要完成以下3件事情：
1）通過一個類的全限定名來擷取定義此類的二進制位元組流。
2）将這個位元組流所代表的靜态存儲結構轉化為方法區的運作時資料結構。
3）在記憶體中生成一個代表這個類的java.lang.Class對象，作為方法區這個類的各種資料的通路入口。
相對于類加載過程的其他階段，一個非數組類的加載階段（準确地說，是加載階段中擷取類的二進制位元組流的動作）是開發人員可控性最強的，因為加載階段既可以使用系統提供的引導類加載器來完成，也可以由使用者自定義的類加載器去完成，開發人員可以通過定義自己的類加載器去控制位元組流的擷取方式（即重寫一個類加載器的loadClass（）方法）。
加載階段完成後，虛拟機外部的二進制位元組流就按照虛拟機所需的格式存儲在方法區之中，方法區中的資料存儲格式由虛拟機實作自行定義，虛拟機規範未規定此區域的具體資料結構。然後在記憶體中執行個體化一個java.lang.Class類的對象（并沒有明确規定是在Java堆中，對于HotSpot虛拟機而言，Class對象比較特殊，它雖然是對象，但是存放在方法區裡面），這個對象将作為程式通路方法區中的這些類型資料的外部接口。
2、驗證
驗證是連結階段的第一步，這一步主要的目的是確定class檔案的位元組流中包含的資訊符合目前虛拟機的要求，并且不會危害虛拟機自身安全。
驗證階段主要包括四個檢驗過程：檔案格式驗證、中繼資料驗證、位元組碼驗證和符号引用驗證。
1.檔案格式驗證
驗證class檔案格式規範，例如： class檔案是否已魔術0xCAFEBABE開頭 ， 主、次版本号是否在目前虛拟機處理範圍之内等
2.中繼資料驗證
這個階段是對位元組碼描述的資訊進行語義分析，以保證起描述的資訊符合java語言規範要求。驗證點可能包括：這個類是否有父類(除了java.lang.Object之外，所有的類都應當有父類)、這個類是否繼承了不允許被繼承的類(被final修飾的)、如果這個類的父類是抽象類，是否實作了起父類或接口中要求實作的所有方法。
3.位元組碼驗證
進行資料流和控制流分析，這個階段對類的方法體進行校驗分析，這個階段的任務是保證被校驗類的方法在運作時不會做出危害虛拟機安全的行為。如：保證訪法體中的類型轉換有效，例如可以把一個子類對象指派給父類資料類型，這是安全的，但不能把一個父類對象指派給子類資料類型、保證跳轉指令不會跳轉到方法體以外的位元組碼指令上。
4.符号引用驗證
3、準備
準備階段是正式為類變量配置設定記憶體并設定類變量初始值的階段，這些記憶體都将在方法區中進行配置設定。這個階段中有兩個容易産生混淆的知識點，首先是這時候進行記憶體配置設定的僅包括類變量(static 修飾的變量),而不包括執行個體變量，執行個體變量将會在對象執行個體化時随着對象一起配置設定在java堆中。其次是這裡所說的初始值“通常情況”下是資料類型的零值，假設一個類變量定義為:
public static int value = 12;
那麼變量value在準備階段過後的初始值為0而不是12，因為這時候尚未開始執行任何java方法，而把value指派為123的putstatic指令是程式被編譯後，存放于類構造器()方法之中，是以把value指派為12的動作将在初始化階段才會被執行。
上面所說的“通常情況”下初始值是零值，那相對于一些特殊的情況，如果類字段的字段屬性表中存在ConstantValue屬性，那在準備階段變量value就會被初始化為ConstantValue屬性所指定的值，建設上面類變量value定義為：
public static final int value = 123;
編譯時javac将會為value生成ConstantValue屬性，在準備階段虛拟機就會根據ConstantValue的設定将value設定為123。
4、解析
解析階段是虛拟機常量池内的符号引用替換為直接引用的過程。
符号引用：符号引用是一組符号來描述所引用的目标對象，符号可以是任何形式的字面量，隻要使用時能無歧義地定位到目标即可。符号引用與虛拟機實作的記憶體布局無關，引用的目标對象并不一定已經加載到記憶體中。
直接引用：直接引用可以是直接指向目标對象的指針、相對偏移量或是一個能間接定位到目标的句柄。直接引用是與虛拟機記憶體布局實作相關的，同一個符号引用在不同虛拟機執行個體上翻譯出來的直接引用一般不會相同，如果有了直接引用，那引用的目标必定已經在記憶體中存在。
虛拟機規範并沒有規定解析階段發生的具體時間，隻要求了在執行anewarry、checkcast、getfield、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic這13個用于操作符号引用的位元組碼指令之前，先對它們使用的符号引用進行解析，是以虛拟機實作會根據需要來判斷，到底是在類被加載器加載時就對常量池中的符号引用進行解析，還是等到一個符号引用将要被使用前才去解析它。
解析的動作主要針對類或接口、字段、類方法、接口方法四類符号引用進行。分别對應編譯後常量池内的CONSTANT_Class_Info、CONSTANT_Fieldref_Info、CONSTANT_Methodef_Info、CONSTANT_InterfaceMethoder_Info四種常量類型。
1.類、接口的解析
2.字段解析
3.類方法解析
4.接口方法解析
5、初始化
類的初始化階段是類加載過程的最後一步，在準備階段，類變量已賦過一次系統要求的初始值，而在初始化階段，則是根據程式員通過程式制定的主觀計劃去初始化類變量和其他資源，或者可以從另外一個角度來表達：初始化階段是執行類構造器< clinit >()方法的過程。在以下四種情況下初始化過程會被觸發執行：
1.遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有進行過初始化，則需先觸發其初始化。生成這4條指令的最常見的java代碼場景是：使用new關鍵字執行個體化對象、讀取或設定一個類的靜态字段(被final修飾、已在編譯器把結果放入常量池的靜态字段除外)的時候，以及調用類的靜态方法的時候。
2.使用java.lang.reflect包的方法對類進行反射調用的時候
3.當初始化一個類的時候，如果發現其父類還沒有進行過初始化、則需要先出發其父類的初始化
4.jvm啟動時，使用者指定一個執行的主類(包含main方法的那個類)，虛拟機會先初始化這個類
在上面準備階段 public static int value = 12; 在準備階段完成後 value的值為0，而在初始化階調用了類構造器< clinit >()方法，這個階段完成後value的值為12。
*類構造器< clinit >()方法是由編譯器自動收集類中的所有類變量的指派動作和靜态語句塊(static塊)中的語句合并産生的，編譯器收集的順序是由語句在源檔案中出現的順序所決定的，靜态語句塊中隻能通路到定義在靜态語句塊之前的變量，定義在它之後的變量，在前面的靜态語句快可以指派，但是不能通路。
*類構造器< clinit >()方法與類的構造函數(執行個體構造函數< init >()方法)不同，它不需要顯式調用父類構造，虛拟機會保證在子類< clinit >()方法執行之前，父類的< clinit >()方法已經執行完畢。是以在虛拟機中的第一個執行的< clinit >()方法的類肯定是java.lang.Object。
*由于父類的< clinit >()方法先執行，也就意味着父類中定義的靜态語句快要優先于子類的變量指派操作。
*< clinit >()方法對于類或接口來說并不是必須的，如果一個類中沒有靜态語句，也沒有變量指派的操作，那麼編譯器可以不為這個類生成< clinit >()方法。
*接口中不能使用靜态語句塊，但接口與類不太能夠的是，執行接口的< clinit >()方法不需要先執行父接口的< clinit >()方法。隻有當父接口中定義的變量被使用時，父接口才會被初始化。另外，接口的實作類在初始化時也一樣不會執行接口的< clinit >()方法。
*虛拟機會保證一個類的< clinit >()方法在多線程環境中被正确加鎖和同步，如果多個線程同時去初始化一個類，那麼隻會有一個線程執行這個類的< clinit >()方法，其他線程都需要阻塞等待，直到活動線程執行< clinit >()方法完畢。如果一個類的< clinit >()方法中有耗時很長的操作，那就可能造成多個程序阻塞。
四、雙親委派模型
類加載器分類
在虛拟機的角度上，隻存在兩種不同的類加載器：
啟動類加載器(Bootstrap ClassLoader)，這個類加載器使用C++語言實作，是虛拟機自身的一部分；
其它所有的類加載器，這些類加載器都由Java語言實作，獨立于虛拟機外部，并且全部繼承自java.lang.ClassLoader
從Java開發人員的角度看，類加載器還可以劃分得更細一些，如下：
啟動類加載器(Bootstrap ClassLoader)
這個類加載器負責将放置在<JAVA_HOME>\lib目錄中的，或者被-Xbootclasspath參數所指定路徑中的，并且是虛拟機能識别的(僅按照檔案名識别，如rt.jar，名字不符合的類庫即使放置在lib目錄中也不會被加載)類庫加載到虛拟機記憶體中。啟動類加載器無法被Java程式直接使用。程式員在編寫自定義類加載器時，如果需要把加載請求委派給引導類加載器，直接使用null代替即可。
擴充類加載器(Extension ClassLoader)
這個類加載器由sun.misc.Launcher$ExtClassLoader實作，它負責加載<JAVA_HOME>\lib\ext目錄中的，或者被java.ext.dirs系統變量所指定的路徑中的所有類庫，開發者可以直接使用擴充類加載器。
應用程式類加載器(Application ClassLoader)
這個類加載器由sum.misc.Launcher.$AppClassLoader來實作。由于這個類加載器是ClassLoader中的getSystemClassLoader()方法的傳回值，是以一般也被稱為系統類加載器。它負責加載使用者類路徑（ClassPath）上所指定的類庫，開發者可以直接使用這個類加載器，如果應用程式中沒有自定義過自己的類加載器，一般情況下這個就是程式中預設的類加載器。
如上圖所示的類加載器之間的這種層次關系，就稱為類加載器的雙親委派模型（Parent Delegation Model）。該模型要求除了頂層的啟動類加載器外，其餘的類加載器都應當有自己的父類加載器。子類加載器和父類加載器不是以繼承（Inheritance）的關系來實作，而是通過組合（Composition）關系來複用父加載器的代碼。
雙親委派模型的工作過程為：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把這個請求委派給父類加載器去完成，每一個層次的加載器都是如此，是以所有的類加載請求都會傳給頂層的啟動類加載器，隻有當父加載器回報自己無法完成該加載請求（該加載器的搜尋範圍中沒有找到對應的類）時，子加載器才會嘗試自己去加載。
使用這種模型來組織類加載器之間的關系的好處是Java類随着它的類加載器一起具備了一種帶有優先級的層次關系。例如java.lang.Object類，無論哪個類加載器去加載該類，最終都是由啟動類加載器進行加載，是以Object類在程式的各種類加載器環境中都是同一個類。否則的話，如果不使用該模型的話，如果使用者自定義一個java.lang.Object類且存放在classpath中，那麼系統中将會出現多個Object類，應用程式也會變得很混亂。如果我們自定義一個rt.jar中已有類的同名Java類，會發現JVM可以正常編譯，但該類永遠無法被加載運作。