Update RS耗时异常的判定标准是Avg＞10ms或Max＞30ms，结合Ext Root Scanning同步上升可确认RSet更新构成扫描瓶颈；根本原因在于Dirty Card Queue消费滞后，需通过调参与写模式治理协同优化。
Update RS 耗时持续超过 10ms（Avg）或单次突破 30ms（Max），基本可以判定 RSet 更新已构成扫描瓶颈，尤其当它伴随 Ext Root Scanning 时间同步上涨时。
怎么看 Update RS 耗时是否异常
GC 日志中每轮 Young GC 或 Mixed GC 的详细阶段里，会明确列出 Update RS 的统计项，例如：
[Update RS (ms): Min: 0.2, Avg: 12.8, Max: 41.5, Diff: 41.3, Sum: 51.2, Workers: 4]
关键不是看单次峰值，而是观察长期趋势：
-
Avg > 10ms：说明平均每次更新开销已超出 G1 设计预期（通常应控制在 1–5ms 量级），线程可能频繁等待 RSet 缓存区刷新 -
Max > 30ms：大概率触发了 Dirty Card Queue 溢出，导致应用线程被迫自旋或阻塞，直接体现为 STW 时间跳变 - 若
Ext Root Scanning时间也同步上升（比如从 2ms 涨到 15ms），说明 RSet 更新滞后已反向拖累根扫描——因为部分跨 Region 引用未及时记录，GC 线程不得不退化为全堆扫描
为什么 Update RS 会突然变慢
RSet 更新本身不耗 CPU，真正卡住的是 Dirty Card Queue 的消费与重置。常见诱因有：
- 突发写操作集中：如批量导入、缓存预热、日志刷盘等场景，短时间内大量跨 Region 写入，
Dirty Card Queue被瞬间填满 -
G1ConcRefinementThreads设置过低（默认值常为 1 或 2），无法及时消费队列；而调得过高又可能抢占应用线程资源 - 对象图深度大且跨 Region 引用频繁：比如一个大对象图中，多个 Region 的对象互相持有引用，每次修改都会触发多条 card 标记
- Region 大小不合理（如
-XX:G1HeapRegionSize=1M）：Region 越小，跨 Region 写比例越高，RSet 条目爆炸式增长
确认瓶颈后该调哪些参数
参数调整必须配合日志验证，不能孤立改动：
- 优先加
-XX:G1ConcRefinementThreads=4（4核以上机器可设为 CPU 核数的 1/4），并观察日志中Refinement阶段是否缩短 - 收紧
-XX:G1RSetUpdatingPauseTimePercent=10（默认 10%，表示 STW 阶段最多花 10% 时间做 RSet 更新），避免 Update RS 吃掉过多停顿预算 - 若写模式不可控，可尝试增大
-XX:G1RSetScanBlockSize=64（默认 32），减少扫描次数，但会略微增加内存占用 - 禁用
-XX:-G1UseAdaptiveConcRefinement可让 refinement 线程恒定运行，适合写负载稳定的服务；但对峰谷波动大的服务反而容易引发线程争抢
比调参更关键的是写模式治理
很多团队卡在调参上反复横跳，其实根源不在 GC，而在代码写法：
- 避免在循环中新建跨 Region 对象引用：比如
list.add(new User())在大集合里反复执行，会持续触发 card 标记；改用对象池或复用已有实例 - 拆分大对象：单个对象 > Region 大小一半（如 512KB）会进 Humongous 区，其 RSet 维护成本极高；考虑按字段粒度拆成多个小对象
- 预分配 Region：对已知生命周期长的对象图，用
-XX:G1NewSizePercent和-XX:G1MaxNewSizePercent控制年轻代占比，减少晋升频次带来的跨代引用爆炸
Update RS 不是孤立模块，它和你的对象分配节奏、引用拓扑、Region 划分强耦合。日志里那行 Avg: 12.8 背后，往往藏着一段没被 review 过的批量写逻辑。
