深入分析 OpenJDK G1 FullGC 原理

爱被打了一巴掌 2024-03-26 11:27 43阅读 0赞

### 导读 ###

本文主要从代码层面介绍 OpenJDK G1（garbage first） FullGC 的工作原理，基于 OpenJDK 从 GC（garbage collection） 入口处开始分析整个 FullGC 原理的核心代码与执行过程；并对比 OpenJDK8 与 OpenJDK11 中单线程与多线程实现 FullGC 的异同。希望帮助大家更深入地理解 G1 FullGC 原理，并了解代码中可能导致 GC 时间长的对象分配方式。

### G1 GC的知识回顾 ###

为了帮助大家更全面地理解 FullGC 的逻辑和前因后果，我们先整体简单介绍下 G1 GC 。GC 主要指在程序运行过程中，对象不再使用后，由 JVM 提供的程序将对象销毁并回收内存，将该内存再加入到可用内存中；而 G1GC，是 JVM 提供的一种垃圾回收器，可以通过多 worker 并行回收，并且通过 CMS 并发标记，此外通过 region 的分代回收，可以较好的控制单次回收的暂停时间，并且有效的抑制碎片化的问题。但 G1 并不是完美的回收器，相比于 CMS GC，G1GC CPU 负载相对较高；吞吐量在小内存上可能相对较弱，但 G1GC 整体在回收时间和效率上都表现较为优秀，是当前 java 业务中使用较为频繁的垃圾回收器。但随着使用场景的变换，为了在业务中更好地完成垃圾回收调优，可以更多地了解下这项技术的基础知识。

**1.**G1 将整个 JVM 运行时堆分为若干个 region，region 大小在运行之初设定，且一经设定不可改变；每个 region 都可能被作以下分别：包括 Eden，Survivor，Old，Humongous 和 Free 等区域，其中 Eden region 指年轻代，一般对象（大小小于 region 的一半）对象分配的默认选择区域，并且为每次内存空间不足时的优先回收区；从一次垃圾回收存活下来的对象会被 copy 到 survivor region，经过几轮回收后，依然存活的对象太多，则这些对象会被移动到 Old region；当对象大小大于region 一半会被直接分配到 Humongous region，只有在 Full GC 或者 CMS 后才有机会回收。

**2.**回收包含 4 部分 YoungGC（Pause）、MixGC、Concurrent Marking 和 FullGC

**YoungGC**：选择全部年轻代(Eden)，根据暂停时间要求决定回收年轻代的数量。

*  stop the world（stw）暂停所有应用线程，G1 创建回收集 Collection Set（cset）
 *  扫描 root，从栈、classloader、JNIHandle 等出发，扫描标记直接引用的对象
 *  基于要回收的 region 的 rset 来扫描标记对应 region 的存活对象
 *  然后将活对象 copy 到新 region
 *  处理其他引用

**Concurrent Marking Cycle：** JVM 内存使用比例超过一定阈值，会触发全局并发标记，包括 clean up 阶段（这里会清理 出部分大对象）

**MixGC：**选择全部年轻代和部分老年代，会按照垃圾占比高低来排序，优先回收垃圾多的 set，G1也得名于此（Garbage f irst），回收过程同 YoungGC 一样。

**FullGC：** MixGC 来不及回收或回收不掉，分配内存仍失败，就会触发全局回收，包括所有年轻代、老年代，大对象以及少 量其他的 JVM 管理的内存，过程总体同 YoungGC 一样。不过扫描 root 过程会将整个堆完全扫描完。对于有些高流量的 业务程序而言，适当的 FullGC 可以更好的调整整个内存，但一般情况而言，因为回收暂停时间较长，我们应当尽量避免 Fu llGC。

**3.**G1 FullGC 回收流程图简图如下

![0a461299bf4f477792f07ad7f9fdf905.png][]

![0630df5a696b49aba25dabd8c166cf13.png][]

### G1 FullGC入口（触发条件） ###

触发 FullGC 的条件主要分两大类，第一类是在对象分配时发现内存不足导致分配失败，会触发回收逻辑，在 young gc/mix gc 尝试回收后，都不能释放足够内存时，便会触发 FullGC；第二类为业务代码中主动调用回收内存函数，比如 System.gc。两类最终都会调用到 do\_collection()，此处不涉及 parallel，OpenJDK8 和 OpenJDK11 入口相同

// 各种分配失败时的调用入口
    G1CollectedHeap::mem_allocate
        VM_G1CollectForAllocation::doit()  
            G1CollectedHeap::satisfy_failed_allocation()
                G1CollectedHeap::do_collection()
    
     // System.gc()和 metadata回收            
    G1CollectedHeap::collect(GCCause::Cause cause)
        VM_G1CollectFull::doit()
            G1CollectedHeap::do_full_collection()
                G1CollectedHeap::do_collection()

### G1 FullGC回收前准备——prepare\_collection ###

从 do\_collection 调入后，对于 OpenJDK8，以 G1MarkSweep::invoke\_at\_safepoint 函数为边界，该函数前为回收准备，之后为收尾工作；而 OpenJDK11 则将整个 prepare\_collection、collect 和 complete 三步都用 g1FullCollector 类进行封装，逻辑更加清晰。

准备过程两者相似，可简单分为三类

*  **数据信息检查及记录**：包括计时器，trace、safepoint 检查、日志打印等数据处理部分
 *  **concurrent\_mark 相关操作和暂停**：包括 concurrent\_mark 的 abort，cm discovery 禁用等
 *  **回收准备**：heap 集合整理清除、policy 策略更新、开启 stw discovery、处理对象偏向锁等

// openjdk11
    void G1FullCollector::prepare_collection() {
      _heap->g1_policy()->record_full_collection_start();
      _heap->print_heap_before_gc();
      _heap->print_heap_regions();
       // 终止并发标记，禁用cm discovery
      _heap->abort

[0a461299bf4f477792f07ad7f9fdf905.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/97fb1cba61e541d2ad1b6627f92b0f63.png
[0630df5a696b49aba25dabd8c166cf13.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/92bcfc41e46343a8a6b4beddb167c20d.png