应结合GC类型、Region角色变化、RSet行为和空间迁移轨迹解析G1 Region回收，重点关注Evacuation Pause日志中的Region统计、jstat指标异常、RSet更新密度及Mixed GC选区逻辑失真信号。
解析 G1 的 Region 回收情况，不能只看“回收了几个 Region”，而要结合 GC 类型、Region 角色变化、RSet 行为和空间迁移轨迹，从日志里还原内存真实流动路径。
盯紧 Evacuation Pause 日志里的 Region 统计字段
G1 的关键回收动作发生在 Evacuation Pause（疏散暂停）阶段，日志中明确标出本次回收涉及的 Region 数量和类型：
-
Young GC 日志示例：
[GC pause (G1 Evacuation Pause) (young), 0.089ms] [Eden: 2048M(2048M)->0B, Survivors: 256M->256M, Heap: 3200M(8192M)->1200M(8192M)]→ 这里没写 Region 数，但可通过jstat -gc <pid>中YGCT和YGC频率 +EU波动反推 Eden Region 数量变化 -
Mixed GC 日志会直接说明：
[GC pause (G1 Evacuation Pause) (mixed), 12.456ms] [Eden: 1024M->0B, Survivors: 128M->128M, Old: 2456M->1890M, 16 regions]→ 最后的 “16 regions” 指本次共回收 16 个 Region，其中包含年轻代 Region（Eden + Survivor）和老年代 Region（Old 部分） - 若看到
Humongous regions allocated: 3或Humongous allocation failed，说明有大对象触发了 Humongous 分配，这些 Region 不参与 Mixed GC，但会拖慢整体回收节奏
用 jstat 定位 Region 级别空间异常
jstat -gc <pid> 输出中的几列是 Region 行为的间接镜像：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
EU（Eden Used）持续剧烈波动但 OU（Old Used）缓慢爬升 → 缓存类对象存活时间略长于 Survivor 容纳能力，频繁晋升，说明 Survivor 区偏小或
-XX:MaxTenuringThreshold过低 -
HU（Humongous Used）> 5% → 当前
-XX:G1HeapRegionSize明显小于常见大对象尺寸，导致大量对象被迫走 Humongous 路径，应调大 RegionSize - EC（Eden Capacity）与 S0C/S1C 总和远低于预期新生代占比 → G1 动态调整了年轻代 Region 数量，可能因老年代压力大而压缩新生代，需检查 IHOP 触发时机
从 GC 日志深挖 RSet 和 Region 角色切换痕迹
RSet 更新密度和 Region 角色变动，才是真正反映 Region “活跃度”的信号：
立即学习“Java免费学习笔记（深入）”；
- 加启动参数
-Xlog:gc+remset*=debug,gc+ergo=debug（JDK 11+），搜索[debug][gc,remset] Remembered set update for region→ 出现频次高的 Region ID，说明它被多个其他 Region 频繁写入引用，是跨区引用热点，大概率承载缓存 value 或共享元数据 - 查找
[debug][gc,ergo] Request heap region size行，确认 JVM 实际采用的 RegionSize；再比对Total remembered set memory: X.XMB (Y% of total heap)→ 若 RSet 占堆 > 1.5%，说明 Region 划分过细，需增大 RegionSize 以减少跨 Region 引用边界 - 日志中反复出现
to-space exhausted或evacuation failed→ 不是单纯内存不足，而是目标 Region（to-space）因 RSet 太大或存活对象太多无法完成复制，本质是某些 Region 的“回收价值”被严重低估
识别 Mixed GC 的 Region 选择逻辑是否失真
G1 每次 Mixed GC 选哪些老年代 Region，取决于动态排序的价值模型。异常信号包括：
- 长期只回收 1–2 个老年代 Region，但
OU持续上涨、OC（Old Capacity）使用率逼近 IHOP → 说明 G1 认为可回收的老年代 Region “价值低”，可能因 RSet 过大、Live Data 估算偏高，或 Humongous Region 占比过高挤占了 CSet 名额 - 日志中
[GC pause (mixed)]后紧跟Concurrent Cycle was cancelled→ 并发标记未完成就被打断，往往因为 Mixed GC 实际停顿远超-XX:MaxGCPauseMillis，G1 主动放弃本轮回收，此时应检查是否 RegionSize 不匹配、或-XX:G1MixedGCCountTarget设得太小导致单轮压力过大 - 对比多轮 Mixed GC 的
Old: XMB->YMB变化幅度：若某次回收后 Old 使用量下降极少（如仅降 10MB），但耗时却达 15ms，说明该轮选中的 Region 存活率高、收益差，需结合 RSet 日志排查具体 Region
