g1混合回收中cset动态裁剪取决于价值排序、成本预测与堆压力的实时博弈，需结合日志中的region数量变化、停顿时间波动、ihop阈值及g1mixedgccounttarget等参数综合判断裁剪合理性。
看懂 G1 混合回收日志里的 CSet 动态裁剪，关键不是数清“选了几个 Region”，而是理解它为什么选这些、没选那些——背后是价值排序、成本预测和堆压力三者实时博弈的结果。
从日志里定位 CSet 构成信息
G1 的 Mixed GC 日志中，CSet 的实际组成会明确写出。重点关注类似这样的字段：
- [GC pause (G1 Evacuation Pause) (mixed), 0.042s] —— 表明这是一次混合回收，STW 耗时 42ms
- [Eden: 128M(16)->0B(16), Survivors: 16M->20M, Old: 320M->280M] —— Eden 和 Survivor 大小变化是固定的（所有年轻代 Region 必入 CSet），Old 内存下降量 ≈ 本轮回收的老年代 Region 总容量
- [Mixed GC: 8 regions, 1 humongous] 或 [CSet: 12 regions (4 young, 8 old)] —— 直接告诉你本次 CSet 中老年代 Region 数量
识别裁剪逻辑的三个信号
CSet 不是静态列表，每次都在动态收缩或扩张。观察连续几次 Mixed GC 日志，可发现以下典型模式：
- 停顿时间持续低于目标值（如设为 200ms，实际总在 120–150ms） → 下一轮通常会增加老年代 Region 数量，例如从 5 个升到 7 个，日志中表现为 “8 regions” → “10 regions”
- 某次实际停顿明显超时（如达 230ms）且前序几次也偏高 → G1 会主动削减，下一轮可能跳到 “5 regions”，甚至出现 “1 region” 的轻量清理
- Old Gen 使用率远高于 IHOP（如 65% vs 默认 45%）但 CSet 却很小（长期 ≤2） → 很可能是高 RSet 开销或 Live Data 估算偏高，导致高价值 Region 被误判为“不划算”，CSet 实际被保守裁剪
结合参数理解裁剪边界
CSet 的数量不是无约束增长，受多个硬性参数限制：
- -XX:G1MixedGCCountTarget=8（默认）：整个并发标记周期后，G1 最多分 8 轮完成老年代清理。若候选 Region 共有 64 个，那平均每轮最多进 8 个；若只剩 12 个可回收，后期就可能每轮只进 1–2 个
- -XX:G1MixedGCLiveThresholdPercent=85（默认）：只允许存活对象占比 ≤15%（即垃圾 ≥85%）的 Region 进入 CSet。日志中若大量老年代 Region 未被选中，很可能是它们的存活率被标记为 86%、91% 等，直接被门槛拦下
- -XX:G1OldCSetRegionThresholdPercent=10（默认）：老年代 Region 总数若为 200 个，本轮 CSet 中老年代部分最多只能含 20 个，超出即被截断
用 GC 日志反推裁剪是否合理
真正判断裁剪是否健康，要看后续行为是否连贯：
- 如果连续多轮 CSet 都只有 1–2 个老年代 Region，但 Old Gen 使用率仍在快速爬升（如从 48% → 58% → 67%），说明裁剪过严，可能触发 Full GC 风险
- 如果某轮 CSet 突然激增至 15 个 Region，但停顿时间仍控制在 180ms 内，且之后 Old Gen 显著回落（如 62% → 43%），说明裁剪正响应高压力，属正常激进策略
- 日志中反复出现 “to-space exhausted” 或 “Concurrent Cycle was cancelled”，基本可判定 CSet 规模长期偏小，已无法跟上对象晋升速度
