G1垃圾收集器并非橫空出世，早在JDK1.7的時候就已經存在了。随着後續的優化，終于在JDK1.9的時候被Oracle付以重任，替換CMS成為預設的垃圾收集器。
G1相較于CMS的顯著特點是，減少了空間碎片。CMS的空間碎片很嚴重，Mark-Sweep之後的空間，有很多小碎片，但是都比要配置設定的小，然後觸發一次Full GC，讓人崩潰。
一、啥是G1垃圾收集器
Garbage-First（G1，垃圾優先）收集器是服務類型的收集器，目标是多處理器機器、大記憶體機器。它高度符合垃圾收集暫停時間的目标，同時實作高吞吐量。Oracle JDK 7 update 4 以及更新釋出版完全支援G1垃圾收集器。G1垃圾回集器為以下應用設計：
- 類似CMS收集器，可以和應用線程同時并發的執行
- 壓縮空閑空間時沒有GC引起的暫停時間
- 需要更可預言的GC暫停時間
- 不想犧牲大量的吞吐量性能
- 不需要特别大的Java堆
G1垃圾收集器計劃長期替換并發标記清除收集器（CMS，Concurrent Mark-Sweep Collector）。G1和CMS比較，有一些不同點讓G1成為一個更好的解決方案。一個不同點是G1是一個壓縮收集器。G1收集器充分地壓縮空間以完全避免配置設定空間使用細粒度的空閑清單，而不是依賴于區塊。這相當簡化了收集器的部件，和盡量消除可能的碎片問題。同時，G1收集器相比CMS收集器而方言，提供更可預言的垃圾收集暫停時間，允許使用者指定想要暫停時間名額。
二、G1如何進行垃圾收集
老的垃圾收集器都把堆結構化為三個部分：年輕代、年老代和永久代（或中繼資料區）。 G1則采用了新的結構，堆空間被分割成一些相同大小的堆區域，每一個都是連續範圍的虛拟記憶體。特定的區域集合像舊的收集器一樣被指派為相同的角色（伊甸：eden、幸存：survivor、年老：old），但是它們沒有一個固定大小。這在記憶體使用上提供了更強大的靈活性。
當執行垃圾收集時，G1收集器以與CMS收集器類似的方式操作。G1收集器執行一個全局的并發标記階段來決定堆中的對象的活躍度。之後标記階段就完成了。G1收集器知道哪個區域基本上是空的。它首先會收集那些産出大量空閑空間的區域。這就是為什麼這個垃圾收集的方法叫做垃圾優先的原因。就像名稱顯示的那樣，G1收集器集中它的收集和壓縮活動在堆裡的那些可完全被回收的區域，那就是垃圾。G1收集器使用一個暫停預言的模式去達到一個使用者定義的暫停時間名額，基于使用者指定的暫停時間名額去選擇收集區域的數量。
被G1收集器鑒定為可以回收的區域就是垃圾，使用抽空的方式收集。G1收集器從堆空間的一個或多個區域裡複制對象到堆空間的一個單獨的區域内，這個過程中同時壓縮和釋放記憶體。這個抽空過程在多處理上以并行的方式運作，以減小暫停時間和增加吞吐量。是以，每一次垃圾收集G1收集器連續不斷地去減少碎片，在使用者指定的暫停時間内工作。這超越了以往方法的能力。并發标記-清除（CMS，Concurrent Mark Sweep）垃圾收集器不做壓縮操作。并行年老代（ParallelOld）垃圾收集隻進行整個堆的壓縮，會導緻相當大的暫停時間。
注意： G1收集器不是實時的收集器非常重要。它在很大程度上符合使用者設定的暫停時間名額但是并不絕對符合。基于前面垃圾收集的資料來看，G1收集器會估算在使用者指定的時間名額能收集多少區域。是以，收集器有一個合理的精确的收集這些區域的代價模型，它使用這個模型決定在使用者指定的暫停時間内收集哪些、多少個區域。
三、适合G1垃圾收集的場景
G1收集器首要關注的是為使用者運作着需要大堆空間、限制的垃圾回收延遲的應用提供一個解決方案。這意味着堆大小為6GB左右或者更大，穩定的、可預言的暫停時間小于0.5秒。
如果應用有以下一個或多個特點，當下運作着CMS或ParallelOldGC垃圾收集器的應用把收集器切換到G1收集器的話，會從中受益的：
- Full GC持續時間太長或者太頻繁
- 對象配置設定比率或者提升有顯著的變化
- 不期望的長時間垃圾收集或者壓縮暫停（大于0.5到1秒）
現實項目中，大家可以根據實際情況具體選擇。