【JVM垃圾回收器G1详解】

最新推荐文章于 2025-04-08 17:56:22 发布

三河与木

最新推荐文章于 2025-04-08 17:56:22 发布

阅读量988

点赞数

分类专栏： JVM专栏文章标签： jvm

本文链接：https://blog.youkuaiyun.com/weixin_42070243/article/details/133172847

版权

JVM专栏专栏收录该内容

7 篇文章

订阅专栏

本文详细介绍了Java的G1垃圾回收器，包括其工作原理、优势（如并行并发、空间整合和可预测停顿）、分类（YoungGC、MixedGC和FullGC）以及优化策略，重点阐述了如何在大型服务器环境中有效管理内存和降低停顿时间。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

一、垃圾回收器G1

一、垃圾回收器G1

1.1、什么是G1

G1是一款面向服务器的垃圾回收器，主要是针对配置多个处理器和大容量内存的机器，满足GC停顿时间要求的同时，还具备高吞吐量性能特征，相比之前的CMS，G1没有明显的分代机制，我们可以先查下图所示，为G1的对象内存分布图：
在这里插入图片描述
G1会把堆内存分为四种独立的小鸽子，也就是Region，JVM中最多可以有2048个Region；
在给每个Region分配内存大小时。就说用总的分配空间除以2048，例如：现在分配的大小为：4096，那每个Region就为：4096/2048=2M；
也可以通过设置参数：XX:G1HeapRegionSize手动指定Region大小，但是推荐默认的计算方式。
G1 保留了老年和新生代的概念，只是不再用物理隔阂，他们都是Region集合，默认年轻代占堆内存的5%，可以通过参数：-XX:G1NewSizePercent设置新生代初始占比，在系统运行时，JVM会不停的给新生代增加更多的Region，但最多新生代的占比不会超过60%，也可以通过参数：-XX:G1MaxNewSizePercent进行调整，Eden和Survivor的占比还是和之前的一样：也是8:1:1
不通电在于：G1 垃圾回收器，增加了一个大对象处理的Region，也就是上图的Humongous区，这个区域专门针对大对象存在的，在G1中，大对象的判定其实是超过一个Region的50%，就会将对象移到Humoongous区；

1.2、G1工作流程

那G1是如何运作的呢？下面我们可以探讨下G1的运作过程
G1 的运作过程我们可以分为以下四个步骤，和CMS很类似，分别为：初始标记、并发标记、最终标记、筛选回收

初始标记：这个过程会STW，和CMS是一样的，记录GC Roots直接引用的对象，速度很快；
并发标记：这个过程也是和CMS回收器一样的标记过程；
最终标记：这个过程同CMS中的重新标记，会STW方式进行标记；
筛选回收：这个阶段是G1特有的，首先是先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，尽量的将GC停顿时间控制在制定的范围内，这个阶段是STW方式执行的，且这个阶段只会回收一部分的Region，根据指定的停顿时间做选择的，默认这个时间为200ms，主要目的是为了提高用户的体验感，这个回收器不管是年轻代还是老年代，回收算法用的都是复制算法，将一个Region中的存活对象复制到另外一个Region中，这种方式不会产生大量的内存碎片，具体执行过程图如下所示：

1.3、G1优势

在整个过程中，G1具备以下特点：
1、并行与并发：G1能充分利用CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短Stop -The - World停顿时间。部分其他收集器原本需要停顿Java线程来执行GC动作，G1收集器仍然可以通过并发的方式让java程序继续执行。
2、分代收集：虽然G1可以不需要其他收集器配合就能独立管理整个GC堆，但是还是保留了分代的概念。
3、空间整合：与CMS的“标记–清理”算法不同，G1从整体来看是基于“标记整理”算法实现的收集器，从局部上来看是基于“复制”算法实现的。
4、可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

1.4、G1 垃圾收集分类

1.4.1、YoungGC

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

1.4.2、MixedGC

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

1.4.3、Full GC

停止系统程序，然后采用单线程进行标记、清理和压缩整理，好空闲出来一批Region来供下一次MixedGC使用，这
个过程是非常耗时的。(Shenandoah优化成多线程收集了)

1.5、G1的使用场景

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

1.6、G1的常见优化

这个过程主要是需要格外关注：指定的停顿时间参数：-XX:MaxGCPauseMills，若设置过大，可能会导致系统运行很久，年轻代可能在堆内存的占比很高，这个时候才进行YoungGC，那么存活下来的对象就很多，有可能Survivor区放不下或者会触发动态年龄判断机制，那对象就会进入老年代，所以我们在指定这个停顿时间时，不仅要保证年轻代的GC别太频繁的同时，我们还需要考虑每次GC之后，存活的对象有多少，避免上述情况，太多就会加速对象进入老年代的时间，频繁的触发Mixed GC；