JVM-垃圾收集器G1

最新推荐文章于 2025-08-12 16:19:53 发布

原创最新推荐文章于 2025-08-12 16:19:53 发布 · 132 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#jvm #java

G1收集器是一种面向服务器的垃圾收集器，专为多处理器和大内存设计。它通过并行与并发操作、分代收集和空间整合优化，提供低停顿时间和可预测的性能。文章详细介绍了G1的内存划分、收集策略和优化建议，适用于特定场景如大内存、高停顿时间等。

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

G1收集器(-XX:+UseG1GC)

G1（Garbage-First）是一款面向服务器的垃圾收集器，主要针对配备多颗处理器及大容量内存的机器。以极高概率满足GC停顿时间要求的同时，还具备高吞吐量性能特征。

在JDK 7版本正式启用，是JDK 9以后的默认垃圾收集器

Region：G1把Java堆划分为2048个大小相等的区域，称为Region（Region物理上不连续，每个Region大小是1-32M不等，必须是2的整数次幂）。参数-XX:G1HeapRegionSize可以指定Region大小，但是不推荐。

堆4G大小，Region为2M；堆64G大小，Region为32M

JVM目标是不超过2048个Region（JVM源码里TARGET_REGION_NUMBER 定义），实际可以超过该值，但是不推荐。

G1保留了年轻代和老年代的概念，是逻辑上的保留，物理上不连续

默认年轻代占用堆内存的5%。例如堆大小4096M，年轻代占200M左右，大概100个Region。可以通过-XX:G1NewSizePercent设置新生代初始占比，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，可以通过-XX:G1MaxNewSizePercent调整。年轻代中的Eden和Survivor对应的Region也跟之前一样，默认8:1:1

G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，而且一个大对象如果太大，可能会横跨多个Region来存放。Humongous区专门存放短期巨型对象，不用直接进老年代，可以节约老年代的空间，避免因为老年代空间不够的GC开销。

Full GC的时候除了收集年轻代和老年代之外，也会将Humongous区一并回收。

堆内存划分2048个大小相等的Region，物理不连续，Region的大小和个数可修改，但是不推荐。新生代默认占比堆内存的5%，最大不超过堆内存的60%。另外大对象保存到Humongous区，大于Region的50%为大对象，Humongous可跨多个Region保存

G1收集器一次GC(主要值Mixed GC)的运作过程大致分为以下几个步骤：

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快 ；
并发标记（Concurrent Marking）：同CMS的并发标记
最终标记（Remark，STW）：同CMS的重新标记
筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿STW时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，

不管是年轻代或是老年代，回收算法主要用的是复制算法，将一个region中的存活对象复制到另一个region中，这种不会像CMS那样回收完因为有很多内存碎片还需要整理一次，G1采用复制算法回收几乎不会有太多内存碎片。(注意：CMS回收阶段是跟用户线程一起并发执行的，G1因为内部实现太复杂暂时没实现并发回收，不过到了ZGC，Shenandoah就实现了并发收集，Shenandoah可以看成是G1的升级版本)

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

被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点：

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

G1垃圾收集分类

YoungGC

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

MixedGC

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

Full GC

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

相关参数（官网地址）：

参数	作用	默认
`-XX:+UseG1GC`	使用G1收集器	-
`-XX:ParallelGCThreads`	指定GC工作的线程数量	-
`-XX:G1HeapRegionSize`	指定分区大小(1MB~32MB，且必须是2的N次幂)，默认将整堆划分为2048个分区	-
`-XX:MaxGCPauseMillis`	目标暂停时间，停顿时间设置太小会失效	200
`-XX:G1NewSizePercent`	新生代内存初始空间(值配置整数，默认就是百分比)	5
`-XX:G1MaxNewSizePercent`	新生代内存最大空间	60
`-XX:TargetSurvivorRatio`	Survivor区的填充容量(默认50%)，Survivor区域里的一批对象(年龄1+年龄2+年龄n的多个年龄对象)总和超过了Survivor区域的50%，此时就会把年龄n(含)以上的对象都放入老年代	50
`-XX:MaxTenuringThreshold`	最大年龄阈值	15
`-XX:InitiatingHeapOccupancyPercent`	老年代占用空间达到整堆内存阈值(默认45%)，则执行新生代和老年代的混合收集(MixedGC)	45
`-XX:G1MixedGCLiveThresholdPercent`	region中的存活对象低于这个值时才会回收该region，如果超过这个值，存活对象过多，回收的的意义不大	85
`-XX:G1MixedGCCountTarget`	在一次回收过程中指定做几次筛选回收(默认8次)，在最后一个筛选回收阶段可以回收一会，然后暂停回收，恢复系统运行，一会再开始回收，这样可以让系统不至于单次停顿时间过长。	8
`-XX:G1HeapWastePercent`	gc过程中空出来的region是否充足阈值，在混合回收的时候，对Region回收都是基于复制算法进行的，都是把要回收的Region里的存活对象放入其他Region，然后这个Region中的垃圾对象全部清理掉，这样的话在回收过程就会不断空出来新的Region，一旦空闲出来的Region数量达到了堆内存的5%，此时就会立即停止混合回收，意味着本次混合回收结束。	5