這篇文章是我之前翻閱了不少的書籍以及從網(wǎng)絡(luò)上收集的一些資料的整理，因此不免有一些不準(zhǔn)確的地方，同時(shí)不同JDK版本的差異也比較大。

5.垃圾回收

5.1 按代實(shí)現(xiàn)垃圾回收

image.png

新生代（Young generation）:

絕大多數(shù)最新被創(chuàng)建的對(duì)象會(huì)被分配到這里，由于大部分對(duì)象在創(chuàng)建后會(huì)很快變得不可到達(dá)，所以很多對(duì)象被創(chuàng)建在新生代，然后消失。對(duì)象從這個(gè)區(qū)域消失的過程我們稱之為”minor GC“。

新生代中存在一個(gè)Eden區(qū)和兩個(gè)Survivor區(qū)。新對(duì)象會(huì)首先分配在 Eden 中(如果新對(duì)象過大，會(huì)直接分配在老年代中)。在GC中，Eden 中的對(duì)象會(huì)被移動(dòng)到survivor中，直至對(duì)象滿足一定的年紀(jì)(定義為熬過GC的次數(shù)),會(huì)被移動(dòng)到老年代（具體細(xì)節(jié)將在下邊垃圾收集算法中討論）。

可以設(shè)置新生代和老年代的相對(duì)大小。這種方式的優(yōu)點(diǎn)是新生代大小會(huì)隨著整個(gè)堆大小動(dòng)態(tài)擴(kuò)展。參數(shù) -XX:NewRatio 設(shè)置老年代與新生代的比例。例如 -XX:NewRatio=8 指定老年代/新生代為8/1. 老年代占堆大小的 7/8 ，新生代占 1/8 .(默認(rèn)即使1/8)
例如：-XX:NewSize=64m -XX:MaxNewSize=1024m -XX:NewRatio=8

老年代（Old generation）:

對(duì)象沒有變得不可達(dá)，并且從新生代中存活下來，會(huì)被拷貝到這里。其所占用的空間要比新生代多。也正由于其相對(duì)較大的空間，發(fā)生在老年代上的GC要比新生代少得多。對(duì)象從老年代中消失的過程，可以稱之為”major GC“（或者”full GC“）

永久代（permanent generation）:

像一些類的層級(jí)信息，方法數(shù)據(jù)和方法信息（如字節(jié)碼，棧和變量大小），運(yùn)行時(shí)常量池（jdk7之后移出永久代），已確定的符號(hào)引用和虛方法表等等，它們幾乎都是靜態(tài)的并且很少被卸載和回收，在JDK8之前的HotSpot虛擬機(jī)中，類的這些“永久的”數(shù)據(jù)存放在一個(gè)叫做永久代的區(qū)域。永久代一段連續(xù)的內(nèi)存空間，我們?cè)贘VM啟動(dòng)之前可以通過設(shè)置-XX:MaxPermSize的值來控制永久代的大小。但是jdk8之后取消了永久代，這些元數(shù)據(jù)被移到了一個(gè)與堆不相連的本地內(nèi)存區(qū)域 。

5.2 怎樣判斷對(duì)象是否已經(jīng)死亡

引用計(jì)數(shù)收集算法

用計(jì)數(shù)是垃圾收集器中的早期策略。在這種方法中，堆中每個(gè)對(duì)象（不是引用）都有一個(gè)引用計(jì)數(shù)。當(dāng)一個(gè)對(duì)象被創(chuàng)建時(shí)，且將該對(duì)象分配給一個(gè)變量，該變量計(jì)數(shù)設(shè)置為1。當(dāng)任何其它變量被賦值為這個(gè)對(duì)象的引用時(shí)，計(jì)數(shù)加1（a = b,則b引用的對(duì)象+1），但當(dāng)一個(gè)對(duì)象的某個(gè)引用超過了生命周期或者被設(shè)置為一個(gè)新值時(shí)，對(duì)象的引用計(jì)數(shù)減1。任何引用計(jì)數(shù)為0的對(duì)象可以被當(dāng)作垃圾收集。當(dāng)一個(gè)對(duì)象被垃圾收集時(shí)，它引用的任何對(duì)象計(jì)數(shù)減1。

• 優(yōu)點(diǎn)：引用計(jì)數(shù)收集器可以很快的執(zhí)行，交織在程序運(yùn)行中。對(duì)程序不被長時(shí)間打斷的實(shí)時(shí)環(huán)境比較有利。
• 缺點(diǎn)： 無法檢測(cè)出循環(huán)引用。如父對(duì)象有一個(gè)對(duì)子對(duì)象的引用，子對(duì)象反過來引用父對(duì)象。這樣，他們的引用計(jì)數(shù)永遠(yuǎn)不可能為0.

可達(dá)性分析算法

通過一系列稱為”GC Roots”的對(duì)象作為起點(diǎn)，從這些節(jié)點(diǎn)開始向下搜索，搜索所有走過的路徑稱為引用鏈，當(dāng)一個(gè)對(duì)象到GC Roots沒有任何引用鏈相連時(shí)(從GC Roots到此對(duì)象不可達(dá))，則證明此對(duì)象是不可用的。
可作為GC Roots的對(duì)象包括：

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

5.3 java中的引用

強(qiáng)引用(Strong Reference):

在代碼中普遍存在的，類似”O(jiān)bject obj = new Object”這類引用，只要強(qiáng)引用還在，垃圾收集器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象

軟引用(Sofe Reference):

有用但并非必須的對(duì)象，可用SoftReference類來實(shí)現(xiàn)軟引用，在系統(tǒng)將要發(fā)生內(nèi)存溢出異常之前，將會(huì)把這些對(duì)象列進(jìn)回收范圍之中進(jìn)行二次回收。如果這次回收還沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存異常異常。

弱引用(Weak Reference):

被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾收集發(fā)生之前，JDK提供了WeakReference類來實(shí)現(xiàn)弱引用。

虛引用(Phantom Reference):

也稱為幽靈引用或幻影引用，是最弱的一種引用關(guān)系，JDK提供了PhantomReference類來實(shí)現(xiàn)虛引用。

5.4 finalize方法什么作用

對(duì)于一個(gè)對(duì)象來說，在被判斷沒有 GCroots 與其相關(guān)聯(lián)時(shí)，被第一次標(biāo)記，然后判斷該對(duì)象是否應(yīng)該執(zhí)行finalize方法（判斷依據(jù)：如果對(duì)象的finalize方法被復(fù)寫，并且沒有執(zhí)行過，則可以被執(zhí)行）。如果允許執(zhí)行那么這個(gè)對(duì)象將會(huì)被放到一個(gè)叫F-Query的隊(duì)列中，等待被執(zhí)行。（注意：由于finalize的優(yōu)先級(jí)比較低，所以該對(duì)象的的finalize方法不一定被執(zhí)行，即使被執(zhí)行了，也不保證finalize方法一定會(huì)執(zhí)行完）

5.5 垃圾收集算法

標(biāo)記-清除算法：

標(biāo)記-清除算法采用從根集合進(jìn)行掃描，對(duì)存活的對(duì)象進(jìn)行標(biāo)記，標(biāo)記完畢后，再掃描整個(gè)空間中未被標(biāo)記的對(duì)象，進(jìn)行回收。標(biāo)記-清除算法不需要進(jìn)行對(duì)象的移動(dòng)，并且僅對(duì)不存活的對(duì)象進(jìn)行處理，在存活對(duì)象比較多的情況下極為高效，但由于標(biāo)記-清除算法直接回收不存活的對(duì)象，因此會(huì)造成內(nèi)存碎片。

復(fù)制算法：

這種收集算法將堆棧分為兩個(gè)域，常稱為半空間。每次僅使用一半的空間，JVM生成的新對(duì)象則放在另一半空間中。GC運(yùn)行時(shí)，它把可到達(dá)對(duì)象復(fù)制到另一半空間，從而壓縮了堆棧。這種方法適用于短生存期的對(duì)象，持續(xù)復(fù)制長生存期的對(duì)象則導(dǎo)致效率降低。并且對(duì)于指定大小堆來說，需要兩倍大小的內(nèi)存，因?yàn)槿魏螘r(shí)候都只使用其中的一半。

標(biāo)記整理算法：

標(biāo)記-整理算法采用標(biāo)記-清除算法一樣的方式進(jìn)行對(duì)象的標(biāo)記，但在清除時(shí)不同，在回收不存活的對(duì)象占用的空間后，會(huì)將所有的存活對(duì)象往一端空閑空間移動(dòng)，并更新對(duì)應(yīng)的指針。標(biāo)記-整理算法是在標(biāo)記-清除算法的基礎(chǔ)上，又進(jìn)行了對(duì)象的移動(dòng)，因此成本更高，但是卻解決了內(nèi)存碎片的問題。

分代收集算法：

在上邊三種收集思想中加入了分代的思想。

5.6 Hotspot實(shí)現(xiàn)垃圾回收細(xì)節(jié)

一致性：

在可達(dá)性分析期間整個(gè)系統(tǒng)看起來就像被凍結(jié)在某個(gè)時(shí)間點(diǎn)上，不可以出現(xiàn)分析過程中對(duì)象引用關(guān)系還在不斷變化的情況。

一致性要求導(dǎo)致GC進(jìn)行時(shí)必須停頓所有Java執(zhí)行線程。（Stop The World）即使在號(hào)稱不會(huì)發(fā)生停頓的CMS收集器中，枚舉根節(jié)點(diǎn)時(shí)也是必須停頓的。

HotSpot使用的是準(zhǔn)確式GC，當(dāng)執(zhí)行系統(tǒng)停頓下來后，并不需要一個(gè)不漏地檢查完所有執(zhí)行上下文和全局的引用位置，這是通過一組稱為OopMap的數(shù)據(jù)結(jié)構(gòu)來達(dá)到的。

安全點(diǎn)（Safe Point）：

程序只有在到達(dá)安全點(diǎn)時(shí)才能暫停。安全點(diǎn)的選定標(biāo)準(zhǔn)是“是否具有讓程序長時(shí)間執(zhí)行的特征”?！伴L時(shí)間執(zhí)行”的最明顯特征就是指令序列的復(fù)用，如方法調(diào)用、循環(huán)跳轉(zhuǎn)等，具有這些功能的指令才會(huì)產(chǎn)生安全點(diǎn)。

讓程序暫停的兩種方式：

* 搶先式中斷（Preemptive Suspension）：在GC發(fā)生時(shí)，主動(dòng)中斷所有線程，不需要線程執(zhí)行的代碼主動(dòng)配合。如果發(fā)現(xiàn)有線程中斷的地方不在安全點(diǎn)上，就恢復(fù)線程讓它跑到安全點(diǎn)上。（不推薦）
* 主動(dòng)式中斷（Voluntary Suspension）：設(shè)一個(gè)標(biāo)志，各個(gè)線程主動(dòng)去輪詢這個(gè)標(biāo)志，遇到中斷則暫停。輪詢地方與安全點(diǎn)重合。

5.7 垃圾收集器

HotSpot中幾種常見的垃圾收集器：

image.png

5.7.1 Serial收集器

Serial收集器是最基本、發(fā)展歷史最悠久的收集器，曾經(jīng)（在JDK 1.3.1之前）是虛擬機(jī)新生代收集的唯一選擇。

image.png

特性：

這個(gè)收集器是一個(gè)單線程的收集器，但它的“單線程”的意義并不僅僅說明它只會(huì)使用一個(gè)CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進(jìn)行垃圾收集時(shí)，必須暫停其他所有的工作線程，直到它收集結(jié)束。Stop The World

應(yīng)用場(chǎng)景：

Serial收集器是虛擬機(jī)運(yùn)行在Client模式下的默認(rèn)新生代收集器。

優(yōu)勢(shì)：

簡(jiǎn)單而高效（與其他收集器的單線程比），對(duì)于限定單個(gè)CPU的環(huán)境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。

5.7.2 ParNew收集器

image.png

特性：

ParNew收集器其實(shí)就是Serial收集器的多線程版本，除了使用多條線程進(jìn)行垃圾收集之外，其余行為包括Serial收集器可用的所有控制參數(shù)、收集算法、Stop The World、對(duì)象分配規(guī)則、回收策略等都與Serial收集器完全一樣，在實(shí)現(xiàn)上，這兩種收集器也共用了相當(dāng)多的代碼。

應(yīng)用場(chǎng)景：

ParNew收集器是許多運(yùn)行在Server模式下的虛擬機(jī)中首選的新生代收集器。有一個(gè)很重要的原因是除了Serial收集器外，目前只有它能與CMS收集器配合工作。

Serial收集器 VS ParNew收集器：

ParNew收集器在單CPU的環(huán)境中絕對(duì)不會(huì)有比Serial收集器更好的效果，甚至由于存在線程交互的開銷，該收集器在通過超線程技術(shù)實(shí)現(xiàn)的兩個(gè)CPU的環(huán)境中都不能百分之百地保證可以超越Serial收集器。然而，隨著可以使用的CPU的數(shù)量的增加，它對(duì)于GC時(shí)系統(tǒng)資源的有效利用還是很有好處的。

5.7.3 Parallel Scavenge收集器

特性：

Parallel Scavenge收集器是一個(gè)新生代收集器，它也是使用復(fù)制算法的收集器，又是并行的多線程收集器。

應(yīng)用場(chǎng)景：

停頓時(shí)間越短就越適合需要與用戶交互的程序，良好的響應(yīng)速度能提升用戶體驗(yàn)，而高吞吐量則可以高效率地利用CPU時(shí)間，盡快完成程序的運(yùn)算任務(wù)，主要適合在后臺(tái)運(yùn)算而不需要太多交互的任務(wù)。

對(duì)比分析：

Parallel Scavenge收集器 VS CMS等收集器：

Parallel Scavenge收集器的特點(diǎn)是它的關(guān)注點(diǎn)與其他收集器不同，CMS等收集器的關(guān) 注點(diǎn)是盡可能地縮短垃圾收集時(shí)用戶線程的停頓時(shí)間，而Parallel Scavenge收集器的目標(biāo)則是達(dá)到一個(gè)可控制的吞吐量（Throughput）。

由于與吞吐量關(guān)系密切，Parallel Scavenge收集器也經(jīng)常稱為“吞吐量?jī)?yōu)先”收集器。

Parallel Scavenge收集器 VS ParNew收集器：

Parallel Scavenge收集器與ParNew收集器的一個(gè)重要區(qū)別是它具有自適應(yīng)調(diào)節(jié)策略。

GC自適應(yīng)的調(diào)節(jié)策略：

Parallel Scavenge收集器有一個(gè)參數(shù)-XX:+UseAdaptiveSizePolicy。當(dāng)這個(gè)參數(shù)打開之后，就不需要手工指定新生代的大小、Eden與Survivor區(qū)的比例、晉升老年代對(duì)象年齡等細(xì)節(jié)參數(shù)了，虛擬機(jī)會(huì)根據(jù)當(dāng)前系統(tǒng)的運(yùn)行情況收集性能監(jiān)控信息，動(dòng)態(tài)調(diào)整這些參數(shù)以提供最合適的停頓時(shí)間或者最大的吞吐量，這種調(diào)節(jié)方式稱為GC自適應(yīng)的調(diào)節(jié)策略（GC Ergonomics）。

5.7.4 Serial Old收集器

image.png

特性：

Serial Old是Serial收集器的老年代版本，它同樣是一個(gè)單線程收集器，使用標(biāo)記－整理算法。

應(yīng)用場(chǎng)景：

• Client模式：Serial Old收集器的主要意義也是在于給Client模式下的虛擬機(jī)使用。
• Server模式：如果在Server模式下，那么它主要還有兩大用途：一種用途是在JDK 1.5以及之前的版本中與Parallel Scavenge收集器搭配使用，另一種用途就是作為CMS收集器的后備預(yù)案，在并發(fā)收集發(fā)生Concurrent Mode Failure時(shí)使用。

5.7.5 Parallel Old收集器

image.png

特性：

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標(biāo)記－整理”算法。

應(yīng)用場(chǎng)景：

在注重吞吐量以及CPU資源敏感的場(chǎng)合，都可以優(yōu)先考慮Parallel Scavenge加Parallel Old收集器。

這個(gè)收集器是在JDK 1.6中才開始提供的，在此之前，新生代的Parallel Scavenge收集器一直處于比較尷尬的狀態(tài)。原因是，如果新生代選擇了Parallel Scavenge收集器，老年代除了Serial Old收集器外別無選擇（Parallel Scavenge收集器無法與CMS收集器配合工作）。由于老年代Serial Old收集器在服務(wù)端應(yīng)用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整體應(yīng)用上獲得吞吐量最大化的效果，由于單線程的老年代收集中無法充分利用服務(wù)器多CPU的處理能力，在老年代很大而且硬件比較高級(jí)的環(huán)境中，這種組合的吞吐量甚至還不一定有ParNew加CMS的組合“給力”。直到Parallel Old收集器出現(xiàn)后，“吞吐量?jī)?yōu)先”收集器終于有了比較名副其實(shí)的應(yīng)用組合。

5.7.6 CMS收集器

image.png

特性：

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時(shí)間為目標(biāo)的收集器。目前很大一部分的Java應(yīng)用集中在互聯(lián)網(wǎng)站或者B/S系統(tǒng)的服務(wù)端上，這類應(yīng)用尤其重視服務(wù)的響應(yīng)速度，希望系統(tǒng)停頓時(shí)間最短，以給用戶帶來較好的體驗(yàn)。CMS收集器就非常符合這類應(yīng)用的需求。
CMS收集器是基于“標(biāo)記—清除”算法實(shí)現(xiàn)的，它的運(yùn)作過程相對(duì)于前面幾種收集器來說更復(fù)雜一些，整個(gè)過程分為4個(gè)步驟：

• 初始標(biāo)記（CMS initial mark）：初始標(biāo)記僅僅只是標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對(duì)象，速度很快，需要“Stop The World”。
• 并發(fā)標(biāo)記（CMS concurrent mark）：并發(fā)標(biāo)記階段就是進(jìn)行GC Roots Tracing的過程。
• 重新標(biāo)記（CMS remark）：重新標(biāo)記階段是為了修正并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，這個(gè)階段的停頓時(shí)間一般會(huì)比初始標(biāo)記階段稍長一些，但遠(yuǎn)比并發(fā)標(biāo)記的時(shí)間短，仍然需要“Stop The World”。
• 并發(fā)清除（CMS concurrent sweep）：并發(fā)清除階段會(huì)清除對(duì)象。

由于整個(gè)過程中耗時(shí)最長的并發(fā)標(biāo)記和并發(fā)清除過程收集器線程都可以與用戶線程一起工作，所以，從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的。

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

CMS是一款優(yōu)秀的收集器，它的主要優(yōu)點(diǎn)在名字上已經(jīng)體現(xiàn)出來了：并發(fā)收集、低停頓。

缺點(diǎn)：

• 1）CMS收集器對(duì)CPU資源非常敏感

  其實(shí)，面向并發(fā)設(shè)計(jì)的程序都對(duì)CPU資源比較敏感。在并發(fā)階段，它雖然不會(huì)導(dǎo)致用戶線程停頓，但是會(huì)因?yàn)檎加昧艘徊糠志€程（或者說CPU資源）而導(dǎo)致應(yīng)用程序變慢，總吞吐量會(huì)降低。

  CMS默認(rèn)啟動(dòng)的回收線程數(shù)是（CPU數(shù)量+3）/ 4，也就是當(dāng)CPU在4個(gè)以上時(shí)，并發(fā)回收時(shí)垃圾收集線程不少于25%的CPU資源，并且隨著CPU數(shù)量的增加而下降。但是當(dāng)CPU不足4個(gè)（譬如2個(gè)）時(shí)，CMS對(duì)用戶程序的影響就可能變得很大。

• 2）CMS收集器無法處理浮動(dòng)垃圾

  CMS收集器無法處理浮動(dòng)垃圾，可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。

  由于CMS并發(fā)清理階段用戶線程還在運(yùn)行著，伴隨程序運(yùn)行自然就還會(huì)有新的垃圾不斷產(chǎn)生，這一部分垃圾出現(xiàn)在標(biāo)記過程之后，CMS無法在當(dāng)次收集中處理掉它們，只好留待下一次GC時(shí)再清理掉。這一部分垃圾就稱為“浮動(dòng)垃圾”。

  也是由于在垃圾收集階段用戶線程還需要運(yùn)行，那也就還需要預(yù)留有足夠的內(nèi)存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進(jìn)行收集，需要預(yù)留一部分空間提供并發(fā)收集時(shí)的程序運(yùn)作使用。要是CMS運(yùn)行期間預(yù)留的內(nèi)存無法滿足程序需要，就會(huì)出現(xiàn)一次“Concurrent Mode Failure”失敗，這時(shí)虛擬機(jī)將啟動(dòng)后備預(yù)案：臨時(shí)啟用Serial Old收集器來重新進(jìn)行老年代的垃圾收集，這樣停頓時(shí)間就很長了。

• 3）CMS收集器會(huì)產(chǎn)生大量空間碎片

  CMS是一款基于“標(biāo)記—清除”算法實(shí)現(xiàn)的收集器，這意味著收集結(jié)束時(shí)會(huì)有大量空間碎片產(chǎn)生?？臻g碎片過多時(shí)，將會(huì)給大對(duì)象分配帶來很大麻煩，往往會(huì)出現(xiàn)老年代還有很大空間剩余，但是無法找到足夠大的連續(xù)空間來分配當(dāng)前對(duì)象，不得不提前觸發(fā)一次Full GC。

5.7.7 G1收集器

image.png

特性：

G1（Garbage-First）是一款面向服務(wù)端應(yīng)用的垃圾收集器。HotSpot開發(fā)團(tuán)隊(duì)賦予它的使命是未來可以替換掉JDK 1.5中發(fā)布的CMS收集器。與其他GC收集器相比，G1具備如下特點(diǎn)。

• 1)并行與并發(fā)

  G1能充分利用多CPU、多核環(huán)境下的硬件優(yōu)勢(shì)，使用多個(gè)CPU來縮短Stop-The-World停頓的時(shí)間，部分其他收集器原本需要停頓Java線程執(zhí)行的GC動(dòng)作，G1收集器仍然可以通過并發(fā)的方式讓Java程序繼續(xù)執(zhí)行。

• 2)分代收集

  與其他收集器一樣，分代概念在G1中依然得以保留。雖然G1可以不需要其他收集器配合就能獨(dú)立管理整個(gè)GC堆，但它能夠采用不同的方式去處理新創(chuàng)建的對(duì)象和已經(jīng)存活了一段時(shí)間、熬過多次GC的舊對(duì)象以獲取更好的收集效果。

• 3)空間整合

  與CMS的“標(biāo)記—清理”算法不同，G1從整體來看是基于“標(biāo)記—整理”算法實(shí)現(xiàn)的收集器，從局部（兩個(gè)Region之間）上來看是基于“復(fù)制”算法實(shí)現(xiàn)的，但無論如何，這兩種算法都意味著G1運(yùn)作期間不會(huì)產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整的可用內(nèi)存。這種特性有利于程序長時(shí)間運(yùn)行，分配大對(duì)象時(shí)不會(huì)因?yàn)闊o法找到連續(xù)內(nèi)存空間而提前觸發(fā)下一次GC。

• 4)可預(yù)測(cè)的停頓

  這是G1相對(duì)于CMS的另一大優(yōu)勢(shì)，降低停頓時(shí)間是G1和CMS共同的關(guān)注點(diǎn)，但G1除了追求低停頓外，還能建立可預(yù)測(cè)的停頓時(shí)間模型，能讓使用者明確指定在一個(gè)長度為M毫秒的時(shí)間片段內(nèi)，消耗在垃圾收集上的時(shí)間不得超過N毫秒。

在G1之前的其他收集器進(jìn)行收集的范圍都是整個(gè)新生代或者老年代，而G1不再是這樣。使用G1收集器時(shí)，Java堆的內(nèi)存布局就與其他收集器有很大差別，它將整個(gè)Java堆劃分為多個(gè)大小相等的獨(dú)立區(qū)域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region（不需要連續(xù)）的集合。

G1收集器之所以能建立可預(yù)測(cè)的停頓時(shí)間模型，是因?yàn)樗梢杂杏?jì)劃地避免在整個(gè)Java堆中進(jìn)行全區(qū)域的垃圾收集。G1跟蹤各個(gè)Region里面的垃圾堆積的價(jià)值大?。ɑ厥账@得的空間大小以及回收所需時(shí)間的經(jīng)驗(yàn)值），在后臺(tái)維護(hù)一個(gè)優(yōu)先列表，每次根據(jù)允許的收集時(shí)間，優(yōu)先回收價(jià)值最大的Region（這也就是Garbage-First名稱的來由）。這種使用Region劃分內(nèi)存空間以及有優(yōu)先級(jí)的區(qū)域回收方式，保證了G1收集器在有限的時(shí)間內(nèi)可以獲取盡可能高的收集效率。

執(zhí)行過程：

G1收集器的運(yùn)作大致可劃分為以下幾個(gè)步驟：

• 1）初始標(biāo)記（Initial Marking）：初始標(biāo)記階段僅僅只是標(biāo)記一下GC Roots能直接關(guān)聯(lián)到的對(duì)象，并且修改TAMS（Next Top at Mark Start）的值，讓下一階段用戶程序并發(fā)運(yùn)行時(shí)，能在正確可用的Region中創(chuàng)建新對(duì)象，這階段需要停頓線程，但耗時(shí)很短。
• 2）并發(fā)標(biāo)記（Concurrent Marking）：并發(fā)標(biāo)記階段是從GC Root開始對(duì)堆中對(duì)象進(jìn)行可達(dá)性分析，找出存活的對(duì)象，這階段耗時(shí)較長，但可與用戶程序并發(fā)執(zhí)行。
• 3）最終標(biāo)記（Final Marking）：最終標(biāo)記階段是為了修正在并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分標(biāo)記記錄，虛擬機(jī)將這段時(shí)間對(duì)象變化記錄在線程Remembered Set Logs里面，最終標(biāo)記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這階段需要停頓線程，但是可并行執(zhí)行。
• 4）篩選回收（Live Data Counting and Evacuation）：篩選回收階段首先對(duì)各個(gè)Region的回收價(jià)值和成本進(jìn)行排序，根據(jù)用戶所期望的GC停頓時(shí)間來制定回收計(jì)劃，這個(gè)階段其實(shí)也可以做到與用戶程序一起并發(fā)執(zhí)行，但是因?yàn)橹换厥找徊糠諶egion，時(shí)間是用戶可控制的，而且停頓用戶線程將大幅提高收集效率。

何時(shí)會(huì)拋出OutOfMemoryException，并不是內(nèi)存被耗空的時(shí)候才拋出
    * JVM98%的時(shí)間都花費(fèi)在內(nèi)存回收
    * 每次回收的內(nèi)存小于2%

最詳細(xì)的JVM&GC講解

個(gè)人介紹：

高廣超 ：多年一線互聯(lián)網(wǎng)研發(fā)與架構(gòu)設(shè)計(jì)經(jīng)驗(yàn)，擅長設(shè)計(jì)與落地高可用、高性能互聯(lián)網(wǎng)架構(gòu)。

本文首發(fā)在 http://www.itdecent.cn/u/2766e4cfc391)轉(zhuǎn)載請(qǐng)注明！