如何分析 G1 GC 的 Region 状态切换图：从 Free 到 Eden 再到 Old 的物理内存生命周期

分析 G1 GC 的 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 之间跳转，完全取决于业务对象的创建、存活和晋升节奏，而不是什么固定规律。