G1垃圾回收器

记忆集与卡表

记忆集

在老年代中，可能会存在跨代引用的对象，如果又去对老年代再去扫描效率太低，JVM 在新生代维护了一小块空间，老年代对年轻代所有对象的引用，扫描年轻代的时候，还会扫描这个集合中的对象。

image-20210922092113722

卡表

卡表是一个字节数组，且每一个元素都对应一个内存区域的特定大小的内存块，这个内存块就做卡页，卡页的内存包含着一个或多个对象，只要卡页有一个对象存在跨代指针，就标记对应卡表元素的值为 1，称之为脏的卡页，没有则标记为 0，发生 Minor GC 的时候我们直接在卡表中找到脏的，添加到 GC Roots 中扫描，就不必进行扫描整个老年代，扫描完之后就直接再标记卡表的元素为 0。

G1 垃圾回收器概述

G1 垃圾回收器

在 2012 年才在 JDK1.7u4 中可用，oracle 官方计划在 JDK9 中将 G1 变成默认的垃圾收集器，以替代 CMS，G1 是一个分代的，增量的，并行与并发的标记-复制垃圾回收器，它的设计目标是为了适应现在不断扩大的内存和不断增加的处理器数量，进一步降低暂停时间（pause time），同时兼顾良好的吞吐量，官方给 G1 设定的目标是在延迟可控的情况下获得尽可能高的吞吐量，G1 将 Java 堆划分为多个大小相等的独立区域（Region）每一次的回收，G1 会选择可能回收最多垃圾的 Region 进行回收，与此同时，G1 回收器会维护一个空间 Region 的链表。每次回收之后的 Region 都会被加入到这个链表中。

G1 垃圾回收器与 CMS 对比

回收方式

G1 垃圾回收器是压缩式的，因此其回收得到的空间是连续的，避免了 CMS 回收器因为不连续空间所造成的问题。连续空间意味着 G1 垃圾回收器可以不必采用空闲链表的内存分配方式，而可以直接采用指针碰撞的方式。

内存要求

G1 回收器的内存与 CMS 回收器要求的内存模型有极大的不同。G1 将内存划分一个个固定大小的 Region，每个 Region 可以是年轻代、老年代的一个。内存的回收是以 Region 作为基本单位的。

软实时（soft real-time）

所谓的实时垃圾回收，是指在要求的时间内完成垃圾回收。“软实时” 则是指，用户可以指定垃圾回收时间的限时，G1 会努力在这个时限内完成垃圾回收，但是 G1 并不担保每次都能在这个时限内完成垃圾回收。通过设定一个合理的目标，可以让达到 90% 以上的垃圾回收时间都在这个时限内。

Region 分区

Region

G1 将 Java 堆划分为多个大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分 Region(不需要连续）的集合。默认年轻代对堆内存的占比是 5%，如果堆大小为 4096M，那么年轻代占据 200MB 左右的内存，对应大概是 100 个 Region，可以通过 “-XX:G1NewSizePercent” 设置新生代初始占比，在系统运行中，JVM 会不停的给年轻代增加更多的 Region，但是最多新生代的占比不会超过 60%，可以通过 “-XX:G1MaxNewSizePercent” 调整。年轻代中的 Eden 和 Survivor 对应的 Region 也跟之前一样，默认 8:1:1。

Region 的变化

一个 Region 可能之前是年轻代，如果 Region 进行了垃圾回收，之后可能又会变成老年代，Region 的区域功能可能会动态变化。

回收优先列表

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region，一个 Region 花 200ms 能回收 10M 垃圾，另外一个 Region 花 50ms 能回收 20M 垃圾，在回收时间有限情况下，G1 当然会优先选择后面这个 Region 回收，使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率。

Region 大小

G1 将 Java 堆划分为多个大小相等的独立区域（Region），JVM 最多可以有 2048 个 Region。一般 Region 大小等于堆大小除以 2048，假设堆大小为 4096M，则 Region 大小为 2M，也可以用参数 "-XX:G1HeapRegionSize" 手动指定 Region 大小，但是推荐默认的计算方式。

Humongous 区

G1 有专门分配大对象的 Region 叫 Humongous 区，在 G1 中，大对象的判定规则就是一个大对象超过了一个 Region 大小的 50%，就会被放入 Humongous 中，一个大对象如果太大，可能会横跨多个 Region 来存放，Humongous 区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的 GC 开销，Full GC 的时候除了收集年轻代和老年代之外，也会将 Humongous 区一并回收。

分配内存过程

每一个分配的 Region，都可以分成两个部分，已分配的和未被分配的。它们之间的界限被称为 top，把一个对象分配到 Region 内，只需要简单增加 top 的值，也就是指针碰撞式的方式进行分配。

image-20210922095811691

Region 分区中的记忆集与卡表

在传统的分代垃圾回收算法里面，RS(Remember Set)，被用来记录分代之间的指针。在 G1 回收器里面，RS 被用来记录从其他 Region 指向一个 Region 的指针情况。一个 Region 就会有一个 RS，这种记录可以带来一个极大的好处，在回收一个 Region 的时候不需要执行全堆扫描，只需要检查它的 RS 就可以找到外部引用。

分区内部结构：

  • 每个分区内部又被分成了若干个大小为卡片(Card)
  • 标识堆内存最小可用粒度所有分区的卡片将会记录在全局卡片表(Global Card Table)中
  • 分配的对象会占用物理上连续的若干个卡片
  • 当查找对分区内对象的引用时便可通过记录卡片来查找该引用对象，通过 RSet 查找
  • 每次对内存的回收，都是对指定分区的卡片进行处理

如果一个线程修改了 Region 内部的引用，就必须要去通知 RS，更改其中的记录，使用卡表进行记录。

G1 垃圾收集环节

年轻代 YoungGC

YoungGC 并不是说现有的 Eden 区放满了就会马上触发，G1 会计算下现在 Eden 区回收大概要多久时间，如果回收时间远远小于参数 -XX:MaxGCPauseMills 设定的值，会增加年轻代的 Region，继续给新对象存放，不会马上做 YoungGC，直到下一次 Eden 区放满，会触发 Young GC。

老年代并发标记(Concurrent Marking)

当堆内存使用达到一定值（默认 45%) 时，开始老年代并发标记过程。标记完成马上开始混合回收过程。对于一个混合回收期。

混合回收(Mixed GC)

不是 Full GC，老年代的堆占有率达到参数(-XX:InitiatingHeapOccupancyPercent)设定的值则触发，回收所有的 Young 和部分 Old(根据期望的 GC 停顿时间确定 old 区垃圾收集的优先顺序)以及大对象区，正常情况 G1 的垃圾收集是先做 MixedGC，主要使用复制算法，需要把各个 Region 中存活的对象拷贝到别的 Region 里去，拷贝过程中如果发现没有足够的空 Region 能够承载拷贝对象就会触发一次 Full GC。

Full GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，空闲出来一批 Region 来供下一次 Mixed GC 使用，这个过程是非常耗时的。

G1 垃圾回收器运作过程

和 CMS 类似，G1 收集器收集老年代对象会有短暂停顿。

初始标记阶段

标记从根节点直接可达的对象。这个阶段是 STW 的，并且会触发一次年轻代 GC。

并发标记

和 CMS 并发标记一样，在整个堆中进行并发标记(和应用程序并发执行)，在并发标记阶段，若发现区域对象中的所有对象都是垃圾，那个这个区域会被立即回收，同时，并发标记过程中，会计算每个区域的对象存活性(区域中存活对象的比例)。

重新标记

再标记，会有短暂停顿(STW)。再标记阶段是用来收集并发标记阶段产生新的垃圾(并发阶段和应用程序一同运行)，G1 中采用了比 CMS 更快的初始快照算法，snapshot-at-the-beginning(SATB)。

筛选回收

对各个 Region 的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，可以通过参数指定时间 -XX:MaxGCPauseMillis 指定，假设老年代此时有 1000 个 Region 都满了，因为根据预期停顿时间，本次垃圾回收可能只能停顿 200 毫秒，通过之前回收成本计算得知，可能回收其中 800 个 Region 刚好需要 200ms，只会回收 800 个 Region，Collection Set 要回收的集合。

回收算法

回收算法主要用的是复制算法，将一个 Region 中的存活对象复制到另一个 Region 中，这种不会像 CMS 那样回收完因为有很多内存碎片还需要整理一次，G1 采用复制算法回收几乎不会有太多内存碎片。

回收优先列表

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region，一个 Region 花 200ms 能回收 10M 垃圾，另外一个 Region 花 50ms 能回收 20M 垃圾，在回收时间有限情况下，G1 当然会优先选择后面这个 Region 回收，使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率。

期望停顿时间过短问题

可以由用户指定期望的停顿时间是 G1 收集器很强大的一个功能，设置不同的期望停顿时间，可使得 G1 在不同应用场景中取得关注吞吐量和关注延迟之间的最佳平衡。"期望值” 必须是符合实际的，不能设置太短，它默认的停顿目标为 200 毫秒，如果我们把停顿时间调得非常低，可能出现的结果就是由于停顿目标时间太短，导致每次选出来的回收集只占堆内存很小的一部分，收集器收集的速度逐渐跟不上分配器分配的速度，导致垃圾慢慢堆积，最终占满堆引发 Full GC 反而降低性能，通常把期望停顿时间设置为一两百毫秒或者两三百毫秒会是比较合理。

G1 回收器特点

并行与并发

G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 StopThe-World 停顿时间。部分其他收集器原本需要停顿 Java 线程来执行 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。

分代收集

G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。

空间整合

与 CMS 的 “标记-清理” 算法不同，G1 从整体来看是基于 “标记-整理” 算法实现的收集器，从局部上来看是基于 “复制” 算法实现的。

可预测的停顿

G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段。

G1 使用场景

  • 50% 以上的堆被存活对象占用
  • 对象分配和晋升的速度变化非常大
  • 垃圾回收时间特别长，超过 1 秒
  • 8GB 以上的堆内存(建议值)
  • 停顿时间是 500ms 以内

G1 收集器参数设置

使用 G1 收集器

-XX:+UseG1GC

指定 GC 工作的线程数量

-XX:ParallelGCThreads

指定分区大小 (1MB~32MB，且必须是 2 的 N 次幂)，默认将整堆划分为 2048 个分区

-XX:G1HeapRegionSize

目标暂停时间(默认200ms)

-XX:MaxGCPauseMillis

新生代内存初始空间(默认整堆5%)

-XX:G1NewSizePercent

新生代内存最大空间

-XX:G1MaxNewSizePercent

Survivor 区的填充容量(默认50%)，Survivor 区域里的一批对象(年龄1 + 年龄2 + 年龄n 的多个年龄对象)总和超过了 Survivor 区域的50%，会把年龄n(含)以上的对象都放入老年代

-XX:TargetSurvivorRatio

最大年龄阈值(默认15)

-XX:MaxTenuringThreshold

老年代占用空间达到整堆内存阈值(默认45%)，大于该值时则执行新生代和老年代的混合收集(MixedGC)，比如我们之前说的堆默认有 2048 个 Region，如果有接近 1000 个 Region 都是老年代的 Region，则可能就要触发 MixedGC 了

-XX:InitiatingHeapOccupancyPercent

Region 中的存活对象低于这个值时才会回收该 Region，如果超过这个值，存活对象过多，回收的的意义不大(默认85%)

-XX:G1MixedGCLiveThresholdPercent

在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长

-XX:G1MixedGCCountTarget

GC 过程中空出来的 Region 是否充足阈值，在混合回收的时候，对 Region 回收都是基于复制算法进行的，都是把要回收的 Region 里的存活对象放入其他 Region，然后这个 Region 中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的 Region，一旦空闲出来的 Region 数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收就结束了

-XX:G1HeapWastePercent
posted @ 2021-09-06 10:42  BNTang  阅读(467)  评论(0)  编辑  收藏  举报