简称
- STW —— Stop the World，暂停所有在执行的线程
简史
- 2004年Sun实验室第一次发表G1论文
- JDK6U14中第一次作为实验选项引入
- JDK7中开始作为替换CMS的方案
- JDK9中成为默认的垃圾回收器
- JDK10优化，将其fullGC改为并行： JEP307
- JDK11引入了更新的ZGC，可能会成为G1的潜在替代者
G1特有数据结构和算法
Region
堆仍然有新生代(eden、survivor)、老年代的划分，但是不再要求它们是内存连续的。每个区都由多个Region组成。
部分老年代Region存储Humongous对象(即下图的H)，这种对象大小大于等于Region的一半。
(图片来源-Java Hotspot G1 GC的一些关键技术)
SATB算法
全称Snapshot-At-The-Beginning，起始时活对象的快照。在理解SATB前需要先了解以下知识。
三色标记法
CMS和G1的算法都是通过对gc root 进行遍历，并进行三色标记。标记规则为
- 黑色(black): 节点被遍历完成，而且子节点都遍历完成。
- 灰色(gray): 当前正在遍历的节点，而且子节点（即对象的域）还没有遍历。遍历完所有子节点后，将成为黑色
- 白色(white): 还没有遍历到的节点，即灰色节点的子节点。扫描结束仍是白色时会被回收。
并发扫描时，对于白色有两种情况同时发生时，可能会漏标导致被误回收：
- 增加了被黑色引用的关系。
- 被灰色下应用，删除了到它的引用
具体执行过程：https://www.cnblogs.com/javaadu/p/10713956.html
按照R大的说法：CMS的incremental update设计使得它在remark阶段必须重新扫描所有线程栈和整个young gen作为root；G1的SATB设计在remark阶段则只需要扫描剩下的satb_mark_queue。
RSet
全称Remember Set，记录一个Region里的对象被哪些其他Region引用。
相对应地，有另一种辅助数据结构Collection Set（CSet），它记录了GC要收集的Region集合。GC时只需扫描CSet中各个Rset即可。
(Tips for Tuning the Garbage First Garbage Collector)
更详细的访问机制和回收过程这里不再展开，有兴趣可以参考后文引用文献。
Pause Prediction Model
暂停预测模型，G1根据它计算出的历史数据来预测本次收集需要选择的Region数量，从而尽量满足用户设定的目标停顿时间。
具体算法和公式略，可见Java Hotspot G1 GC的一些关键技术
垃圾回收过程
分为以下几步：
- 初始标记（Initial Mark）—— 标记GC root能直接关联的对象（短暂STW）
- 并发标记（Concurrent mark）—— GCRootsTracing，从并发标记中的root遍历，对不可达的对象进行标记，耗时长但可并行
- 最终标记（Final Remark）—— 收集并发标记期间产生的新垃圾（短暂STW）,采用了SATB算法比CMS更快
- 筛选回收（Live Data Counting and Evacuation）—— 对各个Region的回收性价比排序，在保证时间可控的情况下清除失活对象，清除Remember Sets
作为对比，CMS的回收过程
- 初始标记（CMS Initial Mark）—— 标记GC root能直接关联的对象（短暂STW）
- 并发标记（CMS Concurrent Mark）—— GCRootsTracing，从并发标记中的root遍历，对不可达的对象进行标记
- 重新标记（CMS Remark）—— 修正并发标记期间因为用户操作导致标记发生变更的对象，有STW
- 并发清除（CMS Concurrent Sweep）
与CMS相比的优势
- 并发度更高，充分利用CPU多线程 —— CMS对CPU资源敏感，需要占用25%的线程，如果核数小于4更会占用一半的资源。
- 整体上是标记-整理(分代)，局部是复制(分Region)，运行期不产生碎片 —— CMS是标记-清除，会产生空间碎片和本次回收期间产生导致本次无法回收的浮动垃圾
- 可预测的停顿(基于Region)
参考资料
- 周志明.著 《深入理解Java虚拟机》
2.Java Hotspot G1 GC的一些关键技术
3.CMS和G1的回收过程 - 可能是最全面的G1学习笔记
5.G1 SATB和Incremental Update算法的理解