開篇

我們知道JVM的垃圾回收機制實際上是對JVM內存的操作，回收的目的是為了避免內存溢出和內存泄漏的問題。而JVM內存由方法區、堆、虛擬機棧、本地方法棧以及程序計數器5塊區域組成，虛擬機棧、本地方法棧、程序計數器是隨著Java線程建立而建立，當Java 線程完成之后這三個部分的內存就會被釋放掉。

而方法區和堆屬于共有線程，是隨著JVM啟動而建立的，而且這兩個區域與另外三個區域也有所不同，一個接口中有多少個實現類（方法區）以及每次程序運行需要創建多少對象（堆）是動態的，也就是說在程序運行時才能知道。

為了讓這部分動態的內存分配能夠進行合理的回收，就需要垃圾回收算法和垃圾回收器來幫忙了。下面讓我們進入今天的主題。

如何判斷對象“存活”？

JVM 垃圾回收機制是對堆中沒有使用的對象進行回收，那么判斷對象是否“存活”就至關重要。在判斷對象是否“存活”的方法中，我們會介紹引用計數算法和可達性分析法。

引用計數算法

Java 堆中針對每個對象都設置一個引用計數器。當一個對象被創建并初始化賦值后，該變量計數設置為1。每當有一個地方引用它時，計數器值就加1。當引用失效時，即一個對象的某個引用超過了生命周期（出作用域后）或者被設置為一個新值時，計數器值就減1。任何引用計數為0的對象可以被當作垃圾回收。當一個對象被垃圾回收時，它引用的任何對象計數減1。

這種方法的優點很明顯，引用計數回收器執行簡單，判定效率高，對程序不被長時間打斷的實時環境比較有利。不過缺點也很明顯，對于對象循環引用的場景難以判斷，同時引用計數器增加了程序執行的開銷。Java語言并沒有選擇這種算法進行垃圾回收。

可達性分析法

可達性分析法也叫根搜索算法，通過稱為 GC Roots 的對象作為起點，從上往下進行搜索。搜索所走過的路徑稱為引用鏈 （Reference Chain）， 當發現某個對象與 GC Roots之間沒有任何引用鏈相連時， 即認為該對象不可達，該對象也就成了垃圾回收的目標。

如圖1 所示，從GC Roots 開始沒有引用鏈和Obejct5、Object6 和Object7 相連，因此這三個對象對于GC Roots 而言就是不可達的，會被垃圾回收，即便他們互相都有引用。

圖1 可達性分析法

在Java中，可作為GC Roots的對象包括如下四種：

· 虛擬機棧（棧幀中的本地變量表）中引用的對象

· 本地方法棧 中 JNI （Native方法）引用的變量

· 方法區 中類靜態屬性引用的變量

· 方法區 中常量引用的變量

前面談到的可達實際上是在判斷對象是否被引用，如果沒有被引用，垃圾回收器會將其進行回收。不過我們希望存在這樣一些對象，當內存空間足夠的情況下盡量將其保留在內存中，當內存不夠的情況下，再回收這些對象。下面看看如何對如下對象進行處理：

· 強引用（Strong Reference）：例如，Object obj ＝ new Object（）這類引用，只要強引用存在，垃圾回收器永遠不會回收掉被引用的對象。

· 軟引用（Soft Reference）：在系統將要出現內存溢出之前，會將軟引用對象列進回收范圍之中進行二次回收。如果這次回收還沒有足夠的內存，才會拋出內存溢出異常。

· 弱引用（Weak Reference）：被弱引用關聯的對象只能生存到下一次垃圾回收發生之前，無論當前內存是否足夠，用軟引用相關聯的對象都會被回收掉。

· 虛引用（Phantom Reference）：虛引用也稱為幽靈引用或幻影引用，是最弱的一種引用關系，為一個對象設置虛引用的唯一目的是：能在這個對象在垃圾回收器回收的時候收到一個系統通知。

垃圾回收算法

上面講解了如何發現“存活”對象，JVM中會使用可達性分析法，說白了就是看GC Roots在引用鏈上是否有對應的對象被引用到了。接下來就在這個背景下看看有哪些垃圾回收的算法，這里我們列舉出常見的幾種：

標記清除算法

該算法分為標記和清除兩個階段，首先通過可達性分析法找到要回收的對象，也就是沒有被引用的對象，對其進行標記，然后再對該對象進行清除也就是回收了。

如圖2 所示，該算法會對內存空間進行掃描，發現GC Roots 對Object1 和Object2 進行引用，但是對Object2 沒有引用。首先標記Object2 沒有被引用。

圖2

如圖3 所示，算法再次對內存進行掃描，清除Object2 對象占用的空間，將其設置為空閑空間。

圖3 標記清除算法

該算法的優點就是簡單粗暴，沒有引用的對象會被清除掉，但是缺點是效率問題。標記和清除操作會掃描整個空間兩次（第一次：標記存活對象；第二次：清除沒有標記的對象）才能完成清理工作。同時清理過程容易產生內存碎片，這些空閑的空間無法容納大對象，如果此時有一個比較大的對象進入內存，由于該內存中沒有連續的容納大對象的空間，就會提前觸發垃圾回收。

復制算法

為了解決標記清除法帶來的問題，復制算法將內存劃分為大小相等的兩塊，每次使用其中的一塊，當這塊的內存使用完畢以后，再將對象復制到另外一塊上面，然后對已經使用過的內存空間進行清理。這樣每次對內存的一半區域進行回收，不用考慮內存碎片的問題。

如圖4 所示，上面的區域是垃圾回收之前的內存空間，我們用黑色的虛線將內存分為兩個部分。左邊的部分是正在使用的空間，右邊是預留空間。左邊區域中紅色的部分是不可回收的內存，也就是說這里面有被GC Roots 引用的對象，另外灰色的部分是可回收的區域，也就是沒有被GC Roots 引用的對象，白色區域是未分配的。

如果通過復制算法進行垃圾回收，順著綠色的箭頭向下，在回收后的內存區域可以看到，將左側紅色的內存對象移動到了右側預留的區域，并且按照順序排放。然后對左側運行的內存區域進行清理，成為預留區域等待第二次垃圾回收的執行。

圖4 復制算法

復制算法的優點是簡單高效，不會出現內存碎片。缺點也明顯，內存利用率低，只有一半的內存被利用。特別是存活對象較多時效率明顯降低，因為需要移動每個不可回收數據的內存實際位置。

標記整理算法

該算法和標記清除算法相似，但是后續步驟并不是直接對可回收對象進行清理，而是讓所有存活對象都移動到內存的前端，然后再清除掉其他可回收的對象所占用的內存空間。

如圖5 所示，回收前的內存中紅色為不可回收的內存空間，灰色是可回收空間，白色是未分配空間。執行標記整理算法的垃圾回收之后，將不可回收的內存空間整理到內存的前端，同時清除掉可回收的內存空間，此時不可回收空間之后存放的都是白色的未分配空間，供由新對象存放。

圖5 標記整理算法

標記整理算法優點是解決了標記清理算法存在的內存碎片問題。缺點也是非常明顯，需要進行局部對象移動，一定程度上降低了效率。

分代收集算法

分代收集算法，顧名思義是根據對象的存活周期將內存劃分為幾塊，然后定義回收規則。如圖6所示，從左到右分別是年輕代（Young Generation）、老年代（Old Generation） 和 永久代（Permanent Generation），另外年輕代又分為了Eden Space（伊甸空間） 、Survivor Space（幸存者空間）。分代收集的算法在當前商業虛擬機算法中被廣泛采用。

圖6 分代收集法

上面對分代收集法做了字面的解釋，現將該算法的執行過程描述如下：

1）新產生的對象優先分配在Eden區（除非配置了－XX：PretenureSizeThreshold，大于該值的對象會直接進入老年代）。有這樣一種情況，當對象剛剛在新生代創建就被回收了，對象從這個區域消失的過程我們稱之為 minor GC。

2）當Eden區滿了或放不下了，這時候其中存活的對象會復制到from區。如果此時存活下來的對象在from 區都放不下，就會放到老年代，之后Eden 區的內存會全部回收掉。

3）之后產生的對象繼續分配在Eden區，當Eden區又滿了或放不下了，這時候將會把Eden區和from區存活下來的對象復制到to區，此時如果存活下來的對象to區也放不下，會將其移動到年老代，同時會回收掉Eden區和from區的內存。

4）如果按照如上操作將對象在幾個區域中移動，會出現對象被多次復制的情況，對象被復制一次，對象的年齡就會＋1。默認情況下，當對象被復制了15次（通過：－XX：MaxTenuringThreshold來配置），該對象就會進入老年代了。

5）當老年代滿了的情況下，就會發生一次Full GC。

備注：Minor GC指發生在新生代的垃圾收集動作，因為Java對象大多都具備朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快。Full GC指發生在老年代的GC，出現了Full GC，經常會伴隨至少一次的Full GC，Full GC的速度一般會比Minor GC慢10倍以上。

垃圾回收器

如果垃圾回收算法是內存回收的方法論的話，那么垃圾回收器就是內存回收的具體實現了。下面會針對JDK1．7 Update 14 之后的HotSpot虛擬機給大家做介紹。

如圖7所示，這里將內存分為新生代和老年代，將7種不同垃圾回收器分布于其間，垃圾回收器之間存在連線，說明它們可以搭配使用。

虛擬機所處的區域，則表示它是屬于新生代收集器還是老年代收集器。Hotspot實現了如此多的收集器，正是因為目前并無完美的收集器出現，只是選擇對具體應用最適合的收集器。

圖7垃圾回收器的分類

下面就來介紹這幾個垃圾回收器：

Serial回收器

Serial（串行）回收器采用復制算法的新生代收集器，它是一個單線程回收器，針對一個CPU或一條收集線程去完成垃圾收集工作，它在進行垃圾收集時，必須暫停其他所有的工作線程，直至Serial收集器收集結束為止，這個做法也稱為 “Stop The World”。

如圖8 所示，左邊多個應用程序線程在執行， 當Serial 回收器的GC線程（虛線部分）執行的時候，應用程序線程（左邊多個實線）都會暫停，只有在回收器線程執行完畢以后，應用程序線程（右邊多個實線）才會繼續執行。

圖 8 串行垃圾回收器

該回收器的問題就是在進行垃圾回收時其他工作線程必須停頓，不過它在HotSpot虛擬機運行的Client模式下可以為新生代回收器服務。它的簡單而高效對于限定單個CPU的環境來說，Serial回收器沒有線程交互的開銷。在用戶的桌面應用場景中，分配給虛擬機管理的內存不大，停頓時間可以控制在幾十毫秒以內，還是可以接收。它對于運行在Client模式下的虛擬機來說是一個很好的選擇。

ParNew 回收器

ParNew回收器是Serial回收器的多線程版本，它也是一個新生代回收器。除了使用多線程進行垃圾收集外，其余行為包括Serial收集器可用的所有控制參數、收集算法（復制算法）、Stop The World、對象分配規則、回收策略等。

如圖9 所示，與Serial 不同的是ParNew 使用多個線程（中間多條虛線）的方式進行垃圾回收。

圖9 ParNew 并行回收器

ParNew 回收器在多CPU環境下垃圾回收的效率會有明顯提高。它默認開啟的收集線程數與CPU的數量相同，在CPU非常多的情況下可使用－XX：ParallerGCThreads參數設置。反過來，如果針對單個CPU的環境 ParNew 和Serial 回收器的效果就難分伯仲了。

Serial Old回收器

Serial Old 是 Serial回收器的老年代版本，是單線程收集器，使用標記整理（Mark－Compact）算法。它可以給Client模式下的虛擬機使用。如果在Server模式下，它還有兩大用途：在JDK1．5 以及之前版本（Parallel Old誕生以前）中與Parallel Scavenge收集器搭配使用。作為CMS收集器的后備預案，在并發收集發生Concurrent Mode Failure時使用。

Parallel Old回收器

Parallel Old回收器是Parallel Scavenge的老年代版本，使用多線程的標記整理算法。在JDK 1．6中才開始提供，如果新生代選擇了Parallel Scavenge收集器，老年代除了Serial Old以外別無選擇。Parallel Old回收器的工作流程與Parallel Scavenge相同。

Parallel Scavenge 回收器

Parallel Scavenge回收器是并行的多線程新生代回收器，它使用復制算法。Parallel Scavenge回收器的目標是達到一個可控制的吞吐量（Throughput）。

這里稍微說明一下， 吞吐量就是CPU運行用戶代碼時間與CPU總消耗時間的比值，表現成工時是：吞吐量 ＝ 用戶代碼運行時間 ／（用戶代碼運行時間 ＋ 垃圾回收時間）。用戶代碼運行時間95 分鐘，垃圾回收時間為5分鐘，那吞吐量就是95／（95＋5）＝95％。

高吞吐量說明垃圾回收器高效率地利用CPU時間，盡快完成程序的運算任務。從而讓垃圾回收造成的停頓時間變短，適合與用戶交互的程序提升用戶體驗。

Parallel Scavenge會提供精確控制吞吐量的參數，此外還通過對參數－XX：＋UseAdaptiveSizePolicy 設置來自動調節新生代的大小（－Xmn）、Eden和Survivor區的比例（－XX：SurvivorRatio）、晉升老年代對象年齡（－XX：PretenureSizeThreshold）等信息。

此外Parallel Scavenge 回收器還有一個特點就是，會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或者最大的吞吐量，我們稱之為GC自適應的調節策略（GC Ergonomics）。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是以獲取最短回收停頓時間為目標的回收器，它適用于重視響應速度的應用場景，它是基于標記清除算法而實現的。

如圖10 所示，從左往右CMS工作流程分為以下4個步驟：

· 初始標記（CMS initial mark）：標記GC Roots直接關聯到的對象，需要執行“Stop The World”，也就是讓工作線程暫停。

· 并發標記（CMS concurrent mark）：從GC Roots 查找所有可達的對象，這個過程耗時比較長，此時用戶線程依舊在運行。

· 重新標記（CMS remark）：修正并發標記期間，用戶程序繼續運作而導致標記的對象，并且調整標記記錄，此階段也需要“Stop The World”，因為不暫停工作線程的話還可能有標記不準確的情況發生。

· 并發清除（CMS concurrent sweep）：對于標記不可用的對象進行并發清除操作，這個過程耗時會比較長，此時工作線程依舊可以運行。

所以，從總體上來說，CMS收集器的內存回收過程是與用戶線程一起并發執行的。通過下圖可以比較清楚地看到CMS收集器的運作步驟中并發和需要停頓的時間：

圖10 CMS 垃圾回收器

CMS的優點明顯，并發收集、低停頓。不過他對CPU資源非常敏感，在并發階段雖然不會導致用戶線程暫停，但會因為占用了一部分線程（或者說CPU資源）而導致應用程序變慢，總吞吐量會降低。

CMS默認啟動的回收線程數是（CPU數量＋3）／4，也就是當CPU在4個以上時，并發回收時垃圾收集線程不少于25％的CPU資源，并且隨著CPU數量的增加而下降。但是當CPU不足4個時（比如2個），CMS對用戶程序的影響就可能變得很大，如果本來CPU負載就比較大，還要分出一半的運算能力去執行收集器線程，就可能導致用戶程序的執行速度忽然降低了50％。

無法處理浮動垃圾（Floating Garbage） 可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。在垃圾回收階段，用戶線程還在運行，還需要預留有足夠的內存空間給用戶線程使用，因此CMS需要預留一部分空間提供并發收集時的程序運作使用。標記清除算法本身也會導致產生大量的空間碎片。

G1回收器

G1（Garbage－First）回收器是面向服務端應用的垃圾回收器，它具備如下特點：

· 充分利用多CPU縮短“Stop The World”停頓時間，可以通過并發的方式讓Java程序繼續執行。

· 不需要其他回收器配合就能獨立管理整個GC堆，采用不同方式去處理新創建的對象和已存活一段時間、對于經歷過多次GC的舊對象來說會有更好的回收效果。

· G1基本上是基于標記整理算法實現的，在局部（兩個Region之間）是基于復制算法實現的。這意味著G1運行期間不會產生內存空間碎片，收集后能提供規整的可用內存。此特性有利于程序長時間運行，分配大對象時不會因為無法找到連續內存空間而提前觸發下一次GC。

· 可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在GC上的時間不得超過N毫秒。

與其他垃圾回收器不同的是，G1回收的范圍橫跨整個堆內存。

如圖11所示，G1將堆劃分為多個大小相等的區域（Region），雖然還保留新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，而是Region的集合。

圖11 G1 將堆進行分Region

前面提到G1回收器可以預測的停頓時間，是因為它避免在整個Java堆中進行全區域的垃圾回收。G1會跟蹤各個Region的垃圾堆積的價值大小（回收的空間大小以及回收所需時間的經驗值），在后臺維護一個優先列表，每次根據允許的回收時間，優先回收價值最大的Region。

雖然G1把Java堆分為多個Region，在某個Region中的對象可以與位于其他Region中的任意對象發生引用關系。在做可達性分析時仍然需要掃描整個堆，顯然這樣做效率是不高的。為了避免全堆掃描， G1為每個Region維護了一個記憶集（Remembered Set）。當發現程序在對引用（Reference）類型的數據進行寫操作時，會產生一個Write Barrier暫時中斷寫操作。然后檢查引用（Reference）對象是否處于不同的Region之中，如果是便通過CardTable把相關引用信息記錄到被引用對象所屬的Region的記憶集（Remembered Set）之中。當進行內存回收時，在GC根節點的枚舉范圍中加入Remembered Set即可保證不對全堆掃描也不會有遺漏。說白了就是通過Remembered Set 記錄跨Region引用的對象，其目的是避免全堆掃描。

如圖12所示，Region2 中的兩個對象分配被Region1 和Region3 中的對象引用，因此在Region2中的記憶集（Remembered set）就會記錄這兩個引用的信息，在垃圾回收的時候只需要收集記憶集的信息就知道對象在每個Region 的引用關系了，并不需要掃描所有堆的Region。

圖12 跨Region的對象引用

說了G1 的特點和機制，下面通過圖13 來看看它的執行過程：

· 初始標記（Initial Marking）：標記GC Roots 能直接引用的對象，讓下一階段用戶程序并發運行時，能在正確的Region中創建對象，此階段需要停頓線程，但耗時很短。

· 并發標記（Concurrent Marking） ：從GC Root 開始對堆中對象進行可達性分析，找到存活對象，此階段耗時較長，但可與用戶程序并發執行。

· 最終標記（Final Marking）：為了修正在并發標記期間因用戶程序繼續運作而導致標記產生變動的那一部分標記記錄，虛擬機將這段時間對象變化記錄在線程的Remembered Set Logs里面，最終標記階段需要把Remembered Set Logs的數據合并到Remembered Set中，這階段需要停頓線程，但是可并行執行。

· 篩選回收（Live Data Counting and Evacuation） ：首先對各個Region中的回收價值和成本進行排序，根據用戶所期望的GC 停頓時間來制定回收計劃。此階段其實也可以做到與用戶程序一起并發執行，但是因為只回收一部分Region，時間是用戶可控制的，而且停頓用戶線程將大幅度提高收集效率。

總結

今天給大家介紹了垃圾回收的算法和JVM的垃圾回收器，算法作為思路和方法論的指導，而垃圾回收器是方法論的最佳實踐，這里通過一張表格將兩者進行一個總結：