在《Java虛擬機垃圾回收(一) 基礎》中了解到如何判斷對象是存活還是已經(jīng)死亡对蒲？在《Java虛擬機垃圾回收(二) 垃圾回收算法》了解到Java虛擬機垃圾回收的幾種常見算法。
下面先來了解HotSpot虛擬機中的7種垃圾收集器：Serial、ParNew室琢、Parallel Scavenge诡必、Serial Old喷屋、Parallel Old舟铜、CMS辜伟、G1菊霜，先介紹一些垃圾收集的相關概念坚冀，再介紹它們的主要特點、應用場景鉴逞、以及一些設置參數(shù)和基本運行原理记某。
1、垃圾收集器概述
垃圾收集器是垃圾回收算法（標記-清除算法构捡、復制算法液南、標記-整理算法、火車算法）的具體實現(xiàn)勾徽，不同商家滑凉、不同版本的JVM所提供的垃圾收集器可能會有很在差別，本文主要介紹HotSpot虛擬機中的垃圾收集器喘帚。
1-1畅姊、垃圾收集器組合
JDK7/8后，HotSpot虛擬機所有收集器及組合（連線）吹由，如下圖：
（A）若未、圖中展示了7種不同分代的收集器：
Serial、ParNew倾鲫、Parallel Scavenge粗合、Serial Old、Parallel Old级乍、CMS舌劳、G1；（B）玫荣、而它們所處區(qū)域甚淡，則表明其是屬于新生代收集器還是老年代收集器：
新生代收集器：Serial、ParNew捅厂、Parallel Scavenge贯卦； 老年代收集器：Serial Old、Parallel Old焙贷、CMS撵割； 整堆收集器：G1；（C）辙芍、兩個收集器間有連線啡彬，表明它們可以搭配使用：
Serial/Serial Old羹与、Serial/CMS、ParNew/Serial Old庶灿、ParNew/CMS纵搁、Parallel Scavenge/Serial Old、Parallel Scavenge/Parallel Old往踢、G1腾誉；（D）、其中Serial Old作為CMS出現(xiàn)"Concurrent Mode Failure"失敗的后備預案（后面介紹）峻呕；
1-2利职、并發(fā)垃圾收集和并行垃圾收集的區(qū)別
（A）、并行（Parallel）
指多條垃圾收集線程并行工作瘦癌，但此時用戶線程仍然處于等待狀態(tài)猪贪； 如ParNew、Parallel Scavenge佩憾、Parallel Old哮伟；（B）、并發(fā)（Concurrent）
指用戶線程與垃圾收集線程同時執(zhí)行（但不一定是并行的妄帘，可能會交替執(zhí)行）楞黄； 用戶程序在繼續(xù)運行，而垃圾收集程序線程運行于另一個CPU上抡驼； 如CMS鬼廓、G1（也有并行）；
1-3致盟、Minor GC和Full GC的區(qū)別
（A）碎税、Minor GC
又稱新生代GC，指發(fā)生在新生代的垃圾收集動作馏锡； 因為Java對象大多是朝生夕滅雷蹂，所以Minor GC非常頻繁，一般回收速度也比較快杯道；（B）匪煌、Full GC
又稱Major GC或老年代GC，指發(fā)生在老年代的GC党巾； 出現(xiàn)Full GC經(jīng)常會伴隨至少一次的Minor GC（不是絕對萎庭，Parallel Sacvenge收集器就可以選擇設置Major GC策略）； Major GC速度一般比Minor GC慢10倍以上齿拂；
下面將介紹這些收集器的特性驳规、基本原理和使用場景，并重點分析CMS和G1這兩款相對復雜的收集器署海；但需要明確一個觀點：
沒有最好的收集器吗购，更沒有萬能的收集医男； 選擇的只能是適合具體應用場景的收集器。
2巩搏、Serial收集器
Serial（串行）垃圾收集器是最基本昨登、發(fā)展歷史最悠久的收集器趾代；
JDK1.3.1前是HotSpot新生代收集的唯一選擇贯底；1、特點
針對新生代撒强； 采用復制算法禽捆； 單線程收集； 進行垃圾收集時飘哨，必須暫停所有工作線程胚想，直到完成； 即會"Stop The World"芽隆； Serial/Serial Old組合收集器運行示意圖如下：
2浊服、應用場景
依然是HotSpot在Client模式下默認的新生代收集器； 也有優(yōu)于其他收集器的地方：簡單高效（與其他收集器的單線程相比）胚吁；
對于限定單個CPU的環(huán)境來說牙躺，Serial收集器沒有線程交互（切換）開銷，可以獲得最高的單線程收集效率腕扶； 在用戶的桌面應用場景中孽拷，可用內(nèi)存一般不大（幾十M至一兩百M），可以在較短時間內(nèi)完成垃圾收集（幾十MS至一百多MS）,只要不頻繁發(fā)生半抱，這是可以接受的3脓恕、設置參數(shù)
"-XX:+UseSerialGC"：添加該參數(shù)來顯式的使用串行垃圾收集器；4窿侈、Stop TheWorld說明
JVM在后臺自動發(fā)起和自動完成的炼幔，在用戶不可見的情況下首繁，把用戶正常的工作線程全部停掉卷胯，即GC停頓； 會帶給用戶不良的體驗核畴；從JDK1.3到現(xiàn)在乘瓤，從Serial收集器-》Parallel收集器-》CMS-》G1环形，用戶線程停頓時間不斷縮短，但仍然無法完全消除衙傀；
更多"Stop The World"信息請參考：[《Java虛擬機垃圾回收(一) 基礎》](http://blog.csdn.net/tjiyu/article/details/53982412)"2-2抬吟、可達性分析算法"更多Serial收集器請參考：
《Memory Management in the Java HotSpot? Virtual Machine》 4.3節(jié) Serial Collector（內(nèi)存管理白皮書）：[http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf](http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf) 《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第5節(jié) Available Collectors（官方的垃圾收集調(diào)優(yōu)指南）：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref27](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthref27)
3、ParNew收集器
ParNew垃圾收集器是Serial收集器的多線程版本统抬。
1火本、特點
除了多線程外危队，其余的行為、特點和Serial收集器一樣钙畔； 如Serial收集器可用控制參數(shù)茫陆、收集算法、Stop The World擎析、內(nèi)存分配規(guī)則簿盅、回收策略等； 兩個收集器共用了不少代碼揍魂； ParNew/Serial Old組合收集器運行示意圖如下：
2桨醋、應用場景
在Server模式下，ParNew收集器是一個非常重要的收集器现斋，因為除Serial外喜最，目前只有它能與CMS收集器配合工作； 但在單個CPU環(huán)境中庄蹋，不會比Serail收集器有更好的效果瞬内，因為存在線程交互開銷。3限书、設置參數(shù)
"-XX:+UseConcMarkSweepGC"：指定使用CMS后虫蝶，會默認使用ParNew作為新生代收集器； "-XX:+UseParNewGC"：強制指定使用ParNew蔗包； "-XX:ParallelGCThreads"：指定垃圾收集的線程數(shù)量秉扑，ParNew默認開啟的收集線程與CPU的數(shù)量相同；4调限、為什么只有ParNew能與CMS收集器配合
CMS是HotSpot在JDK1.5推出的第一款真正意義上的并發(fā)（Concurrent）收集器舟陆，第一次實現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時工作； CMS作為老年代收集器耻矮，但卻無法與JDK1.4已經(jīng)存在的新生代收集器Parallel Scavenge配合工作秦躯； 因為Parallel Scavenge（以及G1）都沒有使用傳統(tǒng)的GC收集器代碼框架，而另外獨立實現(xiàn)裆装；而其余幾種收集器則共用了部分的框架代碼踱承； 關于CMS收集器后面會詳細介紹。
4哨免、Parallel Scavenge收集器
Parallel Scavenge垃圾收集器因為與吞吐量關系密切茎活，也稱為吞吐量收集器（Throughput Collector）。
1琢唾、特點
（A）载荔、有一些特點與ParNew收集器相似
新生代收集器； 采用復制算法采桃； 多線程收集懒熙；（B）丘损、主要特點是：它的關注點與其他收集器不同
CMS等收集器的關注點是盡可能地縮短垃圾收集時用戶線程的停頓時間； 而Parallel Scavenge收集器的目標則是達一個可控制的吞吐量（Throughput）工扎； 關于吞吐量與收集器關注點說明詳見本節(jié)后面徘钥；
2、應用場景
高吞吐量為目標肢娘，即減少垃圾收集時間呈础，讓用戶代碼獲得更長的運行時間； 當應用程序運行在具有多個CPU上蔬浙，對暫停時間沒有特別高的要求時猪落，即程序主要在后臺進行計算，而不需要與用戶進行太多交互畴博； 例如，那些執(zhí)行批量處理蓝仲、訂單處理俱病、工資支付、科學計算的應用程序袱结；3亮隙、設置參數(shù)
Parallel Scavenge收集器提供兩個參數(shù)用于精確控制吞吐量：（A）、"-XX:MaxGCPauseMillis"
控制最大垃圾收集停頓時間垢夹，大于0的毫秒數(shù)溢吻； MaxGCPauseMillis設置得稍小，停頓時間可能會縮短果元，但也可能會使得吞吐量下降促王； 因為可能導致垃圾收集發(fā)生得更頻繁；（B）而晒、"-XX:GCTimeRatio"
設置垃圾收集時間占總時間的比率蝇狼，0<n<100的整數(shù)； GCTimeRatio相當于設置吞吐量大谐酢迅耘； 垃圾收集執(zhí)行時間占應用程序執(zhí)行時間的比例的計算方法是：1 / (1 + n)
例如，選項-XX:GCTimeRatio=19监署，設置了垃圾收集時間占總時間的5%--1/(1+19)颤专；默認值是1%--1/(1+99)，即n=99钠乏；
垃圾收集所花費的時間是年輕一代和老年代收集的總時間栖秕；
如果沒有滿足吞吐量目標，則增加代的內(nèi)存大小以盡量增加用戶程序運行的時間缓熟；
此外累魔，還有一個值得關注的參數(shù)：
（C）摔笤、"-XX:+UseAdptiveSizePolicy"
開啟這個參數(shù)后，就不用手工指定一些細節(jié)參數(shù)垦写，如：新生代的大新朗馈（-Xmn）、Eden與Survivor區(qū)的比例（-XX:SurvivorRation）梯投、晉升老年代的對象年齡（-XX:PretenureSizeThreshold）等命辖；
JVM會根據(jù)當前系統(tǒng)運行情況收集性能監(jiān)控信息，動態(tài)調(diào)整這些參數(shù)分蓖，以提供最合適的停頓時間或最大的吞吐量尔艇，這種調(diào)節(jié)方式稱為GC自適應的調(diào)節(jié)策略（GC Ergonomiscs）；
這是一種值得推薦的方式：
(1)么鹤、只需設置好內(nèi)存數(shù)據(jù)大兄胀蕖（如"-Xmx"設置最大堆）；
(2)蒸甜、然后使用"-XX:MaxGCPauseMillis"或"-XX:GCTimeRatio"給JVM設置一個優(yōu)化目標棠耕； (3)、那些具體細節(jié)參數(shù)的調(diào)節(jié)就由JVM自適應完成柠新；這也是Parallel Scavenge收集器與ParNew收集器一個重要區(qū)別窍荧；更多目標調(diào)優(yōu)和GC自適應的調(diào)節(jié)策略說明請參考：
《Memory Management in the Java HotSpot? Virtual Machine》 5節(jié) Ergonomics -- Automatic Selections and Behavior Tuning：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》 第2節(jié) Ergonomics：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ergonomics.html#ergonomics](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/ergonomics.html%23ergonomics)
4、吞吐量與收集器關注點說明
（A）恨憎、吞吐量（Throughput）
CPU用于運行用戶代碼的時間與CPU總消耗時間的比值蕊退； 即吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間）； 高吞吐量即減少垃圾收集時間憔恳，讓用戶代碼獲得更長的運行時間瓤荔；（B）、垃圾收集器期望的目標（關注點）
（1）喇嘱、停頓時間
停頓時間越短就適合需要與用戶交互的程序茉贡； 良好的響應速度能提升用戶體驗；（2）者铜、吞吐量
高吞吐量則可以高效率地利用CPU時間腔丧，盡快完成運算的任務； 主要適合在后臺計算而不需要太多交互的任務作烟；（3）愉粤、覆蓋區(qū)（Footprint）
在達到前面兩個目標的情況下，盡量減少堆的內(nèi)存空間拿撩； 可以獲得更好的空間局部性衣厘；更多Parallel Scavenge收集器的信息請參考：
官方的垃圾收集調(diào)優(yōu)指南 第6節(jié)：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html#parallel_collector](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/parallel.html%23parallel_collector)
5影暴、Serial Old收集器
Serial Old是 Serial收集器的老年代版本错邦；
1、特點
針對老年代型宙； 采用"標記-整理"算法（還有壓縮撬呢，Mark-Sweep-Compact）； 單線程收集妆兑； Serial/Serial Old收集器運行示意圖如下：
2魂拦、應用場景
主要用于Client模式； 而在Server模式有兩大用途：（A）搁嗓、在JDK1.5及之前芯勘，與Parallel Scavenge收集器搭配使用（JDK1.6有Parallel Old收集器可搭配）；
（B）腺逛、作為CMS收集器的后備預案荷愕，在并發(fā)收集發(fā)生Concurrent Mode Failure時使用（后面詳解）；更多Serial Old收集器信息請參考：
內(nèi)存管理白皮書 4.3.2節(jié)：[http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf](http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf)
6屉来、Parallel Old收集器
Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本路翻；
JDK1.6中才開始提供；1茄靠、特點
針對老年代； 采用"標記-整理"算法蝶桶； 多線程收集慨绳； Parallel Scavenge/Parallel Old收集器運行示意圖如下：
2、應用場景
JDK1.6及之后用來代替老年代的Serial Old收集器真竖； 特別是在Server模式脐雪，多CPU的情況下； 這樣在注重吞吐量以及CPU資源敏感的場景恢共，就有了Parallel Scavenge加Parallel Old收集器的"給力"應用組合战秋；3、設置參數(shù)
"-XX:+UseParallelOldGC"：指定使用Parallel Old收集器讨韭；更多Parallel Old收集器收集過程介紹請參考：
《內(nèi)存管理白皮書》 4.5.2節(jié)： [ http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf](http://blog.csdn.net/tjiyu/article/details/53983650)
7脂信、CMS收集器
并發(fā)標記清理（Concurrent Mark Sweep，CMS）收集器也稱為并發(fā)低停頓收集器（Concurrent Low Pause Collector）或低延遲（low-latency）垃圾收集器透硝；
在前面ParNew收集器曾簡單介紹過其特點狰闪；1、特點
針對老年代濒生； 基于"標記-清除"算法(不進行壓縮操作埋泵，產(chǎn)生內(nèi)存碎片)； 以獲取最短回收停頓時間為目標； 并發(fā)收集丽声、低停頓礁蔗； 需要更多的內(nèi)存（看后面的缺點）； 是HotSpot在JDK1.5推出的第一款真正意義上的并發(fā)（Concurrent）收集器雁社； 第一次實現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時工作浴井；2、應用場景
與用戶交互較多的場景歧胁； 希望系統(tǒng)停頓時間最短滋饲，注重服務的響應速度； 以給用戶帶來較好的體驗喊巍； 如常見WEB屠缭、B/S系統(tǒng)的服務器上的應用；
3崭参、設置參數(shù)
"-XX:+UseConcMarkSweepGC"：指定使用CMS收集器呵曹；4、CMS收集器運作過程
比前面幾種收集器更復雜何暮，可以分為4個步驟:
（A）奄喂、初始標記（CMS initial mark）
僅標記一下GC Roots能直接關聯(lián)到的對象； 速度很快海洼； 但需要"Stop The World"跨新；（B）、并發(fā)標記（CMS concurrent mark）
進行GC Roots Tracing的過程坏逢； 剛才產(chǎn)生的集合中標記出存活對象域帐； 應用程序也在運行； 并不能保證可以標記出所有的存活對象是整；（C）肖揣、重新標記（CMS remark）
為了修正并發(fā)標記期間因用戶程序繼續(xù)運作而導致標記變動的那一部分對象的標記記錄； 需要"Stop The World"浮入，且停頓時間比初始標記稍長龙优，但遠比并發(fā)標記短； 采用多線程并行執(zhí)行來提升效率事秀；（D）彤断、并發(fā)清除（CMS concurrent sweep）
回收所有的垃圾對象；
整個過程中耗時最長的并發(fā)標記和并發(fā)清除都可以與用戶線程一起工作秽晚；
所以總體上說瓦糟，CMS收集器的內(nèi)存回收過程與用戶線程一起并發(fā)執(zhí)行； CMS收集器運行示意圖如下：
5赴蝇、CMS收集器3個明顯的缺點
（A）菩浙、對CPU資源非常敏感
并發(fā)收集雖然不會暫停用戶線程，但因為占用一部分CPU資源，還是會導致應用程序變慢劲蜻，總吞吐量降低陆淀。
CMS的默認收集線程數(shù)量是=(CPU數(shù)量+3)/4； 當CPU數(shù)量多于4個先嬉，收集線程占用的CPU資源多于25%轧苫，對用戶程序影響可能較大；不足4個時疫蔓，影響更大含懊，可能無法接受。 增量式并發(fā)收集器：針對這種情況衅胀，曾出現(xiàn)了"增量式并發(fā)收集器"（Incremental Concurrent Mark Sweep/i-CMS）岔乔；
類似使用搶占式來模擬多任務機制的思想，讓收集線程和用戶線程交替運行滚躯，減少收集線程運行時間雏门； 但效果并不理想，JDK1.6后就官方不再提倡用戶使用掸掏。更多請參考：
官方的《垃圾收集調(diào)優(yōu)指南》8.8節(jié) Incremental Mode：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#CJAGIIEJ](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html%23CJAGIIEJ) 《內(nèi)存管理白皮書》 4.6.3節(jié)可以看到一些描述茁影；
（B）、無法處理浮動垃圾,可能出現(xiàn)"Concurrent Mode Failure"失敗
（1）丧凤、浮動垃圾（Floating Garbage）
在并發(fā)清除時募闲，用戶線程新產(chǎn)生的垃圾，稱為浮動垃圾愿待； 這使得并發(fā)清除時需要預留一定的內(nèi)存空間蝇更，不能像其他收集器在老年代幾乎填滿再進行收集； 也要可以認為CMS所需要的空間比其他垃圾收集器大呼盆； "-XX:CMSInitiatingOccupancyFraction"：設置CMS預留內(nèi)存空間； JDK1.5默認值為68%蚁廓； JDK1.6變?yōu)榇蠹s92%访圃；
（2）、"Concurrent Mode Failure"失敗
如果CMS預留內(nèi)存空間無法滿足程序需要相嵌，就會出現(xiàn)一次"Concurrent Mode Failure"失斖仁薄； 這時JVM啟用后備預案：臨時啟用Serail Old收集器饭宾，而導致另一次Full GC的產(chǎn)生批糟； 這樣的代價是很大的，所以CMSInitiatingOccupancyFraction不能設置得太大看铆。
（C）徽鼎、產(chǎn)生大量內(nèi)存碎片
由于CMS基于"標記-清除"算法，清除后不進行壓縮操作； 前面[《Java虛擬機垃圾回收(二) 垃圾回收算法》](http://blog.csdn.net/tjiyu/article/details/53983064)"標記-清除"算法介紹時曾說過：產(chǎn)生大量不連續(xù)的內(nèi)存碎片會導致分配大內(nèi)存對象時否淤，無法找到足夠的連續(xù)內(nèi)存悄但，從而需要提前觸發(fā)另一次Full GC動作。
解決方法：（1）石抡、"-XX:+UseCMSCompactAtFullCollection"
使得CMS出現(xiàn)上面這種情況時不進行Full GC檐嚣，而開啟內(nèi)存碎片的合并整理過程； 但合并整理過程無法并發(fā)啰扛，停頓時間會變長嚎京； 默認開啟（但不會進行，結合下面的CMSFullGCsBeforeCompaction）隐解；（2）鞍帝、"-XX:+CMSFullGCsBeforeCompaction"
設置執(zhí)行多少次不壓縮的Full GC后，來一次壓縮整理厢漩； 為減少合并整理過程的停頓時間膜眠； 默認為0，也就是說每次都執(zhí)行Full GC溜嗜，不會進行壓縮整理宵膨；
由于空間不再連續(xù)，CMS需要使用可用"空閑列表"內(nèi)存分配方式炸宵，這比簡單實用"碰撞指針"分配內(nèi)存消耗大辟躏；
更多關于內(nèi)存分配方式請參考：《[Java對象在Java虛擬機中的創(chuàng)建過程](http://blog.csdn.net/tjiyu/article/details/53923392)》總體來看，與Parallel Old垃圾收集器相比土全，CMS減少了執(zhí)行老年代垃圾收集時應用暫停的時間捎琐； 但卻增加了新生代垃圾收集時應用暫停的時間、降低了吞吐量而且需要占用更大的堆空間裹匙；
更多CMS收集器信息請參考：
《垃圾收集調(diào)優(yōu)指南》 8節(jié) Concurrent Mark Sweep (CMS) Collector：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html#concurrent_mark_sweep_cms_collector](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/cms.html%23concurrent_mark_sweep_cms_collector) 《內(nèi)存管理白皮書》 4.6節(jié) Concurrent Mark-Sweep (CMS) Collector：[http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf](http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf)
8瑞凑、G1收集器
G1（Garbage-First）是JDK7-u4才推出商用的收集器；
1概页、特點
（A）籽御、并行與并發(fā)
能充分利用多CPU、多核環(huán)境下的硬件優(yōu)勢惰匙； 可以并行來縮短"Stop The World"停頓時間技掏； 也可以并發(fā)讓垃圾收集與用戶程序同時進行；（B）项鬼、分代收集哑梳，收集范圍包括新生代和老年代
能獨立管理整個GC堆（新生代和老年代），而不需要與其他收集器搭配绘盟； 能夠采用不同方式處理不同時期的對象鸠真； 雖然保留分代概念悯仙，但Java堆的內(nèi)存布局有很大差別； 將整個堆劃分為多個大小相等的獨立區(qū)域（Region）弧哎； 新生代和老年代不再是物理隔離雁比，它們都是一部分Region（不需要連續(xù)）的集合； 更多G1內(nèi)存布局信息請參考：《垃圾收集調(diào)優(yōu)指南》 9節(jié)：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection
（C）撤嫩、結合多種垃圾收集算法偎捎，空間整合，不產(chǎn)生碎片
從整體看序攘，是基于標記-整理算法茴她； 從局部（兩個Region間）看，是基于復制算法程奠； 這是一種類似火車算法的實現(xiàn)丈牢； 都不會產(chǎn)生內(nèi)存碎片，有利于長時間運行瞄沙；（D）己沛、可預測的停頓：低停頓的同時實現(xiàn)高吞吐量
G1除了追求低停頓處，還能建立可預測的停頓時間模型距境； 可以明確指定M毫秒時間片內(nèi)申尼，垃圾收集消耗的時間不超過N毫秒；
2垫桂、應用場景
面向服務端應用师幕，針對具有大內(nèi)存、多處理器的機器诬滩； 最主要的應用是為需要低GC延遲霹粥，并具有大堆的應用程序提供解決方案； 如：在堆大小約6GB或更大時疼鸟，可預測的暫停時間可以低于0.5秒后控； 用來替換掉JDK1.5中的CMS收集器； 在下面的情況時空镜，使用G1可能比CMS好：（1）忆蚀、超過50％的Java堆被活動數(shù)據(jù)占用；
（2）姑裂、對象分配頻率或年代提升頻率變化很大； （3）男旗、GC停頓時間過長（長于0.5至1秒）舶斧。
是否一定采用G1呢？也未必：
如果現(xiàn)在采用的收集器沒有出現(xiàn)問題察皇，不用急著去選擇G1茴厉；
如果應用程序追求低停頓泽台，可以嘗試選擇G1； 是否代替CMS需要實際場景測試才知道矾缓。
3怀酷、設置參數(shù)
"-XX:+UseG1GC"：指定使用G1收集器； "-XX:InitiatingHeapOccupancyPercent"：當整個Java堆的占用率達到參數(shù)值時嗜闻，開始并發(fā)標記階段蜕依；默認為45； "-XX:MaxGCPauseMillis"：為G1設置暫停時間目標琉雳，默認值為200毫秒样眠； "-XX:G1HeapRegionSize"：設置每個Region大小，范圍1MB到32MB翠肘；目標是在最小Java堆時可以擁有約2048個Region檐束； 更多關于G1參數(shù)設置請參考：《垃圾收集調(diào)優(yōu)指南》 10.5節(jié)：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#important_defaults
4、為什么G1收集器可以實現(xiàn)可預測的停頓
G1可以建立可預測的停頓時間模型束倍，是因為：
可以有計劃地避免在Java堆的進行全區(qū)域的垃圾收集被丧；
G1跟蹤各個Region獲得其收集價值大小，在后臺維護一個優(yōu)先列表绪妹； 每次根據(jù)允許的收集時間甥桂，優(yōu)先回收價值最大的Region（名稱Garbage-First的由來）； 這就保證了在有限的時間內(nèi)可以獲取盡可能高的收集效率喂急；
5格嘁、一個對象被不同區(qū)域引用的問題
一個Region不可能是孤立的，一個Region中的對象可能被其他任意Region中對象引用廊移，判斷對象存活時糕簿，是否需要掃描整個Java堆才能保證準確？ 在其他的分代收集器狡孔，也存在這樣的問題（而G1更突出）：回收新生代也不得不同時掃描老年代懂诗？
這樣的話會降低Minor GC的效率； 解決方法：
無論G1還是其他分代收集器苗膝，JVM都是使用Remembered Set來避免全局掃描：
每個Region都有一個對應的Remembered Set殃恒；
每次Reference類型數(shù)據(jù)寫操作時，都會產(chǎn)生一個Write Barrier暫時中斷操作辱揭； 然后檢查將要寫入的引用指向的對象是否和該Reference類型數(shù)據(jù)在不同的Region（其他收集器：檢查老年代對象是否引用了新生代對象）离唐； 如果不同，通過CardTable把相關引用信息記錄到引用指向?qū)ο蟮乃赗egion對應的Remembered Set中问窃；當進行垃圾收集時亥鬓，在GC根節(jié)點的枚舉范圍加入Remembered Set；
就可以保證不進行全局掃描域庇，也不會有遺漏嵌戈。
6覆积、G1收集器運作過程
不計算維護Remembered Set的操作，可以分為4個步驟（與CMS較為相似）熟呛。
（A）宽档、初始標記（Initial Marking）
僅標記一下GC Roots能直接關聯(lián)到的對象； 且修改TAMS（Next Top at Mark Start）,讓下一階段并發(fā)運行時庵朝，用戶程序能在正確可用的Region中創(chuàng)建新對象吗冤； 需要"Stop The World"，但速度很快偿短；（B）欣孤、并發(fā)標記（Concurrent Marking）
進行GC Roots Tracing的過程； 剛才產(chǎn)生的集合中標記出存活對象昔逗； 耗時較長降传，但應用程序也在運行； 并不能保證可以標記出所有的存活對象勾怒；（C）婆排、最終標記（Final Marking）
為了修正并發(fā)標記期間因用戶程序繼續(xù)運作而導致標記變動的那一部分對象的標記記錄； 上一階段對象的變化記錄在線程的Remembered Set Log笔链； 這里把Remembered Set Log合并到Remembered Set中段只； 需要"Stop The World"，且停頓時間比初始標記稍長鉴扫，但遠比并發(fā)標記短赞枕； 采用多線程并行執(zhí)行來提升效率；（D）坪创、篩選回收（Live Data Counting and Evacuation）
首先排序各個Region的回收價值和成本炕婶； 然后根據(jù)用戶期望的GC停頓時間來制定回收計劃； 最后按計劃回收一些價值高的Region中垃圾對象莱预； 回收時采用"復制"算法柠掂，從一個或多個Region復制存活對象到堆上的另一個空的Region，并且在此過程中壓縮和釋放內(nèi)存依沮； 可以并發(fā)進行涯贞，降低停頓時間，并增加吞吐量危喉；
G1收集器運行示意圖如下：
更多G1收集器信息請參考：
《垃圾收集調(diào)優(yōu)指南》 9節(jié) Garbage-First Garbage Collector：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html#garbage_first_garbage_collection](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc.html%23garbage_first_garbage_collection) 《垃圾收集調(diào)優(yōu)指南》 10節(jié) Garbage-First Garbage Collector Tuning：[http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html#g1_gc_tuning](http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/g1_gc_tuning.html%23g1_gc_tuning)
到這里宋渔，我們大體了解HotSpot虛擬機中的所有垃圾收集器，后面我們將去了解JVM的一些內(nèi)存分配與回收策略辜限、JVM垃圾收集相關調(diào)優(yōu)方法……
【參考資料】
1傻谁、《編譯原理》第二版 第7章
2、《深入理解Java虛擬機：JVM高級特性與最佳實踐》第二版 第3章
3列粪、《The Java Virtual Machine Specification》Java SE 8 Edition：https://docs.oracle.com/javase/specs/jvms/se8/html/index.html
4审磁、《Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide》：http://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/index.html
5、《Memory Management in the Java HotSpot? Virtual Machine》：http://www.oracle.com/technetwork/java/javase/tech/memorymanagement-whitepaper-1-150020.pdf
6岂座、HotSpot虛擬機參數(shù)官方說明：http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
7态蒂、《Thinking in Java》第四版 5.5 清理：終結處理和垃圾回收；
