類加載機制

概述

類從被加載到虛擬機內存中開始，到卸載出內存為止，它的整個生命周期包括：加載（Loading）、驗證（Verification）、準備（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸載（Unloading）7個階段。其中驗證、準備、解析3個部分統稱為連接（Linking）

於初始化階段，虛擬機規範則是嚴格規定了有且只有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的方法句柄，並且這個方法句柄所對應的類沒有進行過初始化，則需要先觸發其初始化。

註意：

對於靜態字段，只有直接定義這個字段的類才會被初始化，因此通過其子類來引用父類中定義的靜態字段，只會觸發父類的初始化而不會觸發子類的初始化。

常量HELLOWORLD，但其實在編譯階段通過常量傳播優化，已經將此常量的值“hello world”存儲到了NotInitialization類的常量池中，以後NotInitialization對常量ConstClass.HELLOWORLD的引用實際都被轉化為NotInitialization類對自身常量池的引用了。

也就是說，實際上NotInitialization的Class文件之中並沒有ConstClass類的符號引用入口，這兩個類在編譯成Class之後就不存在任何聯系了。

加載階段

虛擬機需要完成以下3件事情：

1）通過一個類的全限定名來獲取定義此類的二進制字節流。

2）將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

3）在內存中生成一個代表這個類的java.lang.Class對象，作為方法區這個類的各種數據的訪問入口。

驗證

是連接階段的第一步，這一階段的目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，並且不會危害虛擬機自身的安全。但從整體上看，驗證階段大致上會完成下面4個階段的檢驗動作：文件格式驗證、元數據驗證、字節碼驗證、符號引用驗證。

準備階段

是正式為類變量分配內存並設置類變量初始值的階段，這些變量所使用的內存都將在方法區中進行分配。這個階段中有兩個容易產生混淆的概念需要強調一下，首先，這時候進行內存分配的僅包括類變量（被static修飾的變量），而不包括實例變量，實例變量將會在對象實例化時隨著對象一起分配在Java堆中。其次，這裏所說的初始值“通常情況”下是數據類型的零值，假設一個類變量的定義為：

public static int value=123；

那變量value在準備階段過後的初始值為0而不是123，因為這時候尚未開始執行任何Java方法，而把value賦值為123的putstatic指令是程序被編譯後，存放於類構造器＜clinit＞（）方法之中，所以把value賦值為123的動作將在初始化階段才會執行。表7-1列出了Java中所有基本數據類型的零值。

假設上面類變量value的定義變為：public static final int value=123；

編譯時Javac將會為value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設置將value賦值為123。

解析階段

是虛擬機將常量池內的符號引用替換為直接引用的過程

類初始化階段

是類加載過程的最後一步，前面的類加載過程中，除了在加載階段用戶應用程序可以通過自定義類加載器參與之外，其余動作完全由虛擬機主導和控制。到了初始化階段，才真正開始執行類中定義的Java程序代碼在準備階段，變量已經賦過一次系統要求的初始值，而在初始化階段，則根據程序員通過程序制定的主觀計劃去初始化類變量和其他資源，或者可以從另外一個角度來表達：初始化階段是執行類構造器＜clinit＞（）方法的過程。＜clinit＞（）方法是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊（static{}塊）中的語句合並產生的，編譯器收集的順序是由語句在源文件中出現的順序所決定的。

＜clinit＞（）方法對於類或接口來說並不是必需的，如果一個類中沒有靜態語句塊，也沒有對變量的賦值操作，那麽編譯器可以不為這個類生成＜clinit＞（）方法。

虛擬機會保證一個類的＜clinit＞（）方法在多線程環境中被正確地加鎖、同步，如果多個線程同時去初始化一個類，那麽只會有一個線程去執行這個類的＜clinit＞（）方法，其他線程都需要阻塞等待，直到活動線程執行＜clinit＞（）方法完畢。如果在一個類的＜clinit＞（）方法中有耗時很長的操作，就可能造成多個進程阻塞。

類加載器

如何自定義類加載器，看代碼

系統的類加載器

對於任意一個類，都需要由加載它的類加載器和這個類本身一同確立其在Java虛擬機中的唯一性，每一個類加載器，都擁有一個獨立的類名稱空間。這句話可以表達得更通俗一些：比較兩個類是否“相等”，只有在這兩個類是由同一個類加載器加載的前提下才有意義，否則，即使這兩個類來源於同一個Class文件，被同一個虛擬機加載，只要加載它們的類加載器不同，那這兩個類就必定不相等。

這裏所指的“相等”，包括代表類的Class對象的equals（）方法、isAssignableFrom（）方法、isInstance（）方法的返回結果，也包括使用instanceof關鍵字做對象所屬關系判定等情況。

在自定義ClassLoader的子類時候，我們常見的會有兩種做法，一種是重寫loadClass方法，另一種是重寫findClass方法。其實這兩種方法本質上差不多，畢竟loadClass也會調用findClass，但是從邏輯上講我們最好不要直接修改loadClass的內部邏輯。我建議的做法是只在findClass裏重寫自定義類的加載方法。
loadClass這個方法是實現雙親委托模型邏輯的地方，擅自修改這個方法會導致模型被破壞，容易造成問題。因此我們最好是在雙親委托模型框架內進行小範圍的改動，不破壞原有的穩定結構。同時，也避免了自己重寫loadClass方法的過程中必須寫雙親委托的重復代碼，從代碼的復用性來看，不直接修改這個方法始終是比較好的選擇。

雙親委派模型

從Java虛擬機的角度來講，只存在兩種不同的類加載器：一種是啟動類加載器（Bootstrap ClassLoader），這個類加載器使用C++語言實現，是虛擬機自身的一部分；另一種就是所有其他的類加載器，這些類加載器都由Java語言實現，獨立於虛擬機外部，並且全都繼承自抽象類java.lang.ClassLoader。

啟動類加載器（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）：這個類加載器由sun.misc.Launcher $App-ClassLoader實現。由於這個類加載器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也稱它為系統類加載器。它負責加載用戶類路徑（ClassPath）上所指定的類庫，開發者可以直接使用這個類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。

我們的應用程序都是由這3種類加載器互相配合進行加載的，如果有必要，還可以加入自己定義的類加載器。

雙親委派模型要求除了頂層的啟動類加載器外，其余的類加載器都應當有自己的父類加載器。這裏類加載器之間的父子關系一般不會以繼承（Inheritance）的關系來實現，而是都使用組合（Composition）關系來復用父加載器的代碼。

使用雙親委派模型來組織類加載器之間的關系，有一個顯而易見的好處就是Java類隨著它的類加載器一起具備了一種帶有優先級的層次關系。例如類java.lang.Object，它存放在rt.jar之中，無論哪一個類加載器要加載這個類，最終都是委派給處於模型最頂端的啟動類加載器進行加載，因此Object類在程序的各種類加載器環境中都是同一個類。相反，如果沒有使用雙親委派模型，由各個類加載器自行去加載的話，如果用戶自己編寫了一個稱為java.lang.Object的類，並放在程序的ClassPath中，那系統中將會出現多個不同的Object類，Java類型體系中最基礎的行為也就無法保證，應用程序也將會變得一片混亂。

棧楨

棧楨詳解

方法調用詳解

解析

調用目標在程序代碼寫好、編譯器進行編譯時就必須確定下來。這類方法的調用稱為解析。

在Java語言中符合“編譯期可知，運行期不可變”這個要求的方法，主要包括靜態方法和私有方法兩大類，前者與類型直接關聯，後者在外部不可被訪問，這兩種方法各自的特點決定了它們都不可能通過繼承或別的方式重寫其他版本，因此它們都適合在類加載階段進行解析。

靜態分派

多見於方法的重載。

“Human”稱為變量的靜態類型（Static Type），或者叫做的外觀類型（Apparent Type），後面的“Man”則稱為變量的實際類型（Actual Type），靜態類型和實際類型在程序中都可以發生一些變化，區別是靜態類型的變化僅僅在使用時發生，變量本身的靜態類型不會被改變，並且最終的靜態類型是在編譯期可知的；而實際類型變化的結果在運行期才可確定，編譯器在編譯程序的時候並不知道一個對象的實際類型是什麽。

代碼中定義了兩個靜態類型相同但實際類型不同的變量，但虛擬機（準確地說是編譯器）在重載時是通過參數的靜態類型而不是實際類型作為判定依據的。並且靜態類型是編譯期可知的，因此，在編譯階段，Javac編譯器會根據參數的靜態類型決定使用哪個重載版本，所以選擇了sayHello（Human）作為調用目標。所有依賴靜態類型來定位方法執行版本的分派動作稱為靜態分派。靜態分派的典型應用是方法重載。靜態分派發生在編譯階段，因此確定靜態分派的動作實際上不是由虛擬機來執行的。

動態分派

靜態類型同樣都是Human的兩個變量man和woman在調用sayHello（）方法時執行了不同的行為，並且變量man在兩次調用中執行了不同的方法。導致這個現象的原因很明顯，是這兩個變量的實際類型不同。

在實現上，最常用的手段就是為類在方法區中建立一個虛方法表。虛方法表中存放著各個方法的實際入口地址。如果某個方法在子類中沒有被重寫，那子類的虛方法表裏面的地址入口和父類相同方法的地址入口是一致的，都指向父類的實現入口。如果子類中重寫了這個方法，子類方法表中的地址將會替換為指向子類實現版本的入口地址。

Son重寫了來自Father的全部方法，因此Son的方法表沒有指向Father類型數據的箭頭。但是Son和Father都沒有重寫來自Object的方法，所以它們的方法表中所有從Object繼承來的方法都指向了Object的數據類型。

基於棧的字節碼解釋執行引擎

Java編譯器輸出的指令流，基本上]是一種基於棧的指令集架構，指令流中的指令大部分都是零地址指令，它們依賴操作數棧進行工作。與

基於寄存器的指令集，最典型的就是x86的二地址指令集，說得通俗一些，就是現在我們主流PC機中直接支持的指令集架構，這些指令依賴寄存器進行工作。

舉個最簡單的例子，分別使用這兩種指令集計算“1+1”的結果，基於棧的指令集會是這樣子的：

iconst_1

iconst_1

iadd

istore_0

兩條iconst_1指令連續把兩個常量1壓入棧後，iadd指令把棧頂的兩個值出棧、相加，然後把結果放回棧頂，最後istore_0把棧頂的值放到局部變量表的第0個Slot中。

如果基於寄存器，那程序可能會是這個樣子：

mov eax，1

add eax，1

mov指令把EAX寄存器的值設為1，然後add指令再把這個值加1，結果就保存在EAX寄存器裏面。

基於棧的指令集主要的優點就是可移植，寄存器由硬件直接提供，程序直接依賴這些硬件寄存器則不可避免地要受到硬件的約束。棧架構指令集的主要缺點是執行速度相對來說會稍慢一些。所有主流物理機的指令集都是寄存器架構也從側面印證了這一點。

java類加載機制及方法調用