【jvm jdk】G1垃圾收集器详解

什么是G1垃圾收集器

GC收集器的三个考量指标：

• 占用的内存（Capacity）
• 延迟（Latency）
• 吞吐量（Throughput）

随着硬件的成本越来越低，机器的内存也越来越大，GC收集器占用的内存基本上可以容忍。而吞吐量可以通过集群（增加机器）来解决。

随着JVM中内存的增大，STW的时间成为JVM急迫解决的问题，如果还是按照传统的分代模型，使用传统的垃圾收集器，那么STW的时间将会越来越长。

在传统的垃圾收集器中，STW的时间是无法预测的，有没有一种办法，能够首先定义一个停顿时间，然后反向推算收集内容呢？就像是领导在年初制定KPI一样，分配的任务多就多干些，分配的任务少就少干点。

cms垃圾收集器也是尽量减少停顿时间，但是无法设置具体的停顿时间。

G1的思路说起来也类似，它不要求每次都把垃圾清理的干干净净，它只是努力做它认为对的事情。

我们要求G1，在任意1秒的时间内，停顿不得超过10ms，这就是在给它制定KPI。G1会尽量达成这个目标，它能够反向推算出本次要收集的大体区域，以增量的方式完成收集。

这也是使用G1垃圾回收器（-XX:+UseG1GC）不得不设置的一个参数：-XX:MaxGCPauseMillis=10。

G1的堆内存划分

为了实现STW的时间可预测，首先要有一个思想上的改变。G1将堆内存“化整为零”，将堆内存划分成多个大小相等独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

Region可能是Eden，也有可能是Survivor，也有可能是Old，另外Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX:G1HeapRegionSize设定，取值范围为1MB~32MB，且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的进行回收大多数情况下都把Humongous Region作为老年代的一部分来进行看待。

G1在逻辑上还是划分Eden、Survivor、OLd，但是物理上他们不是连续的。

G1的运行过程

G1的运行过程与CMS大体一致，分为以下四个步骤：

• 初始标记(Initial Marking)：仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际并没有额外的停顿。
• 并发标记( Concurrent Marking)：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫
  描完成以后，并发时有引用变动的对象会产生漏标问题，G1中会使用SATB(snapshot-at-the-beginning)算法来解决，后面会详细介绍。
• 最终标记(Final Marking)：对用户线程做一个短暂的暂停，用于处理并发标记阶段仍遗留下来的最后那少量的SATB记录(漏标对象)。
• 筛选回收(Live Data Counting and Evacuation)：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多个收集器线程并行完成的。

TAMS是什么？要达到GC与用户线程并发运行，必须要解决回收过程中新对象的分配，所以G1为每一个Region区域设计了两个名为TAMS（Top at Mark Start）的指针，从Region区域划出一部分空间用于记录并发回收过程中的新对象。这样的对象认为它们是存活的，不纳入垃圾回收范围。

参考

G1垃圾收集器详解
G1从入门到放弃（一）