開篇

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

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

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

如何判斷對象“存活”？

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

引用計數(shù)算法

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

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

可達性分析法

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

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

圖1 可達性分析法

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

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

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

· 方法區(qū) 中類靜態(tài)屬性引用的變量

· 方法區(qū) 中常量引用的變量

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

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

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

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

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

垃圾回收算法

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

標記清除算法

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

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

圖2

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

圖3 標記清除算法

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

復制算法

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

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

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

圖4 復制算法

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

標記整理算法

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

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

圖5 標記整理算法

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

分代收集算法

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

圖6 分代收集法

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

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

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

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

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

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

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

垃圾回收器

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

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

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

圖7垃圾回收器的分類

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

Serial回收器

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

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

圖 8 串行垃圾回收器

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

ParNew 回收器

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

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

圖9 ParNew 并行回收器

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

Serial Old回收器

Serial Old 是 Serial回收器的老年代版本，是單線程收集器，使用標記整理（Mark－Compact）算法。它可以給Client模式下的虛擬機使用。如果在Server模式下，它還有兩大用途：在JDK1．5 以及之前版本（Parallel Old誕生以前）中與Parallel Scavenge收集器搭配使用。作為CMS收集器的后備預案，在并發(fā)收集發(fā)生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總消耗時間的比值，表現(xiàn)成工時是：吞吐量 ＝ 用戶代碼運行時間 ／（用戶代碼運行時間 ＋ 垃圾回收時間）。用戶代碼運行時間95 分鐘，垃圾回收時間為5分鐘，那吞吐量就是95／（95＋5）＝95％。

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

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

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

CMS收集器

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

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

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

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

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

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

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

圖10 CMS 垃圾回收器

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

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

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

G1回收器

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

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

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

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

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

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

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

圖11 G1 將堆進行分Region

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

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

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

圖12 跨Region的對象引用

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

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

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

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

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

總結

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