G1垃圾回收器：从原理到调优的全面解析

原创

于 2026-02-24 01:04:57 发布 · 890 阅读

标签

1. 垃圾回收：从“打扫房间”说起

如果你把电脑的内存想象成你的房间，那么垃圾回收（Garbage Collection, GC）就是那个帮你自动打扫房间的“田螺姑娘”。你只管在房间里创造（创建对象）、使用（引用对象），而当你把东西扔到一边不再理会时（对象失去引用），GC就会在某个时刻悄悄进来，把这些“垃圾”清理掉，腾出空间让你可以继续折腾。听起来很美好，对吧？但问题来了，如果房间特别大（比如堆内存有几十个G），或者你制造垃圾的速度特别快（高并发创建对象），这个“田螺姑娘”如果打扫得慢吞吞，或者打扫时非要让你停下手里所有工作（Stop The World, STW），那体验可就太糟糕了。你的应用程序就会卡住，用户就会抱怨。所以，垃圾回收器的核心使命就两个：高效地回收垃圾，以及尽可能地减少对应用程序的干扰。

在JVM的发展史上，为了平衡这两点，工程师们发明了各种各样的回收器。从最早的Serial收集器（单线程打扫，你必须全程罚站），到后来的Parallel收集器（多线程打扫，速度快了但你还是得罚站），再到CMS收集器（尽量和你一起干活，减少罚站时间，但打扫得不够彻底，容易留下“内存碎片”这个烂摊子）。每一种都有其适用场景和痛点。

直到G1（Garbage-First）垃圾回收器的出现，它被设计用来应对大内存（比如堆内存超过4GB甚至更大）场景下的低停顿需求。Oracle从JDK 9开始，已经将G1作为了默认的垃圾回收器，这足以说明它的地位。但很多开发者对G1的印象可能还停留在“听说很牛”、“参数简单”上，对其内部到底怎么工作的，以及如何真正用好它，还是一头雾水。今天，我就结合自己这些年调优JVM的经验，带你从原理到实战，把G1彻底搞明白。

2. G1的核心设计思想：化整为零与目标导向

G1之所以能处理大堆内存，其根本设计理念是“化整为零”和“目标导向”。这和我们传统的认知很不一样。

2.1 取消物理分代，引入Region分区

在G1之前，无论是CMS还是Parallel，堆内存的布局都是泾渭分明的：这是一整块连续的新生代（Eden + Survivor），那是一整块连续的老年代。这种布局简单，但在进行垃圾回收时，特别是老年代回收，往往需要扫描或操作一大片连续区域，这是导致长时间停顿的一个原因。

G1彻底打破了这种物理上的连续分代。它把整个Java堆（除了巨大的元空间）划分成多个大小固定、物理上不连续的Region。每个Region可以是Eden、Survivor、Old或一种特殊的Humongous区域。Region的大小可以通过 -XX:G1HeapRegionSize 设置，范围从1M到32M，必须是2的幂。JVM会基于你设置的最小堆内存，尽量划分出大约2048个Region。

这样做有什么好处呢？灵活性。G1回收的不是整个新生代或整个老年代，而是以Region为最小回收单元。每次回收，它会根据“性价比”（即回收该Region能获得多少空间、需要多少时间）来选择一组Region进行收集，这组被选中的Region集合就叫 CSet（Collection Set）。