如何解读G1 GC中Region状态变化过程：从空闲至Eden，再到老年代内存演变轨迹？

本文共计806个文字，预计阅读时间需要4分钟。

直接查看GC日志中的[Eden: 128M-部分内容。

怎么看 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 之间跳转，完全取决于业务对象的创建/存活/晋升节奏，而不是固定周期。