Garbage First收集器

Garbage First收集器

• G1是JDK9及以上版本中服务器端模式下的默认垃圾收集器

• G1可以面向堆内存任何部分来组成回收集（Collection Set）进行回收，衡量标准不再是踏属于哪个分代，而是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1的Mixed GC模式

• G1把堆分成多个大小相等的独立区域（Region），每个Region根据需要扮演Eden、Survivor、老年代空间。每个Region的大小可以通过-XX:G1HeapRegionSize设定，范围是1MB-32MB，且为2的N次幂

• Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一般的对象即可判定为大对象。对于超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1大多数行为都把Humongous Region作为老年代的一部分看待

• G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间（默认200毫秒）优先处理回收价值收益最大的那些Region

• G1至少要耗费大约相当于Java堆容量10%~20%的额外内存来维持收集器工作

• G1在整体上采用标记-整理算法，在Region之间采用标记-复制算法，所以G1运作期间不会产生内存空间碎片。

• 跨Region引用对象问题

  • 每个Region都维护有自己的记忆集，这些记忆集会记录下别的Region指向自己的指针，并标记这些指针分别在哪些卡片的范围之内。

  • G1记忆集在存储结构上本质是一种哈希表，Key是别的Region的起始地址，Value是一个集合，里面存储的元素是卡表的索引号

• 并发标记阶段的实现

  • G1通过原始快照算法（SATB）解决用户线程改变对象引用时，不打破原本对象图结构的问题

  • G1为每个Region设计了两个名为TAMS（Top at Mark Start）的指针，把Region中的一部分空间划分出来用于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置上。G1收集器默认在这个地址以上的对象是被隐式标记过的，即默认他们是存活的，不纳入回收范围内。

  • 如果内存回收的速度赶不上内存分配的速度，G1收集器也要被迫冻结用户线程执行，导致Full GC而产生长时间的“STOP THE WORLD”

• 建立可靠的停顿预测模型问题

  • G1收集器的停顿预测模型是以衰减均值为理论基础实现的，在垃圾收集过程中，G1收集器会记录每个Region的回收耗时，每个Region记忆集里的脏卡数量等各个可测量的步骤花费的成本，并分析得出平均值、标准偏差、置信度等统计信息。

  • 衰减平均值会比普通的平均值更容易受到新数据的影响。Region的统计状态越新越能决定其回收的价值。

G1收集器的收集过程

• 初始标记：仅仅标记GC Roots能直接关联到的对象，并且修改TAMS指针的值。让下一阶段并发标记过程中，用户线程可以正确的在可用的Region中分配新对象。这个过程需要停顿线程，但是耗时很短，而且是借用Minor GC的时候同步完成的。

• 并发标记：从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆中的对象图，找出要回收的对象，耗时较长，和用户进程并发执行。

• 最终标记：对用户线程做一个短暂的暂停，用于处理并发阶段结束后遗留下来的最后那少量的SATB记录

• 筛选回收：更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。必须暂停用户线程，由多条收集线程并行完成

标签：Garbage,G1,收集器,对象,Region,回收,线程,First
来源： https://www.cnblogs.com/clcoding/p/15205159.html