說起垃圾收集（Garbage Collection，GC），大部分人都把這項(xiàng)技術(shù)當(dāng)做Java語言的伴生產(chǎn)物。事實(shí)上，GC的歷史遠(yuǎn)比Java久遠(yuǎn)，1960年誕生于MIT的Lisp是第一門真正使用內(nèi)存動態(tài)分配和垃圾收集技術(shù)的語言。當(dāng)List還在胚胎時(shí)期時(shí)，人們就在思考GC需要完成的3件事情：

1. 哪些內(nèi)存需要回收？
2. 什么時(shí)候回收？
3. 如何回收？

一、哪些內(nèi)存需要回收？

從JVM區(qū)域結(jié)構(gòu)看，可將這些區(qū)域劃分為“靜態(tài)內(nèi)存”和“動態(tài)內(nèi)存”兩類。程序計(jì)數(shù)器、虛擬機(jī)棧、本地方法3個(gè)區(qū)域是“靜態(tài)”的，因?yàn)檫@幾個(gè)區(qū)域的內(nèi)存分配和回收都具備確定性，都隨著線程而生，隨著線程而滅。但Java堆和方法區(qū)不一樣，內(nèi)存分配都存在不確定性，只有在程序處于運(yùn)行期間才能知道會創(chuàng)建哪些對象，這部分內(nèi)存和回收都是動態(tài)的，垃圾收集器所關(guān)注的是這部分內(nèi)存。

在堆里面存放著Java世界幾乎所有的對象實(shí)例，垃圾回收器在對堆進(jìn)行回收前，第一件事情就是就是要確定這些對象哪些還"存活"著，哪些已經(jīng)"死去"。那么又怎么確定對象已經(jīng)"死去"呢？

1.引用計(jì)數(shù)法：

分配對象時(shí)給對象添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器值就加1；當(dāng)引用失效時(shí)，計(jì)數(shù)器值就減1；任何時(shí)刻計(jì)數(shù)器為0的對象就是沒有再被使用了。客觀地說，引用計(jì)數(shù)法（Reference Counting）的實(shí)現(xiàn)簡單，判斷效率也很高，但是在主流的Java虛擬機(jī)里面沒有選用引用計(jì)數(shù)法來管理內(nèi)存，其中最主要的原因是它很難解決對象之間相互循環(huán)引用的問題。例如：

public class ReferenceCountingGC {
 public Object instance = null;
 private byte[] bigsize = new byte[2*1024*1024];
 public static void testGC(){
 ReferenceCountingGC objA = new ReferenceCountingGC();
 ReferenceCountingGC objB = new ReferenceCountingGC();
 objA.instance = objB;
 objB.instance = objA;
 objA = null;
 objB = null;
 System.gc();
 }
}

當(dāng)設(shè)置objA = null;objB = null后這兩個(gè)對象再無任何引用，實(shí)際上這兩個(gè)對象已經(jīng)不可能再被訪問，但是它們因?yàn)榛ハ嘁弥鴮Ψ剑瑢?dǎo)致它們的引用計(jì)數(shù)都不為0，于是引用計(jì)數(shù)算法無法通知GC收集器回收它們。如果這個(gè)對象特別大，則會造成嚴(yán)重的內(nèi)存泄露。

2.可達(dá)性分析算法：

可達(dá)性分析（Reachability Analysis）的基本思想是通過一系列的稱為“GC Roots”的對象作為起始點(diǎn)，從這些節(jié)點(diǎn)開始向下搜索，搜索所走過的路徑稱為引用鏈（Reference Chain），當(dāng)一個(gè)對象到GC Roots沒有任何引用鏈相連時(shí)（也就是GC Roots到這個(gè)對象不可達(dá)），則證明此對象是不可用的。如下圖所示：

對象Object5、Object6、Object7相互雖然有關(guān)聯(lián)，但是它們到GC Roots是不可達(dá)的，所以它們將會被判定為是可回收的對象。在Java語言中，可作為GC Roots的對象包括下面幾種：

• 虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象。
• 方法區(qū)中類靜態(tài)屬性引用的對象。
• 方法區(qū)中常量引用的對象。
• 本地方法棧中JNI（即一般說的Native方法）引用的對象。

二、什么時(shí)候回收？

虛擬機(jī)為了分析GC Roots這項(xiàng)工作必須在一個(gè)能確保一致性的快照中進(jìn)行，這里的“一致性”的意思就是指在整個(gè)分析期間整個(gè)執(zhí)行系統(tǒng)看起來就像被凍結(jié)在某個(gè)時(shí)間點(diǎn)上——這叫安全點(diǎn)。當(dāng)然，程序執(zhí)行時(shí)并非在所有地方都能停頓下來開始GC，只有到達(dá)安全點(diǎn)時(shí)才能暫停。安全點(diǎn)選址也有規(guī)定的，選定基本上是以程序“是否具有讓程序長時(shí)間執(zhí)行的特征”為標(biāo)準(zhǔn)進(jìn)行選定的。這里的長時(shí)間執(zhí)行的最明顯特征是指令列復(fù)用，例如方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)等。

虛擬機(jī)為了能讓所有線程都“跑”到安全點(diǎn)上停頓下來，設(shè)計(jì)了兩個(gè)方案：搶先式中斷和主動式中斷。其中搶先式中斷是虛擬機(jī)發(fā)生GC時(shí)，首先把所有線程全部中斷，如果發(fā)生有線程中斷的地方不在安全點(diǎn)上，就恢復(fù)線程，讓它“跑”到安全點(diǎn)上。這種方式現(xiàn)在比較用了。而主動式中斷是虛擬機(jī)需要GC時(shí)僅僅簡單的設(shè)置一個(gè)標(biāo)志，各個(gè)線程執(zhí)行到安全點(diǎn)時(shí)主動去輪詢這個(gè)標(biāo)志，發(fā)現(xiàn)中斷標(biāo)志為真時(shí)就自己中斷掛起。

三、如何回收？

3.1 垃圾收集算法:

（1）標(biāo)記-清除（Mark-Sweep）算法

這是最基礎(chǔ)的算法，就像它名字一樣，算法分為“標(biāo)記”和“清除”兩個(gè)階段：首先標(biāo)記處所有需要回收的對象（如哪些內(nèi)存需要回收所描述的對象），對標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對象，如下圖所示：

缺點(diǎn)：一個(gè)是效率問題，標(biāo)記和清除兩個(gè)過程的效率都不高；另一個(gè)是空間問題，標(biāo)記清除后悔產(chǎn)生大量的不連續(xù)的內(nèi)存碎片，可能會導(dǎo)致后續(xù)無法分配大對象而導(dǎo)致再一次觸發(fā)垃圾收集動作。

（2）復(fù)制算法

為了針對標(biāo)記-清除算法的不足，復(fù)制算法將可用內(nèi)存容量劃分為大小相等的兩塊，每次只使用一塊。當(dāng)一塊的內(nèi)存用完了，就將還存活的對象復(fù)制到另一塊上面去。然后把已使用過的內(nèi)存空間一次清理掉，如下圖所示：

缺點(diǎn)：使用內(nèi)存比原來縮小了一半。

現(xiàn)在的商業(yè)虛擬機(jī)都采用這種收集算法來回收新生代，有企業(yè)分析的得出其實(shí)并不需求將內(nèi)存按1:1的比例劃分，因?yàn)樾律械膶ο蟠蟛糠侄际恰俺λ馈钡?。所以，HotSpot虛擬機(jī)默認(rèn)的Eden和Survivor的大小比例是8:1。一塊Eden和兩塊Survivor，每次使用一塊Eden和一塊Survivor，也就是說只有10%是浪費(fèi)的。如果另一塊Survivor都無法存放上次垃圾回收的對象時(shí)，那這些對象將通過“擔(dān)保機(jī)制”進(jìn)入老年代了。

（3）標(biāo)記-整理（Mark-Compact）算法

復(fù)制算法一般是對對象存活率較低的一種回收操作，但對于對象存活率較高的內(nèi)存區(qū)域（老年代）來說，效果就不是那么理想了，標(biāo)記-整理算法因此誕生了。標(biāo)記-整理算法和標(biāo)記-清除算法差不多，都是一開始對回收對象進(jìn)行標(biāo)記，但后續(xù)不是直接對對象清理，而是讓所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內(nèi)存，如下圖所示：

（4）分代收集算法

分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根據(jù)對象存活的生命周期將內(nèi)存劃分為若干個(gè)不同的區(qū)域。一般情況下將堆區(qū)劃分為老年代（Tenured Generation）和新生代（Young Generation），老年代的特點(diǎn)是每次垃圾收集時(shí)只有少量對象需要被回收，而新生代的特點(diǎn)是每次垃圾回收時(shí)都有大量的對象需要被回收，那么就可以根據(jù)不同代的特點(diǎn)采取最適合的收集算法。

3.2 垃圾收集器：

（1）七種垃圾收集器:

1. Serial（串行GC）-復(fù)制
2. ParNew（并行GC）-復(fù)制
3. Parallel Scavenge（并行回收GC）-復(fù)制
4. Serial Old（MSC）（串行GC）-標(biāo)記-整理
5. CMS（并發(fā)GC）-標(biāo)記-清除
6. Parallel Old（并行GC）--標(biāo)記-整理
7. G1（JDK1.7update14才可以正式商用）

說明：

1. 1~3用于年輕代垃圾回收：年輕代的垃圾回收稱為minor GC
2. 4~6用于年老代垃圾回收（當(dāng)然也可以用于方法區(qū)的回收）：年老代的垃圾回收稱為full GC
3. G1獨(dú)立完成"分代垃圾回收"

注意：并行與并發(fā)

1. 并行：多條垃圾回收線程同時(shí)操作
2. 并發(fā)：垃圾回收線程與用戶線程一起操作

(2)常用五種組合:

1. Serial/Serial Old
2. ParNew/Serial Old：與上邊相比，只是比年輕代多了多線程垃圾回收而已
3. ParNew/CMS：當(dāng)下比較高效的組合
4. Parallel Scavenge/Parallel Old：自動管理的組合
5. G1：最先進(jìn)的收集器，但是需要JDK1.7update14以上

(2.1)Serial/Serial Old：

特點(diǎn)：

• 年輕代Serial收集器采用單個(gè)GC線程實(shí)現(xiàn)"復(fù)制"算法（包括掃描、復(fù)制）
• 年老代Serial Old收集器采用單個(gè)GC線程實(shí)現(xiàn)"標(biāo)記-整理"算法
• Serial與Serial Old都會暫停所有用戶線程（即STW）

說明：

STW（stop the world）：編譯代碼時(shí)為每一個(gè)方法注入safepoint（方法中循環(huán)結(jié)束的點(diǎn)、方法執(zhí)行結(jié)束的點(diǎn)），在暫停應(yīng)用時(shí)，需要等待所有的用戶線程進(jìn)入safepoint，之后暫停所有線程，然后進(jìn)行垃圾回收。

適用場合：

• CPU核數(shù)<2，物理內(nèi)存<2G的機(jī)器（簡單來講，單CPU，新生代空間較小且對STW時(shí)間要求不高的情況下使用）
• -XX:UseSerialGC：強(qiáng)制使用該GC組合
• -XX:PrintGCApplicationStoppedTime：查看STW時(shí)間
• 由于它實(shí)現(xiàn)相對簡單，沒有線程相關(guān)的額外開銷（主要指線程切換與同步），因此非常適合運(yùn)行于客戶端PC的小型應(yīng)用程序，或者桌面應(yīng)用程序（比如swing編寫的用戶界面程序），以及我們平時(shí)的開發(fā)、調(diào)試、測試等。

(2.2)ParNew/Serial Old：

說明：

ParNew除了采用多GC線程來實(shí)現(xiàn)復(fù)制算法以外，其他都與Serial一樣，但是此組合中的Serial Old又是一個(gè)單GC線程，所以該組合是一個(gè)比較尷尬的組合，在單CPU情況下沒有Serial/Serial Old速度快（因?yàn)镻arNew多線程需要切換），在多CPU情況下又沒有之后的三種組合快（因?yàn)镾erial Old是單GC線程），所以使用其實(shí)不多。

-XX:ParallelGCThreads：指定ParNew GC線程的數(shù)量，默認(rèn)與CPU核數(shù)相同，該參數(shù)在于CMS GC組合時(shí)，也可能會用到

(2.3)Parallel Scavenge/Parallel Old：

特點(diǎn)：

1. 年輕代Parallel Scavenge收集器采用多個(gè)GC線程實(shí)現(xiàn)"復(fù)制"算法（包括掃描、復(fù)制）
2. 年老代Parallel Old收集器采用多個(gè)GC線程實(shí)現(xiàn)"標(biāo)記-整理"算法
3. Parallel Scavenge與Parallel Old都會暫停所有用戶線程（即STW）

說明：

1. 吞吐量：CPU運(yùn)行代碼時(shí)間/(CPU運(yùn)行代碼時(shí)間+GC時(shí)間)
2. CMS主要注重STW的縮短（該時(shí)間越短，用戶體驗(yàn)越好，所以主要用于處理很多的交互任務(wù)的情況）
3. Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，說明CPU利用率越高，所以主要用于處理很多的CPU計(jì)算任務(wù)而用戶交互任務(wù)較少的情況）

參數(shù)設(shè)置：

1. -XX:+UseParallelOldGC：使用該GC組合
2. -XX:GCTimeRatio：直接設(shè)置吞吐量大小，假設(shè)設(shè)為19，則允許的最大GC時(shí)間占總時(shí)間的1/(1 +19)，默認(rèn)值為99，即1/(1+99)
3. -XX:MaxGCPauseMillis：最大GC停頓時(shí)間，該參數(shù)并非越小越好
4. -XX:+UseAdaptiveSizePolicy：開啟該參數(shù)，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold這些參數(shù)就不起作用了，虛擬機(jī)會自動收集監(jiān)控信息，動態(tài)調(diào)整這些參數(shù)以提供最合適的的停頓時(shí)間或者最大的吞吐量（GC自適應(yīng)調(diào)節(jié)策略），而我們需要設(shè)置的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio兩個(gè)參數(shù)就好（當(dāng)然-Xms也指定上與-Xmx相同就好）

適用場合：

1. 很多的CPU計(jì)算任務(wù)而用戶交互任務(wù)較少的情況
2. 不想自己去過多的關(guān)注GC參數(shù)，想讓虛擬機(jī)自己進(jìn)行調(diào)優(yōu)工作
3. 對吞吐量要求較高，或需要達(dá)到一定的量。

(2.4)ParNew/CMS：

說明：

1. 以上只是年老代CMS收集的過程，年輕代ParNew看"2.2、ParNew/Serial Old"就好
2. CMS是多回收線程的，不要被上圖誤導(dǎo)，默認(rèn)的線程數(shù)：(CPU數(shù)量+3)/4
3. CMS主要注重STW的縮短（該時(shí)間越短，用戶體驗(yàn)越好，所以主要用于處理很多的交互任務(wù)的情況）

特點(diǎn)：

1.年輕代ParNew收集器采用多個(gè)GC線程實(shí)現(xiàn)"復(fù)制"算法（包括掃描、復(fù)制）

2.年老代CMS收集器采用多線程實(shí)現(xiàn)"標(biāo)記-清除"算法

• 初始標(biāo)記：標(biāo)記與根集合節(jié)點(diǎn)直接關(guān)聯(lián)的節(jié)點(diǎn)。時(shí)間非常短，需要STW
• 并發(fā)標(biāo)記：遍歷之前標(biāo)記到的關(guān)聯(lián)節(jié)點(diǎn)，繼續(xù)向下標(biāo)記所有存活節(jié)點(diǎn)。時(shí)間較長。
• 重新標(biāo)記：重新遍歷trace并發(fā)期間修改過的引用關(guān)系對象。時(shí)間介于初始標(biāo)記與并發(fā)標(biāo)記之間，通常不會很長。需要STW
• 并發(fā)清理：直接清除非存活對象，清理之后，將該線程占用的CPU切換給用戶線程

3.初始標(biāo)記與重新標(biāo)記都會暫停所有用戶線程（即STW），但是時(shí)間較短；并發(fā)標(biāo)記與并發(fā)清理時(shí)間較長，但是不需要STW

關(guān)于并發(fā)標(biāo)記期間怎樣記錄發(fā)生變動的引用關(guān)系對象，在重新標(biāo)記期間怎樣掃描這些對象

缺點(diǎn)：

• 并發(fā)標(biāo)記與并發(fā)清理：按照說明的第二點(diǎn)來講，假設(shè)有2個(gè)CPU，那么其中有一個(gè)CPU會用于垃圾回收，而另一個(gè)用于用戶線程，這樣的話，之前是兩CPU運(yùn)行用戶線程，現(xiàn)在是一個(gè)，那么效率就會急劇下降。也就是說，降低了吞吐量（即降低了CPU使用率）。
• 并發(fā)清理：在這一過程中，產(chǎn)生的垃圾無法被清理（因?yàn)榘l(fā)生在重新標(biāo)記之后）
• 并發(fā)標(biāo)記與并發(fā)清理：由于是與用戶線程并發(fā)的，所以用戶線程可能會分配對象，這樣既可能對象直接進(jìn)入年老代（例如，大對象），也可能進(jìn)入年輕代后，年輕代發(fā)生minor GC，這樣的話，實(shí)際上要求我們的年老代需要預(yù)留一定空間，也就是說要在年老代還有一定空間的情況下就要進(jìn)行垃圾回收，留出一定內(nèi)存空間來供其他線程使用，而不能等到年老代快爆滿了才進(jìn)行垃圾回收，通過-XX:CMSInitiatingOccupancyFraction來指定當(dāng)年老代空間滿了多少后進(jìn)行垃圾回收
• 標(biāo)記-清理算法：會產(chǎn)生內(nèi)存碎片，由于是在老年代，可能會提前觸發(fā)Full GC（這正是我們要盡量減少的）

參數(shù)設(shè)置：

• -XX:+UseConcMarkSweepGC：使用該GC組合
• -XX:CMSInitiatingOccupancyFraction：指定當(dāng)年老代空間滿了多少后進(jìn)行垃圾回收
• -XX:+UseCMSCompactAtFullCollection：（默認(rèn)是開啟的）在CMS收集器頂不住要進(jìn)行FullGC時(shí)開啟內(nèi)存碎片整理過程，該過程需要STW
• -XX:CMSFullGCsBeforeCompaction：指定多少次FullGC后才進(jìn)行整理
• -XX:ParallelCMSThreads：指定CMS回收線程的數(shù)量，默認(rèn)為：(CPU數(shù)量+3)/4

適用場合：

用于處理很多的交互任務(wù)的情況

方法區(qū)的回收一般使用CMS，配置兩個(gè)參數(shù)：-XX:+CMSPermGenSweepingEnabled與-XX:+CMSClassUnloadingEnabled

適用于一些需要長期運(yùn)行且對相應(yīng)時(shí)間有一定要求的后臺程序

(2.5)G1

說明：

• 從上圖來看，G1與CMS相比，僅在最后的"篩選回收"部分不同（CMS是并發(fā)清除），實(shí)際上G1回收器的整個(gè)堆內(nèi)存的劃分都與其他收集器不同。
• CMS需要配合ParNew，G1可單獨(dú)回收整個(gè)空間

原理：

• G1收集器將整個(gè)堆劃分為多個(gè)大小相等的Region
• G1跟蹤各個(gè)region里面的垃圾堆積的價(jià)值（回收后所獲得的空間大小以及回收所需時(shí)間長短的經(jīng)驗(yàn)值），在后臺維護(hù)一張優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先回收價(jià)值最大的region，這種思路：在指定的時(shí)間內(nèi)，掃描部分最有價(jià)值的region（而不是掃描整個(gè)堆內(nèi)存），并回收，做到盡可能的在有限的時(shí)間內(nèi)獲取盡可能高的收集效率。

運(yùn)作流程：

• 初始標(biāo)記：標(biāo)記出所有與根節(jié)點(diǎn)直接關(guān)聯(lián)引用對象。需要STW
• 并發(fā)標(biāo)記：遍歷之前標(biāo)記到的關(guān)聯(lián)節(jié)點(diǎn)，繼續(xù)向下標(biāo)記所有存活節(jié)點(diǎn)。在此期間所有變化引用關(guān)系的對象，都會被記錄在Remember Set Logs中
• 最終標(biāo)記：標(biāo)記在并發(fā)標(biāo)記期間，新產(chǎn)生的垃圾。需要STW
• 篩選回收：根據(jù)用戶指定的期望回收時(shí)間回收價(jià)值較大的對象（看"原理"第二條）。需要STW

優(yōu)點(diǎn)：

1. 停頓時(shí)間可以預(yù)測：我們指定時(shí)間，在指定時(shí)間內(nèi)只回收部分價(jià)值最大的空間，而CMS需要掃描整個(gè)年老代，無法預(yù)測停頓時(shí)間
2. 無內(nèi)存碎片：垃圾回收后會整合空間，CMS采用"標(biāo)記-清理"算法，存在內(nèi)存碎片
3. 篩選回收階段：

• 由于只回收部分region，所以STW時(shí)間我們可控，所以不需要與用戶線程并發(fā)爭搶CPU資源，而CMS并發(fā)清理需要占據(jù)一部分的CPU，會降低吞吐量。
• 由于STW，所以不會產(chǎn)生"浮動垃圾"（即CMS在并發(fā)清理階段產(chǎn)生的無法回收的垃圾）

適用范圍：

• 追求STW短：若ParNew/CMS用的挺好，就用這個(gè)；若不符合，用G1
• 追求吞吐量：用Parallel Scavenge/Parallel Old，而G1在吞吐量方面沒有優(yōu)勢

以上就是本文的全部內(nèi)容，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作能帶來一定的幫助，同時(shí)也希望多多支持腳本之家！

最新評論