轉：http://blog.csdn.net/ns_code/article/details/17881581
類加載過程
類從被加載到虛擬機內存中開始，到卸載出內存爲止，它的整個生命週期包括：加載、驗證、準備、解析、初始化、使用和卸載七個階段。它們開始的順序如下圖所示：
其中類加載的過程包括了加載、驗證、準備、解析、初始化五個階段。在這五個階段中，加載、驗證、準備和初始化這四個階段發生的順序是確定的，而解析階段則不一定，它在某些情況下可以在初始化階段之後開始，這是爲了支持Java語言的運行時綁定（也成爲動態綁定或晚期綁定）。另外注意這裏的幾個階段是按順序開始，而不是按順序進行或完成，因爲這些階段通常都是互相交叉地混合進行的，通常在一個階段執行的過程中調用或激活另一個階段。
這裏簡要說明下Java中的綁定：綁定指的是把一個方法的調用與方法所在的類(方法主體)關聯起來，對java來說，綁定分爲靜態綁定和動態綁定：
靜態綁定：即前期綁定。在程序執行前方法已經被綁定，此時由編譯器或其它連接程序實現。針對java，簡單的可以理解爲程序編譯期的綁定。java當中的方法只有final，static，private和構造方法是前期綁定的。
動態綁定：即晚期綁定，也叫運行時綁定。在運行時根據具體對象的類型進行綁定。在java中，幾乎所有的方法都是後期綁定的。
下面詳細講述類加載過程中每個階段所做的工作。
加載
加載時類加載過程的第一個階段，在加載階段，虛擬機需要完成以下三件事情：
1、通過一個類的全限定名來獲取其定義的二進制字節流。
2、將這個字節流所代表的靜態存儲結構轉化爲方法區的運行時數據結構。
3、在Java堆中生成一個代表這個類的java.lang.Class對象，作爲對方法區中這些數據的訪問入口。
注意，這裏第1條中的二進制字節流並不只是單純地從Class文件中獲取，比如它還可以從Jar包中獲取、從網絡中獲取（最典型的應用便是Applet）、由其他文件生成（JSP應用）等。
相對於類加載的其他階段而言，加載階段（準確地說，是加載階段獲取類的二進制字節流的動作）是可控性最強的階段，因爲開發人員既可以使用系統提供的類加載器來完成加載，也可以自定義自己的類加載器來完成加載。
加載階段完成後，虛擬機外部的 二進制字節流就按照虛擬機所需的格式存儲在方法區之中，而且在Java堆中也創建一個java.lang.Class類的對象，這樣便可以通過該對象訪問方法區中的這些數據。
說到加載，不得不提到類加載器，下面就具體講述下類加載器。
類加載器雖然只用於實現類的加載動作，但它在Java程序中起到的作用卻遠遠不限於類的加載階段。對於任意一個類，都需要由它的類加載器和這個類本身一同確定其在就Java虛擬機中的唯一性，也就是說，即使兩個類來源於同一個Class文件，只要加載它們的類加載器不同，那這兩個類就必定不相等。這裏的“相等”包括了代表類的Class對象的equals（）、isAssignableFrom（）、isInstance（）等方法的返回結果，也包括了使用instanceof關鍵字對對象所屬關係的判定結果。
站在Java虛擬機的角度來講，只存在兩種不同的類加載器：
啓動類加載器：它使用C++實現（這裏僅限於Hotspot，也就是JDK1.5之後默認的虛擬機，有很多其他的虛擬機是用Java語言實現的），是虛擬機自身的一部分。
所有其他的類加載器：這些類加載器都由Java語言實現，獨立於虛擬機之外，並且全部繼承自抽象類java.lang.ClassLoader，這些類加載器需要由啓動類加載器加載到內存中之後才能去加載其他的類。
站在Java開發人員的角度來看，類加載器可以大致劃分爲以下三類：
啓動類加載器：Bootstrap ClassLoader，跟上面相同。它負責加載存放在JDK\jre\lib(JDK代表JDK的安裝目錄，下同)下，或被-Xbootclasspath參數指定的路徑中的，並且能被虛擬機識別的類庫（如rt.jar，所有的java.*開頭的類均被Bootstrap ClassLoader加載）。啓動類加載器是無法被Java程序直接引用的。
擴展類加載器：Extension ClassLoader，該加載器由sun.misc.Launcher$ExtClassLoader實現，它負責加載JDK\jre\lib\ext目錄中，或者由java.ext.dirs系統變量指定的路徑中的所有類庫（如javax.*開頭的類），開發者可以直接使用擴展類加載器。
應用程序類加載器：Application ClassLoader，該類加載器由sun.misc.Launcher$AppClassLoader來實現，它負責加載用戶類路徑（ClassPath）所指定的類，開發者可以直接使用該類加載器，如果應用程序中沒有自定義過自己的類加載器，一般情況下這個就是程序中默認的類加載器。
應用程序都是由這三種類加載器互相配合進行加載的，如果有必要，我們還可以加入自定義的類加載器。因爲JVM自帶的ClassLoader只是懂得從本地文件系統加載標準的java class文件，因此如果編寫了自己的ClassLoader，便可以做到如下幾點：
1）在執行非置信代碼之前，自動驗證數字簽名。
2）動態地創建符合用戶特定需要的定製化構建類。
3）從特定的場所取得java class，例如數據庫中和網絡中。
事實上當使用Applet的時候，就用到了特定的ClassLoader，因爲這時需要從網絡上加載java class，並且要檢查相關的安全信息，應用服務器也大都使用了自定義的ClassLoader技術。
這幾種類加載器的層次關係如下圖所示：
這種層次關係稱爲類加載器的雙親委派模型。我們把每一層上面的類加載器叫做當前層類加載器的父加載器，當然，它們之間的父子關係並不是通過繼承關係來實現的，而是使用組合關係來複用父加載器中的代碼。該模型在JDK1.2期間被引入並廣泛應用於之後幾乎所有的Java程序中，但它並不是一個強制性的約束模型，而是Java設計者們推薦給開發者的一種類的加載器實現方式。
雙親委派模型的工作流程是：如果一個類加載器收到了類加載的請求，它首先不會自己去嘗試加載這個類，而是把請求委託給父加載器去完成，依次向上，因此，所有的類加載請求最終都應該被傳遞到頂層的啓動類加載器中，只有當父加載器在它的搜索範圍中沒有找到所需的類時，即無法完成該加載，子加載器纔會嘗試自己去加載該類。
使用雙親委派模型來組織類加載器之間的關係，有一個很明顯的好處，就是Java類隨着它的類加載器（說白了，就是它所在的目錄）一起具備了一種帶有優先級的層次關係，這對於保證Java程序的穩定運作很重要。例如，類java.lang.Object類存放在JDK\jre\lib下的rt.jar之中，因此無論是哪個類加載器要加載此類，最終都會委派給啓動類加載器進行加載，這邊保證了Object類在程序中的各種類加載器中都是同一個類。
驗證
驗證的目的是爲了確保Class文件中的字節流包含的信息符合當前虛擬機的要求，而且不會危害虛擬機自身的安全。不同的虛擬機對類驗證的實現可能會有所不同，但大致都會完成以下四個階段的驗證：文件格式的驗證、元數據的驗證、字節碼驗證和符號引用驗證。
文件格式的驗證：驗證字節流是否符合Class文件格式的規範，並且能被當前版本的虛擬機處理，該驗證的主要目的是保證輸入的字節流能正確地解析並存儲於方法區之內。經過該階段的驗證後，字節流纔會進入內存的方法區中進行存儲，後面的三個驗證都是基於方法區的存儲結構進行的。
元數據驗證：對類的元數據信息進行語義校驗（其實就是對類中的各數據類型進行語法校驗），保證不存在不符合Java語法規範的元數據信息。
字節碼驗證：該階段驗證的主要工作是進行數據流和控制流分析，對類的方法體進行校驗分析，以保證被校驗的類的方法在運行時不會做出危害虛擬機安全的行爲。
符號引用驗證：這是最後一個階段的驗證，它發生在虛擬機將符號引用轉化爲直接引用的時候（解析階段中發生該轉化，後面會有講解），主要是對類自身以外的信息（常量池中的各種符號引用）進行匹配性的校驗。
準備
準備階段是正式爲類變量分配內存並設置類變量初始值的階段，這些內存都將在方法區中分配。對於該階段有以下幾點需要注意：
1、這時候進行內存分配的僅包括類變量（static），而不包括實例變量，實例變量會在對象實例化時隨着對象一塊分配在Java堆中。
2、這裏所設置的初始值通常情況下是數據類型默認的零值（如0、0L、null、false等），而不是被在Java代碼中被顯式地賦予的值。
假設一個類變量的定義爲：
public static int value = 3；
那麼變量value在準備階段過後的初始值爲0，而不是3，因爲這時候尚未開始執行任何Java方法，而把value賦值爲3的putstatic指令是在程序編譯後，存放於類構造器<clinit>（）方法之中的，所以把value賦值爲3的動作將在初始化階段纔會執行。
下表列出了Java中所有基本數據類型以及reference類型的默認零值：
這裏還需要注意如下幾點：
對基本數據類型來說，對於類變量（static）和全局變量，如果不顯式地對其賦值而直接使用，則系統會爲其賦予默認的零值，而對於局部變量來說，在使用前必須顯式地爲其賦值，否則編譯時不通過。
對於同時被static和final修飾的常量，必須在聲明的時候就爲其顯式地賦值，否則編譯時不通過；而只被final修飾的常量則既可以在聲明時顯式地爲其賦值，也可以在類初始化時顯式地爲其賦值，總之，在使用前必須爲其顯式地賦值，系統不會爲其賦予默認零值。
對於引用數據類型reference來說，如數組引用、對象引用等，如果沒有對其進行顯式地賦值而直接使用，系統都會爲其賦予默認的零值，即null。
如果在數組初始化時沒有對數組中的各元素賦值，那麼其中的元素將根據對應的數據類型而被賦予默認的零值。
3、如果類字段的字段屬性表中存在ConstantValue屬性，即同時被final和static修飾，那麼在準備階段變量value就會被初始化爲ConstValue屬性所指定的值。
假設上面的類變量value被定義爲：
public static final int value = 3；
編譯時Javac將會爲value生成ConstantValue屬性，在準備階段虛擬機就會根據ConstantValue的設置將value賦值爲3。回憶上一篇博文中對象被動引用的第2個例子，便是這種情況。我們可以理解爲static final常量在編譯期就將其結果放入了調用它的類的常量池中。
解析
解析階段是虛擬機將常量池中的符號引用轉化爲直接引用的過程。在Class類文件結構一文中已經比較過了符號引用和直接引用的區別和關聯，這裏不再贅述。前面說解析階段可能開始於初始化之前，也可能在初始化之後開始，虛擬機會根據需要來判斷，到底是在類被加載器加載時就對常量池中的符號引用進行解析（初始化之前），還是等到一個符號引用將要被使用前纔去解析它（初始化之後）。
對同一個符號引用進行多次解析請求時很常見的事情，虛擬機實現可能會對第一次解析的結果進行緩存（在運行時常量池中記錄直接引用，並把常量標示爲已解析狀態），從而避免解析動作重複進行。
解析動作主要針對類或接口、字段、類方法、接口方法四類符號引用進行，分別對應於常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四種常量類型。
1、類或接口的解析：判斷所要轉化成的直接引用是對數組類型，還是普通的對象類型的引用，從而進行不同的解析。
2、字段解析：對字段進行解析時，會先在本類中查找是否包含有簡單名稱和字段描述符都與目標相匹配的字段，如果有，則查找結束；如果沒有，則會按照繼承關係從上往下遞歸搜索該類所實現的各個接口和它們的父接口，還沒有，則按照繼承關係從上往下遞歸搜索其父類，直至查找結束，查找流程如下圖所示：
從下面一段代碼的執行結果中很容易看出來字段解析的搜索順序：
class Super{
public static int m = 11;
static{
System.out.println("執行了super類靜態語句塊");
}
}
class Father extends Super{
public static int m = 33;
static{
System.out.println("執行了父類靜態語句塊");
}
}
class Child extends Father{
static{
System.out.println("執行了子類靜態語句塊");
}
}
public class StaticTest{
public static void main(String[] args){
System.out.println(Child.m);
}
}
執行結果如下：
執行了super類靜態語句塊
執行了父類靜態語句塊
33
如果註釋掉Father類中對m定義的那一行，則輸出結果如下：
執行了super類靜態語句塊
11
另外，很明顯這就是上篇博文中的第1個例子的情況，這裏我們便可以分析如下：static變量發生在靜態解析階段，也即是初始化之前，此時已經將字段的符號引用轉化爲了內存引用，也便將它與對應的類關聯在了一起，由於在子類中沒有查找到與m相匹配的字段，那麼m便不會與子類關聯在一起，因此並不會觸發子類的初始化。
最後需要注意：理論上是按照上述順序進行搜索解析，但在實際應用中，虛擬機的編譯器實現可能要比上述規範要求的更嚴格一些。如果有一個同名字段同時出現在該類的接口和父類中，或同時在自己或父類的接口中出現，編譯器可能會拒絕編譯。如果對上面的代碼做些修改，將Super改爲接口，並將Child類繼承Father類且實現Super接口，那麼在編譯時會報出如下錯誤：
StaticTest.java:24: 對 m 的引用不明確，Father 中的 變量 m 和 Super 中的 變量 m
都匹配
System.out.println(Child.m);
^
1 錯誤
3、類方法解析：對類方法的解析與對字段解析的搜索步驟差不多，只是多了判斷該方法所處的是類還是接口的步驟，而且對類方法的匹配搜索，是先搜索父類，再搜索接口。
4、接口方法解析：與類方法解析步驟類似，知識接口不會有父類，因此，只遞歸向上搜索父接口就行了。
初始化
初始化是類加載過程的最後一步，到了此階段，才真正開始執行類中定義的Java程序代碼。在準備階段，類變量已經被賦過一次系統要求的初始值，而在初始化階段，則是根據程序員通過程序指定的主觀計劃去初始化類變量和其他資源，或者可以從另一個角度來表達：初始化階段是執行類構造器<clinit>()方法的過程。
這裏簡單說明下<clinit>（）方法的執行規則:
1、<clinit>（）方法是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊中的語句合併產生的，編譯器收集的順序是由語句在源文件中出現的順序所決定的，靜態語句塊中只能訪問到定義在靜態語句塊之前的變量，定義在它之後的變量，在前面的靜態語句中可以賦值，但是不能訪問。
2、<clinit>（）方法與實例構造器<init>（）方法（類的構造函數）不同，它不需要顯式地調用父類構造器，虛擬機會保證在子類的<clinit>（）方法執行之前，父類的<clinit>（）方法已經執行完畢。因此，在虛擬機中第一個被執行的<clinit>（）方法的類肯定是java.lang.Object。
3、<clinit>（）方法對於類或接口來說並不是必須的，如果一個類中沒有靜態語句塊，也沒有對類變量的賦值操作，那麼編譯器可以不爲這個類生成<clinit>（）方法。
4、接口中不能使用靜態語句塊，但仍然有類變量（final static）初始化的賦值操作，因此接口與類一樣會生成<clinit>（）方法。但是接口魚類不同的是：執行接口的<clinit>（）方法不需要先執行父接口的<clinit>（）方法，只有當父接口中定義的變量被使用時，父接口才會被初始化。另外，接口的實現類在初始化時也一樣不會執行接口的<clinit>（）方法。
5、虛擬機會保證一個類的<clinit>（）方法在多線程環境中被正確地加鎖和同步，如果多個線程同時去初始化一個類，那麼只會有一個線程去執行這個類的<clinit>（）方法，其他線程都需要阻塞等待，直到活動線程執行<clinit>（）方法完畢。如果在一個類的<clinit>（）方法中有耗時很長的操作，那就可能造成多個線程阻塞，在實際應用中這種阻塞往往是很隱蔽的。
下面給出一個簡單的例子，以便更清晰地說明如上規則：
class Father{
public static int a = 1;
static{
a = 2;
}
}
class Child extends Father{
public static int b = a;
}
public class ClinitTest{
public static void main(String[] args){
System.out.println(Child.b);
}
}
執行上面的代碼，會打印出2，也就是說b的值被賦爲了2。
我們來看得到該結果的步驟。首先在準備階段爲類變量分配內存並設置類變量初始值，這樣A和B均被賦值爲默認值0，而後再在調用<clinit>（）方法時給他們賦予程序中指定的值。當我們調用Child.b時，觸發Child的<clinit>（）方法，根據規則2，在此之前，要先執行完其父類Father的<clinit>（）方法，又根據規則1，在執行<clinit>（）方法時，需要按static語句或static變量賦值操作等在代碼中出現的順序來執行相關的static語句，因此當觸發執行Father的<clinit>（）方法時，會先將a賦值爲1，再執行static語句塊中語句，將a賦值爲2，而後再執行Child類的<clinit>（）方法，這樣便會將b的賦值爲2.
如果我們顛倒一下Father類中“public static int a = 1;”語句和“static語句塊”的順序，程序執行後，則會打印出1。很明顯是根據規則1，執行Father的<clinit>（）方法時，根據順序先執行了static語句塊中的內容，後執行了“public static int a = 1;”語句。
另外，在顛倒二者的順序之後，如果在static語句塊中對a進行訪問（比如將a賦給某個變量），在編譯時將會報錯，因爲根據規則1，它只能對a進行賦值，而不能訪問。
總結
整個類加載過程中，除了在加載階段用戶應用程序可以自定義類加載器參與之外，其餘所有的動作完全由虛擬機主導和控制。到了初始化纔開始執行類中定義的Java程序代碼（亦及字節碼），但這裏的執行代碼只是個開端，它僅限於<clinit>（）方法。類加載過程中主要是將Class文件（準確地講，應該是類的二進制字節流）加載到虛擬機內存中，真正執行字節碼的操作，在加載完成後才真正開始。
---------------------
作者：蘭亭風雨
來源：CSDN
原文：https://blog.csdn.net/ns_code/article/details/17881581
版權聲明：本文爲博主原創文章，轉載請附上博文鏈接！