G1GCRegion状态切换详解：从Free到Eden再到Old

本文深入剖析了G1垃圾收集器中Region状态切换的本质机制，指出仅依赖GC日志中的逻辑内存变化（如“Eden: 128M->0B”）会严重误导对内存布局的真实理解；唯有启用-XX:+PrintRegionStats才能获取全堆Region的物理类型瞬时快照，精准追踪Region如何在Free、Eden、Survivor、Old和Humongous之间原子性地重标记与流转——这种切换完全由GC动作驱动，而非对象年龄或时间推移自动发生，揭示了G1内存管理高度动态、按需重构的核心特性，为诊断大对象泄漏、老年代异常膨胀及Region复用瓶颈提供了不可替代的底层观测依据。

直接看 GC 日志里的 [Eden: 128M->0B(128M) 这类字段，根本看不出 Region 状态切换——它只反映逻辑容量变化，不体现物理 Region 的实际类型流转。真正要分析 Region 生命周期，得靠 PrintGCDetails + -XX:+UnlockDiagnosticVMOptions -XX:+PrintRegionStats 组合输出的 region-level 快照。

怎么看 G1 的 Region 类型实时分布？

启用 -XX:+PrintRegionStats 后，每次 GC 暂停结束时会打印类似这样的表格：

Region Stats (total: 2048, free: 1520, eden: 256, survivors: 16, old: 240, humongous: 16)

这个统计是真实物理 Region 计数，不是逻辑内存大小。关键点：

• free 表示未分配、可被任意类型复用的空闲 Region；
• eden 和 survivors 是当前被标记为年轻代用途的 Region，但它们物理上可能散落在堆任意位置；
• old 包含所有被标记为老年代的 Region，包括已晋升对象所在的和尚未触发并发标记的“冷” Old Region；
• humongous 是独立计数，且 StartsHumongous 和 ContinuesHumongous 都算在内。

Region 状态切换的真实触发点在哪？

Region 类型变更不是由对象年龄或引用关系自动触发的，而是由 GC 动作强制重标记：

• Young GC 结束后：存活对象复制到 S 区或晋升到 O 区 → 对应目标 Region 被重新标记为 Survivor 或 Old；
• Mixed GC 中回收某个 Old Region → 该 Region 清空后直接变成 Free，下次分配可能变 Eden；
• Humongous 分配失败 触发 Full GC → 所有 Region 重置状态，Free 数量暴增；
• 没有 GC 发生时，Old Region 不会“自动”变成 Free，哪怕里面全是垃圾——必须等并发标记+Cleanup 阶段确认其可回收。

为什么 PrintRegionStats 比 GC 日志更可靠？

GC 日志里 [Eden: 128M->0B(128M)] 这种写法容易误导：它只表示 Eden 逻辑区总容量 128MB、回收后使用量归零，但完全不告诉你这 128MB 是由哪几个 Region 构成、回收后这些 Region 是否还属于 Eden。

而 PrintRegionStats 每次输出都是全堆 Region 的瞬时快照，能清晰看到：

• 一次 Young GC 后 eden 数下降、survivors 上升，说明部分 Region 从 Eden 切换为 Survivor；
• Mixed GC 后 old 数减少、free 数增加，证明老年代 Region 真被释放了；
• 如果 humongous 数持续增长但 free 不降，大概率是大对象泄漏，Region 被长期占用无法复用。

Region 的物理生命周期其实就三步：分配时标记类型 → GC 时按需重标记 → 回收后归入 Free 池。整个过程没有中间态，切换就是原子性的重标记操作，不存在“半旧半新”的 Region。最容易被忽略的是：一个 Region 可能在 5 分钟内反复在 Eden→Survivor→Old→Free 之间跳转，完全取决于业务对象的创建/存活/晋升节奏，而不是固定周期。

到这里，我们也就讲完了《G1GCRegion状态切换详解：从Free到Eden再到Old》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！