【大厂突击】七、全面的 G1 学习资料

背景

在 G1 收集器之前 CMS 算的上是一款优秀的收集器，它主要的优点有：并发收集、低停顿等。但是它的缺点也很明显比如：

CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4
CMS收集器无法处理浮动垃圾，由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自然会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，称为“浮动垃圾”，CMS 无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。
由于垃圾收集阶段会产生“浮动垃圾”，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以参数 -XX:CMSInitiatingOccupancyFraction 设置的过高将会很容易导致 “Concurrent Mode Failure” 失败，性能反而降低。
CMS是基于“标记-清除”算法实现的收集器，会产生大量不连续的内存碎片。当老年代空间碎片太多时，如果无法找到一块足够大的连续内存存放对象时，将不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。
JVM 设计团队为了规避这些缺点设计出了 G1 收集器取代 CMS 收集器

G1 和 CMS 对比

G1 特点

在G1的实现过程中，引入了一些新的概念，对于实现高吞吐、没有内存碎片、收集时间可控等功能起到了关键作用。与其他收集器相比它有以下几个特点：

并行与并发，G1 能够充分利用多 CPU 、来缩短 STW 的时间
分代收集，G1 保留了分代的概念，并且 G1 可以不需要其他收集器配合就能够独立管理这个 GC 堆
空间整合，G1 收集器是大体上是基于【标记-整理】算法实现的收集器，但是两个 Region 之间上来看是基于 【复制】算法来实现的。这两种算法都不会再内存产生内存空间碎片。
可预测停顿时间，这也是 G1 的一大优势，G1 除了追求低停顿之外还建立了可预测时间模型。

各个概念

G1 分区

G1之前的垃圾收集器都会将堆分成三个部分，新生代（Young Generation）、老年代（Old Generation）和永久代（Permanent Generation），根据不同的分区类型，采用不同的策略进行回收。如下所示：

而G1的各代存储地址是不连续的，每一代都使用了n个不连续的大小相同的Region，每个Region占有一块连续的虚拟内存地址。G1把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以作为新生代的Eden空间、Survivor空间，或者老年代空间。G1堆和操作系统交互的最小管理单位称为分区（Heap Region，HR）或称堆分区如下图所示：

G1的分区类型（HeapRegionType）大致可以分为四类：

• 自由分区（Free Heap Region，FHR）
• 新生代分区（Young Heap Regio