一、概述

     虛擬機器把描述類的資料從class檔案載入到記憶體，並對資料進行校驗、轉換解析和初始化。最終形成可以被虛擬機器最直接使用的java型別的過程就是虛擬機器的類載入機制。

     與那些在編譯時需要進行連線工作的語言不同，在 java語言裡型別的載入、連線以及初始化過程都是在程式執行期間完成的，這種策略雖然會使類載入時稍微增加一些效能開銷，但是會為java應用程式提供高度的靈活性。java裡天生就可以動態擴充套件語言特性就是依賴執行期間動態載入和動態連線這個特點實現的。比如，如果編寫一個面向介面的程式，可以等到執行時再指定其具體實現類。

二、類載入的時機

    類從被載入到虛擬機器記憶體種開始，到卸載出記憶體為止，它的整個生命週期包括：載入、驗證、準備、解析、初始化、使用和解除安裝七個階段，其中驗證、準備、解析三個部分統稱為連線，如圖所示

      載入、驗證、準備、初始化和解除安裝這5個階段的順序是確定的，類的載入過程必須按照這種順序按部就班地開始，而解析階段則不一定：它在某些情況下可以在初始化階段之後再開始，這是為了支援Java語言的執行時繫結（也稱為動態繫結或晚期定）。

什麼時候需要開始類載入的第一個階段：載入？

1、使用new關鍵字例項化物件的時候、讀取或設定一個類的靜態欄位的時候，已經呼叫一個類的靜態方法的時候。

2、使用java.lang.reflect包的方法對類進行反射呼叫的時候，如果類沒有初始化，則需要先觸發其初始化。

3、當初始化一個類的時候，如果發現其父類沒有被初始化就會先初始化它的父類。

4、當虛擬機器啟動的時候，使用者需要指定一個要執行的主類（就是包含main()方法的那個類），虛擬機器會先初始化這個類。

5、使用Jdk1.7動態語言支援的時候的一些情況。

三、類載入過程

java虛擬機器中類載入的全過程：載入、驗證、準備、解析和初始化這5個階段鎖執行的具體工作。

1、載入

在載入階段虛擬機器需要完成一下三件事情：

（1) 通過型別的完全限定名，產生一個代表該型別的二進位制資料流（根本沒有指明從哪裡獲取、怎樣獲取，可以說一個非常開放的平臺了）

（2) 解析這個二進位制資料流為方法區內的執行時資料結構

（3) 建立一個表示該型別的java.lang.Class類的例項，作為方法區這個類的各種資料的訪問入口。
注： 非陣列類載入階段既可以使用系統提供的類載入器來完成，也可以由使用者自定義的類載入器去完成。（即重寫一個類載入器的loadClass（）方法）

2、驗證

    驗證是連線階段的第一步，這一階段的目的是為了確保Class檔案的位元組流中包含的資訊符合當前虛擬機器的要求，並且不會危害虛擬機器自身的安全。虛擬機器如果不檢查輸入的位元組流，並對其完全信任的話，很可能會因為載入了有害的位元組流而導致系統崩潰，所以驗證是虛擬機器對自身保護的一項重要工作。這個階段是否嚴謹，直接決定了java虛擬機器是否能承受惡意程式碼的攻擊。從整體上看，驗證階段大致上會完成4個階段的校驗工作：檔案格式、元資料、位元組碼、符號引用。

2.1、檔案格式驗證

       驗證位元組流是否符合Class檔案格式的規範，以及能否被當前版本的虛擬機器處理。目的是保證輸入的位元組流能正確地解析並存儲於方法區之內。這個階段驗證是基於二進位制位元組流進行的，只有通過這個階段的驗證後，位元組流才會進入記憶體的方法區進行儲存，所以後面的3個階段的全部是基於方法區的儲存結構進行的，不會再直接操作位元組流。

2.2、元資料驗證

      對位元組碼描述的資訊進行語義分析，保證其描述的資訊符合Java語言規範的要求，目的是保證不存在不符合Java語言規範的元資料資訊。

2.3、 位元組碼驗證

        進行資料流和控制流分析，保證被校驗類的方法在執行時不會做出危害虛擬機器安全的行為。 例如，保證跳轉指令不會跳轉到方法體以外的位元組碼指令上、保證方法體中的型別轉換是有效的等等。

2.4、 符號引用驗證

         校驗發生在虛擬機器將符號引用轉化為直接引用的時候，這個轉化動作將在連線的第三個階段——解析階段中發生。符號引用驗證的目的是確保解析動作能正常執行。

3、準備

         準備階段是正式為類變數分配記憶體並設定類變數初始值的階段，這些變數所使用的記憶體都將在方法區中進行分配。（注：這時候進行記憶體分配的僅包括類變數（被static修飾的變數），而不包括例項變數，例項變數將會在物件例項化時隨著物件一起分配在Java堆中）。

4 、解析

解析階段是虛擬機器將常量池內的符號引用替換為直接引用的過程。

符號引用： 符號引用以一組符號來描述所引用的目標，符號可以是符合約定的任何形式的字面量，符號引用與虛擬機器實現的記憶體佈局無關，引用的目標並不一定已經載入到記憶體中。

直接引用: 直接引用可以是直接指向目標的指標、相對偏移量或是一個能間接定位到目標的控制代碼。直接引用與虛擬機器實現的記憶體佈局相關，引用的目標必定已經在記憶體中存在。

虛擬機器規範沒有規定解析階段發生的具體時間，虛擬機器實現可以根據需要來判斷到底是在類被載入時解析還是等到一個符號引用將要被使用前才去解析。
 

5、初始化

      類初始化階段是類載入的最後一步，前面的類載入過程中，除了在載入階段使用者應用程式可以通過自定義類載入器參與之外，其餘動作完全由虛擬機器主導和控制。到了初始化階段，才真正開始執行類中定義的java程式程式碼（或者說是位元組碼）。

四、類載入器

1、類與類載入器

        對於任意一個類，都需要由載入它的類載入器和這個類本身一同確立其在Java虛擬機器中的唯一性。如果兩個類來源於同一個Class檔案，只要載入它們的類載入器不同，那麼這兩個類就必定不相等。

2、 類載入器介紹

從Java虛擬機器的角度分為兩種不同的類載入器：啟動類載入器（Bootstrap ClassLoader） 和其他類載入器。其中啟動類載入器，使用C++語言實現，是虛擬機器自身的一部分；其餘的類載入器都由Java語言實現，獨立於虛擬機器之外，並且全都繼承自java.lang.ClassLoader類。（這裡只限於HotSpot虛擬機器）。

絕大部分Java程式都會使用到以下3種系統提供的類載入器。

啟動類載入器（Bootstrap ClassLoader）：

這個類載入器負責將存放在\lib目錄中的，或者被-Xbootclasspath引數所指定的路徑中的，並且是虛擬機器識別的（僅按照檔名識別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會被載入）類庫載入到虛擬機器記憶體中。

擴充套件類載入器（Extension ClassLoader）：

這個載入器由sun.misc.Launcher$ExtClassLoader實現，它負責載入\lib\ext目錄中的，或者被java.ext.dirs系統變數所指定的路徑中的所有類庫，開發者可以直接使用擴充套件類載入器。

應用程式類載入器（Application ClassLoader）：

這個類載入器由sun.misc.Launcher$AppClassLoader實現。由於這個類載入器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也稱它為系統類載入器。它負責載入使用者類路徑（ClassPath）上所指定的類庫，開發者可以直接使用這個類載入器，如果應用程式中沒有自定義過自己的類載入器，一般情況下這個就是程式中預設的類載入器。

五、雙親委派模型

雙親委派模型（Pattern Delegation Model）,要求除了頂層的啟動類載入器外，其餘的類載入器都應該有自己的父類載入器。這裡父子關係通常是子類通過組合關係而不是繼承關係來複用父類載入器的程式碼。

雙親委派模型的工作過程： 如果一個類載入器收到了類載入的請求，先把這個請求委派給父類載入器去完成（所以所有的載入請求最終都應該傳送到頂層的啟動類載入器中），只有當父載入器反饋自己無法完成載入請求時，子載入器才會嘗試自己去載入。

好處：就是java類隨著它的類載入器一起具備了一種帶有優先順序的層次關係。

雙親委派模型對於保證Java程式的穩定運作很重要，但他的實現卻非常簡單，實現雙親委派的程式碼都集中在java.lang.ClassLoader的loadClass()方法之種。

六、破壞雙親委派模型

雙親委派模型主要出現過3次較大規模“被破壞”的情況。

第一次破壞是因為類載入器和抽象類java.lang.ClassLoader在JDK1.0就存在的，而雙親委派模型在JDK1.2之後才被引入，為了相容已經存在的使用者自定義類載入器，引入雙親委派模型時做了一定的妥協：在java.lang.ClassLoader中引入了一個findClass()方法，在此之前，使用者去繼承java.lang.Classloader的唯一目的就是重寫loadClass()方法。JDK1.2之後不提倡使用者去覆蓋loadClass()方法，而是把自己的類載入邏輯寫到findClass()方法中，如果loadClass()方法中如果父類載入失敗，則會呼叫自己的findClass()方法來完成載入，這樣就可以保證新寫出來的類載入器是符合雙親委派模型規則的。

第二次破壞是因為模型自身的缺陷，現實中存在這樣的場景：基礎的類載入器需要求呼叫使用者的程式碼，而基礎的類載入器可能不認識使用者的程式碼。為此，Java設計團隊引入的設計時“執行緒上下文類載入器（Thread Context ClassLoader）”。這樣可以通過父類載入器請求子類載入器去完成類載入動作。已經違背了雙親委派模型的一般性原則。

第三次破壞是由於使用者對程式動態性的追求導致的。這裡所說的動態性是指：“程式碼熱替換”、“模組熱部署”等等比較熱門的詞。說白了就是希望應用程式能夠像我們的計算機外設一樣，接上滑鼠、U盤不用重啟機器就能立即使用。OSGi是當前業界“事實上”的Java模組化標準，OSGi實現模組化熱部署的關鍵是它自定義的類載入器機制的實現。每一個程式模組（OSGi中稱為Bundle）都有一個自己的類載入器，當需要更換一個Bundle時，就把Bundle連同類載入器一起換掉以實現程式碼的熱替換。在OSGi環境下，類載入器不再是雙親委派模型中的樹狀結構，而是進一步發展為更加複雜的網狀結構。