1.加載
加載（loading）階段是“類加載” （Class Loading）過程的一個階段，在加載階段，虛擬機需要完成以下三件事情：
1）通過一個類的全限定名來獲取定義此類的二進制字節流。
2）將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構
3）在Java堆中生成一個代表這個類的java.lang.Class對象，作為方法區這些數據的訪問入口。
虛擬機規范這三點並不具體，因此虛擬機實現與具體應用的靈活度相當大。加載方式很多：
- 從zip包中讀取，日后發展為JAR,EAR,WAR格式
- 從網絡中獲取，這場景最典型的是Applet
- 運行時計算生成，此場景使用最多的是動態代理技術，在java.lang.reflect.Proxy中，就是用ProxyGenerator.generateProxyClass來為特定接口生成*$Proxy的代理類的二進制字節流。
- 由其他文件生成，典型場景:JSP應用
- 從數據庫中讀取
- 。。。。
加載完成后，虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區中，方法區中的數據存儲格式由虛擬機實現自行定義，虛擬機規范未規定此區域的具體數據結構。然后再Java堆中實例化一個java.lang.Class類的對象，這個對象將作為程序訪問方法區中的這些類型數據的外部接口。加載階段與連接階段的部分內容（如一部分字節碼文件格式驗證動作）是交叉進行的，加載階段尚未完成，連接階段可能已經開始，但這些夾在加載階段之中進行的動作，仍然屬於連接階段的內容，這兩個階段開始時間仍然保持着固定的先后順序。
2.驗證
驗證是連接階段的第一步，這一階段目的是為了確保Class文件的字節流中包含的信息符合當前虛擬機的要求，並且不會危害虛擬機自身安全。
虛擬機規范對這個階段的限制和指導非常籠統，僅僅說了一句如果驗證到輸入的字節流不符合Class文件的存儲格式，就拋出一個java.lang.VerifyError異常或者其子類異常。具體應當檢查哪些方面，如何檢查，何時檢查，都沒有強制要求或明確說明，所以不同的虛擬機對驗證的實現可能會有所不同，但大致上都會完場下面四個階段的檢驗過程：文件格式驗證、元數據驗證、字節碼驗證和符號引用驗證。
1.文件格式驗證
第一階段要驗證字節流是否符合Class文件格式的規范否，並且能被當前版本的虛擬機處理。該驗證階段的主要目的是保證輸入的字節流能正確的解析並存儲於方法區之內，格式上符合描述一個Java類型的信息的要求。這階段的驗證是基於字節流進行的，經過這個就餓段的驗證之后，字節流才會進入內存的方法區進行存儲，所以后面三個驗證階段全部是基於方法區的存儲結構進行的。
2.元數據驗證
第二階段是對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言的規范要求，這個階段可能包括的驗證點如下：
- 這個類是否有父類（除了java.lang.Object之外，所有的類應當有父類）
- 這個類的父類是否繼承了不允許被繼承的類（被final修飾）
- 如果這個類不是抽象類，是否實現了其父類或接口之中要求實現的所有方法。
- 類中的字段、方法是否與父類產生了矛盾
- 。。。。。
3.字節碼驗證
第三個階段是驗證過程中最復雜的一個，其主要工作是進行數據流和控制流分析。第二階段對元數據信息中的數據類型做完校驗后，這階段將對類的方法體進行校驗分析。這階段的任務是保證被校驗類的方法在運行時不會做出危害虛擬機安全的行為,例如：
- 保證任意時刻操作數棧的數據類型與指令代碼序列都能配合工作，例如不會出現類似這種情況：在操作棧中放置了一個int類型的數據，使用時卻按long類型來加載入本地變量表中。
- 保證跳轉指令不會跳轉到方法體以外的字節碼指令上。
- 保證方法體中的類型轉換是有效的，例如可以把一個子類對象賦值給父類數據類型，這是安全的，反之不合法。
- 。。。。。。
如果一個類的方法體的字節碼沒有通過字節碼驗證，那肯定是有問題的；如果一個方法體通過了字節碼驗證，也不能說明其一定就是安全的。即使字節碼驗證之中進行了大量的檢查，也不能保證這一點。這里涉及了離散數學中一個很著名的問題“Halting Problem“：通俗一點的說法就是，通過程序去校驗程序邏輯是無法做到絕對准確的--不能通過程序准確地檢查出程序是否能在有限的時間之內結束運行。
為避免將過多時間消耗在字節碼驗證階段，1.6之后給方法體的Code屬性的屬性表中增加了一項名為“StackMapTable”的屬性，這項屬性描述了方法體重所有的基本塊開始時本地變量表和操作棧應有的狀態，這可以將字節碼驗證的類型推導轉變為類型檢查從而節省一些時間。使用-XX：-UseSplitVerifier選項來關閉掉這項優化，或者使用參數-XX:+FailOverToOldVerifier要求在類型校驗失敗的時候瑞回到舊的類型推導方式進行校驗（1.7之后不允許）。
4.符號引用驗證
最后一個階段的校驗發生在虛擬機將符號引用轉化為直接引用的時候，這個轉化動作將在連接的第三個階段——解析階段中發生。符號引用驗證可以看做是對類自身以外的信息進行匹配性的校驗，通常需要校驗以下內容：
- 符號引用中通過字符串描述的全限定名是否能找到對應的類。
- 在指定類中是否存在符合方法的字段描述符以及簡單名稱所描述的方法和字段。
- 符號引用中的類、字段和方法的訪問性（private、protected、public、default）是否可被當前類訪問。
- 。。。。。。
符號引用驗證的目的是確保解析動作能正常執行，如果無法通過符號引用驗證，將會拋出一個java.lang.IncompatibleClassChangeError異常的子類，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
驗證階段對於虛擬機的類加載機制來說，是一個非常重要、但不一定是必要的階段。如果所運行的全部代碼都已經被反復使用和驗證過，在實施階段就可以考慮使用-Xverify：none參數來關閉大部分的類驗證措施，以鎖單虛擬機類加載的時間。
3.准備
准備階段是正式為類變量分配內存並設置類變量初始值得階段，這些內存都將在方法區中進行分配。這個階段中有兩個容易產生混淆的概念需要強調一下，首先是這時候進行內存分配的僅包括類變量（被static修飾的變量），而不包括實例變量，實例變量將會在對象實例化時睡着對象一起分配在Java堆中。其次是這里所說的初始值“通常情況下”是數據類型的零值。
public static int value=123；
此時value初始化為0，而不是123。如果類字段的字段屬性表中存在ConstantValue屬性，那在准備階段變量value就會被初始化為ConstantValue屬性所指定的值，如：
public static final int value = 123；
編譯時Javac將會為value生成ConstantValue屬性，在准備階段虛擬機就會根據ConstantValue的設置將value賦值為123。
4.解析
解析階段是虛擬機將常量池內的符號引用替換為直接引用發的過程。
符號引用(Symbolic References): 符號引用以一組符號來描述所引用的目標，符號可以使任何形式的字面量，只要使用時能無歧義地定位到目標即可。符號引用於虛擬機實現的內存布局無關，引用的目標不一定已經加載到內存中。
直接引用（Direct References):直接引用可以是直接指向目標的指針，相對偏移量或是一個能簡介定位到目標的句柄，直接引用是與虛擬機實現的內存布局相關的，統一符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同，如果有了直接引用，那引用的目標必定已經在內存中存在。
虛擬機規范之中並未規定解析階段發生的具體時間，只要求在執行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic這13個用於操作符引用的字節碼指令之前，先對它們使用的符號引用進行解析。
解析動作主要針對類或接口、字段、類方法、接口方法四類符號引用進行，分別對應於常量池的CONSTANT_Class_info,CONSTANT_Fieldref_info、CONSTANT_Methodref_info以及CONSTANT_InterfaceMethodref_info 四種常量類型。下面講解這四種引用的解析過程。
1.類或接口的解析
假設當前代碼所處的類為D，如果要把一個從未解析過的符號引用N解析為一個類或接口C的直接引用，那虛擬機完成整個解析的過程需要包括以下三個步驟：
1）如果C不是一個數組類型，那虛擬機將會把代表N的全限定名傳遞給D的類加載器去加載這個類C。在加載過程中，由於無數據驗證、字節碼驗證的需要，又將可能觸發其他相關類的加載動作，例如加載這個類的父類或實現的接口。一旦這個加載過程出現了任何異常，解析過程就將宣告失敗。
2）如果C是一個數組類型，並且數組的元素類型為對象，也就是N的描述符會是類似“Ljava.lang.Integer”的形式，那將會按照第一點的規則加載數組元素類型。如果N的描述符如全面所假設的形式，需要加載的元素類型就是“java.lang.Integer”,接着由虛擬機生成一個代表次數組維度和元素的數組對象。
2.字段解析
要解析一個未被解析過的字段符號引用，首先對堆字段表內class_index項中索引CONSTANT_Class_info符號引用進行解析，也就是字段所屬的類或接口的符號引用。如果在解析這個類或接口符號引用的過程中出現了任何異常，都會導致字段符號引用解析的失敗。如果解析成功完成，那將這個字段所屬的類或接口用C表示，虛擬機規范要求按照如下步驟對C進行后續字段的搜索：
1）如果C本身就包含了簡單名稱和字段描述符都與目標匹配的字段，則返回這個字段的直接引用，查找結束。
2）否則，如果在C中實現了接口，將會按照繼承關系從上往下遞歸搜索各個接口和它的父接口。如果接口中包含了簡單名稱和字段描述符都與目標匹配的字段，則返回這個字段的直接引用，查找結束。
3）否則，如果C不是java.lang.Object的話，將會按照繼承關系從上往下遞歸搜索其父類，如果接口中包含了簡單名稱和字段描述符都與目標相匹配的字段，則返回這個字段的直接引用，查找結束。
3）否則，查找失敗，拋出java.lang.NoSuchFieldError異常。
如果查找過程成功返回了引用，將會對這個字段進行權限驗證，如果發現不具備對字段的訪問權限，將拋出java.lang.IllegalAccessError異常。
3.類方法解析
類方法解析第一步和字段解析一樣，線解析出class_index項中索引的方法所屬的類或接口的符號引用，如果解析成功，用C表示這個類，虛擬機會按照點如下步驟進行后續類方法搜索：
1）類方法和接口方法符號引用的常量類型定義是分開的，如果在類方法表中發現class_index中索引的C是個接口，那就直接拋出java.lang.IncompatibleClassChangeError異常。
2）如果通過了第（1）步，在類C中查找是否有簡單名稱和描述符都與目標相匹配的方法，如果有則返回這個方法的直接引用，查找結束。
3）否則，在類C的父類中遞歸查找是否有這個方法，如果有則返回這個方法的直接引用，查找結束。
4）否則，在類C實現的接口列表以及它們的父接口之中遞歸查找是否有此方法，如果存在匹配，說明類C是一個抽象類，這時候查找結束，拋出java.lang.AbstractMethodError異常。
5）否則，宣告方法查找失敗，拋出java.lang.NoSuchMethodError。
最后，如果查找過程成功返回了直接引用，將會對這個方法進行權限驗證；如果發現不具備對此方法的訪問權限，將拋出java.lang.IllegalAccessError異常。
4.接口方法解析
接口方法也是需要先解析出接口方法表的class_index項中索引的方法所屬的類或接口的符號引用，如果解析成功，依然用C表示這個接口，接下來虛擬機將會按照如下步驟進行后續的接口方法搜索:
1)與類方法解析相反，如果在接口方法表中發現class_index中索引C是個類而不是接口，那就直接拋出java.lang.IncompatibleClassChangeError異常。
2）否則，在接口中查找是否有此方法，如果有則返回這個方法的直接引用，查找結束。
3）否則，在接口C的父接口中遞歸查找，直到java.lang.Object類為止，看是否有此方法，如果有則返回這個方法直接引用，查找結束。
4）否者，宣告方法查找失敗，拋出java.lang.NoSuchMethodError異常。
因為接口方法都是public 所以沒有IllegalAccessError異常。
5.初始化
直到初始化才真正開始執行類中定義的Java程序代碼。初始化階段是執行類的構造器<clinit>()方法的過程。
- <clinit>()方法是由編譯器自動收集類中所有的類變量賦值動作和靜態語句塊中的語句合並產生的，收集順序取決於出現在源文件中的位置。靜態語句塊中只能訪問到定義在靜態語句塊之前的變量，定義在它之后的變量，在前面的靜態語句塊中可以復制，但是不能訪問。
- <clinit>()方法與類的構造函數不同，它不需要顯示調用父類構造器，虛擬機保證在子類的<clinit>()方法執行之前，父類的<clinit>()方法已經執行完畢。因此虛擬機中第一個被執行的<clinit>()方法的類肯定是java.lang.Object。
- 由於父類的<clinit>()方法先執行，也就意味着父類中定義的靜態語句塊要優先於子類的變量賦值操作。
- 如果一個類中沒有靜態變量或靜態語句塊，那么編譯器可以不為這個類生成<clinit>()方法。
- 接口中不能使用靜態代碼塊，但可使用靜態變量。與類不同的是，執行接口的<clinit>()方法不需要先執行父接口的<clinit>()方法。只有父接口中定義的變量被使用時父接口才會被初始化，另外，接口的實現類在初始化時頁一樣不會執行接口的<clinit>()方法。
- 虛擬機會保證一個類的<clinit>()方法在多線程環境中被正確的加鎖和同步。多線程訪問，一個訪問其他都被阻塞。