如何分析 G1 GC 的 Region 状态切换图:从 Free 到 Eden 再到 Old 的物理内存生命周期
G1GC的Region状态切换必须通过GC动作强制重标记,PrintRegionStats输出的物理Region计数快照能清晰显示Eden、Survivor、Old等类型切换,而GC日志仅反映逻辑容量。Region生命周期分三步:分配时标记类型、GC时按需重标记、回收后归入Free池,切换是原子性操作。
分析 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 发生时,
OldRegion 不会“自动”变成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 之间跳转,完全取决于业务对象的创建、存活和晋升节奏,而不是什么固定规律。


































