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

　編譯

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

詞法、語法分析

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

填充符號表

完成了語法和詞法分析之后，下一步就是填充符號表的過程，符號表中所登記的信息在編譯的不同階段都要用到。在這里延伸一下符號表的概念。符號表是什么呢？它是由一組符號地址和符號信息構成的表格，最簡單的可以理解為哈希表的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版）》，感興趣的可自行查閱。