作為一名程式猿 ，我們每天都在寫Code，但你真的瞭解它的生命週期麼？今天就來簡單聊下它的生命歷程，說起一段Java Code，從出生到game over大體分這麼幾步：編譯、類載入、執行、GC。

編譯

Java語言的編譯期其實是一段“不確定 ”的過程，因為可能是一個前端編譯器把.java檔案轉變為.class檔案的過程；也可能是指JVM的後端執行期編譯器（JIT編譯器）把位元組碼轉變為機器碼的過程；還可能是指使用靜態提前編譯器（AOT編譯器）直接把.java檔案編譯成本地機器碼的過程。但是在這裡我們說的是第一類。也是符合我們大眾對編譯認知的。編譯在這個時間段經歷了哪些過程呢？

詞法、語法分析

詞法分析是將原始碼的字元流轉變為Token集合，而語法分析則是根據Token序列抽象構造語法樹（AST）的過程，AST是一種用來描述程式程式碼語法結構的樹形表示形式，語法樹的每個節點都代表著程式程式碼中的一個語法結構，例如包、型別、修飾符、運算子、介面、返回值甚至程式碼註釋都可以是一個語法結構。

填充符號表

完成了語法和詞法分析之後，下一步就是填充符號表的過程，符號表中所登記的資訊在編譯的不同階段都要用到。在這裡延伸一下符號表的概念。符號表是什麼呢？它是由一組符號地址和符號資訊構成的表格，最簡單的可以理解為雜湊表的K-V值對的形式。為什麼會用到符號表呢？符號表最早期的應用之一就是組織程式程式碼的資訊。最初，計算機程式只是一串簡單的數字，但程式猿們很快發現使用符號來表示操作和記憶體地址（變數名）要方便得多。將名稱和數字關聯起來就需要一張符號表。隨著程式的增長，符號表操作的效能逐漸變成了程式開發效率的瓶頸，為此從而誕生了許多提升序號表效率的資料結構和演算法。至於所謂的資料結構和演算法有哪些呢？大體說下：無序連結串列中的順序查詢、有序陣列中的二分查詢、二叉查詢樹、平衡查詢樹（在這我們主要接觸到的是紅黑樹）、雜湊表（基於拉鍊法的雜湊表，基於線性探測法的雜湊表）。像Java中的java.util.TreeMap和java.util.HashMap分別是基於紅黑樹和拉鍊法的雜湊表的符號表實現的。這裡提到的符號表的概念不再細說，感興趣的可以查詢相關資料。

語義分析

經過上兩步之後，我們獲得了程式程式碼的抽象語法樹表示，語法樹能表示一個正確的原始碼抽象，但無法保證源程式是符合邏輯的，這時候語義分析登場了，它的主要任務就是對結構上正確的源程式進行上下文有關性質的審查。標註檢查、資料及控制流分析、解語法糖是語義分析階段的幾個步驟，在這具體說下語法糖的概念。語法糖是指在計算機語言中新增的某種語法，這種語法對語言的功能並沒有影響，但更方便程式猿使用。Java中最常用的語法糖主要是泛型、變長引數、自從裝箱/拆箱、遍歷迴圈，JVM在執行時不支援這些語法，它們在編譯階段還原回簡單的基礎語法結構，這個過程也就是解語法糖。舉個泛型擦除的例子，List<Integer>和List<String>在編譯之後會進行泛型擦除，變成一樣的原生型別List<E>。

位元組碼生成

位元組碼生成是Javac編譯過程的最後一個階段，在這個階段會把前面各步驟生成的資訊轉化成位元組碼寫到磁碟中，還會進行了少量程式碼新增和轉換的工作。例項構造器<init>()方法和類構造器<clinit>()方法（這裡的例項構造器並不是指預設建構函式，如果使用者程式碼沒有提供任何建構函式，那編譯器將會新增一個沒有引數的、訪問性與當前類一致的預設建構函式，這個工作在填充符號表階段已經完成，而類構造器<clinit>()方法指的是編譯器自動收集類中的所有類變數賦值動作和靜態語句塊中的語句合併產生的）就是在這個階段新增到語法樹中的。到此為止整個編譯過程結束。

類載入

編譯將程式編譯成位元組碼之後，下一步就是類載入到記憶體的過程。

類載入的過程是在虛擬機器記憶體的方法區進行，這地方涉及到虛擬機器記憶體，所以在這首先簡單介紹下程式在記憶體區域分佈的概念。虛擬機器記憶體區域劃分為：程式計數器、棧、本地方法棧、堆、方法區（部分割槽域為執行時常量池）、直接記憶體。

程式計數器

程式計數器是一塊較小的記憶體空間，它可以看做是當前執行緒所執行的位元組碼的行號指示器。在JVM概念模型中，位元組碼直譯器工作時就是通過改變這個計數器的值來選取下一條需要執行的位元組碼指令。

棧

棧用於儲存區域性變數表、運算元棧、動態連結、方法出口等資訊。其中區域性變數表存放了編譯期剋制的各種基本資料型別、物件引用。它與程式計數器一樣都是執行緒私有的。

本地方法棧

本地方法棧與上面介紹的虛擬機器棧作用相似，它們的區別不過是虛擬機器棧為虛擬機器執行Java方法（位元組碼）服務，而本地方法棧則為虛擬機器使用的Native方法服務，甚至有的虛擬機器會把這兩塊合二為一。

堆

堆是JVM管理記憶體最大的一塊。它是被所有執行緒共享的一塊區域，它的唯一目的是存放物件例項，幾乎所有的物件例項都在這裡分配記憶體（像特殊的類物件會在方法區分配記憶體）。這地方也是垃圾收集管理的主要區域，從記憶體回收角度看，現在垃圾收集器都採用分代收集演算法（後面會詳細介紹），所以Java堆還可以進一步細分：新生代和老年代，而新生代進一步細分：Eden空間、From Survivor空間、To Survivor空間。為了效率考慮，堆還可能劃分為多個執行緒私有的分配緩衝區（TLAB）。無論如何劃分，都與存放內容無關，無論哪個區域，存放的依然是物件例項，它們存在的目的只是為了更好的回收和分配記憶體而已。

方法區

方法區與堆一樣，都是執行緒共享的記憶體區域，它用於儲存已被虛擬機器載入的類資訊、常量、靜態變數、即時編譯器編譯後的程式碼等資料。而執行時常量池是方法區的一部分，它主要用於存放編譯期宣告各種字面量和符號引用。

直接記憶體

直接記憶體並不是虛擬機器執行時資料區的一部分，也是不Java規範中定義的記憶體區域，你可以簡單理解為堆外記憶體，記憶體分配不受Java堆大小的限制但受整個記憶體大小的限制。

說完了虛擬機器記憶體區域的概念，我們回到正題，類載入的流程到底是什麼呢？載入、驗證、準備、解析、初始化五步。其中載入、驗證、準備、初始化是順序執行的，而解析則不一定，它有可能會在初始化之後執行。

載入

在載入階段，JVM需要完成三個步驟：首先通過類的全限定名來獲取定義此類的二進位制位元組流，然後將這個位元組流所代表的靜態儲存結構轉化為方法區的執行時資料結構，最後在記憶體中生成一個代表這個類的java.lang.Class物件，作為方法區這個類的各種資料入口。在第一步獲取二進位制位元組流中並沒有明確指出從一個*.class檔案中獲取，規定的靈活性導致我們可以從ZIP（為JAR、EAR/WAR格式提供基礎）包中獲取，從網路獲取（Applet），執行時計算生成（動態代理），其他檔案產生（JSP檔案生成的Class類），從資料庫獲取。

驗證

驗證，顧名思義，其實就是為了確保Class檔案位元組流中包含資訊符合JVM的要求，因為Class檔案的來源途徑不一定中規中矩的從編譯器產生，也有可能用十六進位制編輯器直接編寫Class檔案。校驗流程為檔案格式校驗、後設資料驗證、位元組碼驗證，這地方的具體安全校驗方式不再細說。

準備

準備階段正式為類變數分配記憶體並設定初始值的階段，這些變數所使用的記憶體都在方法區進行分配。

解析

解析階段是JVM將常量池內的符號引用替換為直接引用（指向目標的指標、相對偏移量或控制程式碼）的過程，前面我們談到的編譯填充符號表的價值在這地方體現出來了。解析過程無非就是對類或介面、欄位、介面方法進行解析。

初始化

類初始化階段是類載入過程的最後一步，在準備階段，變數已經賦過一次初始值，而在這一步，則會根據程式猿定製的要求進行初始化類變數和其他資源。在這個階段就是執行前面編譯位元組碼生成流程提到的<clinit>()方法的過程。虛擬機器也保證在多執行緒環境下這個方法被同時呼叫時被正確的加鎖、同步，保證只有一個執行緒去執行這個方法而其他執行緒阻塞等待，筆者以前寫的一篇文章《從一個簡單的Java單例示例談談併發》中，基於類初始化的單例執行緒安全的寫法涉及到的就是這塊，有興趣的可以結合起來一起看看。這地方還涉及到另一個我們比較關心的知識點，Java何時觸發對類的初始化操作呢？

• 遇到new、getstatic、putstatic或invokestatic這4條位元組碼指令時，如果類沒有初始化，則需要觸發其初始化，前面各種叉叉指令什麼鬼，簡單理解就是new一個物件的時候，讀取或者設定一個類的靜態欄位的時候，呼叫一個類的靜態方法的時候。
• 使用java.lang.reflect包的方法對類進行反射呼叫的時候，如果類沒有初始化，則需要觸發其初始化。 當初始化一個類，發現其父類還沒進行初始化，則先觸發其父類的初始化操作。
• 當虛擬機器啟動時，使用者需要指定一個要執行的主類（main方法所在類），虛擬機器會先初始化這個主類。
• 當使用JDK1.7以上的動態語言支援時，如果一個java.lang.invoke.MethodHandle例項最後的解析結果為REF_getStatic、REF_putStatic、REF_invokeStatic的方法控制程式碼，並且這個方法控制程式碼所對應類沒有進行初始化，則觸發初始化操作。

執行

經過了上面兩個階段，程式開始正常跑起來了，我們都知道程式執行過程涉及到了各種指令的計算操作， 程式如何執行的呢？這地方就會使用到文章開頭談到的後端編譯器（JIT即時編譯器）+直譯器這種搭配使用的混合模式（HotSpot虛擬機器預設採用瞭直譯器與一個編譯器），位元組碼執行引擎則負責著這類各種程式計算操作的任務，它在執行Java程式碼的時候有可能會有解釋執行（通過直譯器執行）和編譯執行（通過即時編譯器產生原生程式碼執行）兩種選擇，也可能兩者兼備。棧幀是用於支援虛擬機器進行方法呼叫和執行的資料結構，具體的壓棧彈棧各種指令計算的思路涉及到了一個經典的演算法——Dijkstra演算法，至於如何執行有興趣的自己查資料吧這地方不會過多深入。執行期的優化問題在這個階段同樣重要，而JVM設計團隊則把對效能的優化集中到了這個階段，這樣可以讓那些不是由Javac產生的Class檔案同樣享受到編譯器優化帶來的好處，至於具體的優化技術有哪些呢？有很多，這裡簡單提幾個具有代表性的優化技術：公共子表示式消除、陣列邊界檢查消除、方法內聯、逃逸分析等等。

GC

終於說到程式要進入死亡階段了。JVM是如何判斷程式藥丸的呢？這地方其實採用了可達性分析演算法，這個演算法的基本思路是通過一系列的稱為“GC Roots”的物件作為起始點，從這個節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連時（用圖論話說，就是從GC Roots到這個物件不可達），則證明此物件不可用，這時候就被判定為可回收的物件。當我們已經知道要回收的物件何時觸發垃圾收集呢？安全點，安全點就是一些讓程式暫定執行從而進行GC的位置，由此我們很容易知道GC停頓的時間是垃圾收集的核心。所有的垃圾收集演算法以及衍生出來的垃圾收集器無不圍繞著儘量減少GC停頓時間產生的，現在最新的G1垃圾收集器可以建立可預測的停頓時間模型，有計劃的避免在整個Java堆中進行全區域的垃圾收集。前文介紹記憶體區域分佈的概念的時候，我們談到了新生代、老年代，而不同的垃圾收集器有可能作用於新生代，也有可能作用於老年代，甚至沒有分代的概念（比如G1收集器），說到這，下面就具體介紹下垃圾收集演算法及對應的垃圾收集器

標記-清除演算法

最基礎的收集演算法，演算法分為標記和清除兩個階段：首先標記處所有要回收的物件，在標記完成之後統一回收所有被標記的物件。它最大的不足是效率不高，還會產生大量不連續的記憶體碎片，這樣導致的問題當程式執行過程分配較大物件時，即使堆中還有足夠的記憶體，但是無法找到足夠的連續記憶體只能不得不觸發一次GC操作。這地方對應的垃圾收集器是CMS收集器。

複製演算法

複製演算法是為了解決效率問題而生的，它可以將可用記憶體容量劃分為大小相等的兩塊，，每次只使用其中一塊，當這一塊記憶體用完了，就將還存活的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。這樣每次會對整個半區進行GC，並且不會產生記憶體碎片等問題。現在的商業虛擬機器大多采用這種演算法來回收新生代，另外劃分記憶體比例也不是1:1，像HotSpot預設Eden（一塊Eden區）和Survivor（兩塊Survivor區）的大小比例為8:1，每次使用Eden和其中一塊Surviovr區，也就是新生代中可用記憶體空間是整個新生代的90%，當回收時，將Eden和其中一塊Survivor中還存活的物件一次性複製到另一塊Survivor中，最後清理掉Eden和剛才用到的Survivor空間，細心的讀者在這地方也許會有發現，如果複製過程那塊沒使用的Survivor不夠用怎麼辦呢？這時候需要依賴老年代進行分配擔保，擔保成功就會將Eden和其中一塊Survivor中還存活的物件移動到老年代中，擔保失敗就不得不在老年代觸發一次垃圾回收。這地方延伸一下，新生代垃圾回收稱為Minor GC，因為Java物件大多朝生夕死的特性，所以Minor GC很頻繁，一般回收速度也快，而老年代垃圾回收稱為Major GC/Full GC，Major GC的速度一般會比Minor GC的速度慢很多，從前面的分析過程我們可以輕易的推斷，出現了Major GC，經常會伴隨著一次Minor GC，但非絕對，因此我們GC的目的其實也是通過調優儘量控制減少Major GC的頻率。這地方對應的垃圾收集器是Serial收集器、ParNew收集器（Serial收集器多執行緒版本，可與後面談到的老年代收集器CMS進行配合工作）、Parallel Scavenge收集器。

標記-整理演算法

這個演算法是應用在老年代垃圾回收的演算法，因為老年代不像複製演算法那樣回收頻率高，另外它還會浪費空間。標記-整理過程與標記-清除差不多，無非後續步驟不是直接對可回收物件進行清除，而是讓所有存活的物件都向一端移動，然後直接清理掉端邊界以外的記憶體。這地方對應的垃圾收集器是Serial Old收集器、Parallel Old收集器。

分代收集演算法

當前商業虛擬機器都採用這種演算法，它的思想就是我們前面提到的對堆記憶體區域進行分代，新生代和老年代，不同的區域採用不同垃圾收集演算法。新生代用複製演算法，老年代用標記-整理或標記-清除演算法。

回顧

前面扯了這麼多，也許大家對一段Java Code的生命史有點概念了，或者說沒怎麼看懂呀，在這地方我們舉個例子回顧下整個流程，當我們new一個物件的時候，會經歷什麼呢？結合前面所說的，JVM遇到一個new指令時，首先去檢查整個指令引數能否在方法區的常量池定位到一個類的符號引用，並且檢查整個符號引用代表的類是否已被載入、解析和初始化過，如果沒有，則必須先執行對應類載入過程。類載入檢查通過後，接下來JVM將會為新生物件分配記憶體，這個過程是在堆中進行的，分配大小在類載入完成後就可以確定，如果堆記憶體是規整的，則採用指標移動物件大小相等距離即可，這種分配方式叫“指標碰撞”，如果是零散的，則JVM維護一個列表記錄哪些記憶體可用，分配並更新列表記錄，這種方式叫“空閒列表”，至於採用哪種方式，取決於我們前面提到的堆採用了哪種垃圾收集器決定的。劃分完物件記憶體之後，虛擬機器會進行必要的初始化操作，接下來需要對物件進行必要的設定，這些資訊設定在物件頭（類後設資料資訊、物件的雜湊碼、物件的GC分代年齡等等）裡面，這些工作完成之後，一個新物件產生了，這地方其實還沒結束，再下一步就是呼叫<init>()方法進行程式猿計劃的對物件欄位進行的賦值操作，最後設定棧中的引用指向這個堆中物件所在的記憶體地址（直接引用），這時候一個真正可用的物件已經產生了，至於後續對物件進行的各種操作及最後的死亡就是前面提到的位元組碼執行引擎啊GC啊相信大家已不再陌生。

參考

本文內容參考《深入Java虛擬機器（第2版）》、《演算法（第4版）》，感興趣的可自行查閱。

原文出處：HugNew » 你真的瞭解一段Java程式的生命史嗎

---

關注微信訂閱號“Martin說”，每天收穫更多Martin的閒扯。