如何分析 G1 GC 的 CSet（Collection Set）选择算法如何平衡回收价值与停顿时间目标-java教程-PHP中文网

G1的CSet不是“回收最多对象”的集合，而是以满足MaxGCPauseMillis为目标、按“单位时间回收效率”（reclaimable_bytes/predicted_time）贪心选择Region的集合，优先纳入预测耗时低且可回收量相对高的Region，而非单纯可回收量最大的Region。

如何分析 g1 gc 的 cset（collection set）选择算法如何平衡回收价值与停顿时间目标

为什么 G1 的 CSet 不是“回收最多对象”的集合

G1 的 CSet 选择根本目标不是最大化回收量，而是满足用户设定的 MaxGCPauseMillis（如默认 200ms），同时尽可能多地释放堆空间。它把整个堆划分为大小相等的 region，每个 region 维护一个“回收价值”指标——即 predicted_elapsed_time（预测回收耗时）与 reclaimable_bytes（可回收字节数）的比值，也就是“单位时间能回收多少内存”。这个比值越高，region 越“划算”。

实际选择时，G1 按该比值从高到低排序 region，逐个加入 CSet，直到预估总停顿时间逼近但不超过目标值。这意味着：

一个巨型、碎片少、存活对象极少的 region，哪怕只含 1MB 可回收内存，也可能因预测耗时极低（0.5ms）而被优先选中
一个中等大小但跨代引用多、RSet 更新重、卡表扫描慢的 region，即使可回收 5MB，也可能因预测耗时飙到 80ms 被跳过
G1MixedGCCountTarget 和 G1OldCSetRegionThresholdPercent 会影响老年代 region 的入选倾向，但不改变“价值优先+时间封顶”的底层逻辑

如何用 JVM 参数和日志验证 CSet 构成

开启详细 GC 日志后，每次 Mixed GC 开始前会打印 CSet 的 region 统计。关键参数组合如下：

-Xlog:gc+ergo+cset=debug,gc+heap=debug -XX:MaxGCPauseMillis=100

你会在日志中看到类似：

[DEBUG][gc,ergo,cset] Adding region [0x00000007c0000000, 0x00000007c0200000] to collection set (reclaimable: 1048576B, predicted time: 1.23ms)

重点关注三列：reclaimable（真实可回收量）、predicted time（G1 基于历史 RSet 扫描耗时、对象复制开销、TLAB 分配成本等模型估算）、region type（是否为 old / humongous / mixed）。注意：predicted time 不是实测值，它依赖 G1PeriodicGCInterval 触发的采样，若应用刚启动或行为突变，预测可能严重偏高/偏低。

CSet 选择失败的典型信号：Mixed GC 频繁但回收量锐减

当观察到以下现象，说明 CSet 算法已陷入“价值-时间”两难：

GC 日志中连续多次 Mixed GC 的 collection-set size 稳定在极小值（如仅 2–3 个 region），但 reclaimed 总量远低于 old gen used 增长速率
G1EvacuationFailure 出现频率上升，伴随 to-space exhausted 错误 —— 表明 CSet 过小导致晋升失败，被迫触发 Full GC
JFR 录制中 G1YoungCollection 事件的 collectionSetSize 字段长期 ，而 oldGenUsedAfter 持续爬升

此时不是调大 MaxGCPauseMillis 就能解决。更可能是老年代 region 的 RSet 过大（如频繁跨代引用）、或存在大量 humongous object 导致 region 无法并入 CSet（G1 不回收 humongous region 的 CSet，除非整块空闲）。

调整 CSet 行为的实操边界在哪

G1 不提供直接干预 CSet 选区的开关，所有“调节”本质是引导预测模型或放宽约束：

降低 RSet 维护开销：用 -XX:G1RSetUpdatingPauseTimePercent=10（默认 10）减少并发 Refine 线程工作量，让预测更稳定；但设太低会导致 RSet 过期，evacuation 失败率上升
控制老年代参与比例：-XX:G1OldCSetRegionThresholdPercent=20（默认 10）可提高老年代 region 入选门槛，避免过早消耗老年代 region，适合写放大高的场景
规避 humongous 区域干扰：监控 G1HumongousAllocation 事件，把 > 50% region size 的对象拆解或池化，否则这些 region 永远不会进 CSet
绝对不要碰 -XX:G1HeapWastePercent（默认 5）—— 它只影响何时触发 Mixed GC，不改变单次 CSet 构成

CSet 是 G1 最精巧也最隐蔽的决策模块：它不暴露算法细节，只通过预测时间和回收量两个标量做贪心选择。真正有效的调优，永远始于看清日志里每个 region 的 predicted time 和 reclaimable 如何分布，而不是盲目调参。