G1 RSet更新压力核心在于跨Region引用密度过高，而非对象数量多；需通过调大Refinement线程、合理设置RegionSize（匹配业务对象大小）、拆分全局缓存及复用对象等手段收敛引用密度与更新节奏。

G1 收集器处理海量对象引用带来的 RSet 更新压力，核心不是“压住写”，而是控制跨 Region 引用的密度与更新节奏。RSet 本身不记录所有引用，只登记“谁引用了我”（point-in），但一旦引用关系频繁跨越 Region 边界，就会触发写屏障 → 填充 Dirty Card Queue → 并发 Refinement 线程处理 → 最终更新目标 Region 的 RSet。这个链路在高写场景下极易形成背压，表现为 Young GC 中 Update RS 时间飙升、应用线程卡在写屏障、甚至 Evacuation Failure。

RSet 更新压力的真实来源不是对象多，而是跨 Region 引用太密

• 同一 Region 内的对象互相引用，完全不进 RSet；
• 老年代对象长期持有大量新生代对象（如全局缓存、静态 Map、连接池元数据），会让一个 Region 的 RSet 条目爆炸式增长；
• Region 越小（如 -XX:G1HeapRegionSize=1M），相同堆下 Region 数越多 → RSet 实例越多 → 总内存占用和更新开销非线性上升；
• 频繁修改老对象字段指向新对象（如 cache.put(key, new Value())），每次赋值都触发写屏障 + 卡页标记 + RSet 注册。

关键定位信号：别只看 GC 时间，要看结构占比

• 启用 -Xlog:gc+phases=debug,gc+refine=debug，关注 Young GC 日志中：
  • [Update RS (ms): Avg: X.X, Max: Y.Y] —— 若 Avg > 10ms 或 Max > 30ms，已属高风险；
  • [Ext Root Scanning: Z.Zms] 同步上涨，说明 RSet 扫描拖慢根集合构建；
  • 日志出现 DirtyCardQueueSet::apply_closure_to_completed_buffer 耗时突增，表明 Dirty Card Queue 溢出或 Refinement 滞后。

从配置与代码两个层面同步收敛压力

• 调整并发 Refinement 能力：

  • 增加 -XX:G1ConcRefinementThreads（建议设为 min(8, CPU核数/2)），避免 Refinement 线程跟不上写屏障节奏；
  • 可微调 -XX:G1RSetUpdatingPauseTimePercent（默认 10），临时放宽 GC 内 RSet 更新时间上限（如设为 15），但需配合观察 Evacuation 时间是否恶化。

• 控制 Region 粒度与引用分布：

  • 检查 jstat -gc <pid> 中 HU（Humongous Used）占比，若持续 > 5%，说明 Region 太小，大对象被迫进 Humongous 区 → 加剧碎片和 RSet 边界；
  • 根据主流对象大小选 RegionSize：2–8MB 缓冲区 → 设 2M 或 4M；高频小 POJO → 保持 1M 即可；
  • 避免 -XX:G1HeapRegionSize 设为非 2 的幂（如 3M），JVM 启动直接失败。

• 重构高频跨代引用模式：

  • 全局静态缓存（如 ConcurrentHashMap<String, Xxx>）是 RSet 头号杀手，改为按业务域拆分、加生命周期控制、或使用软/弱引用 + 显式清理；
  • 减少老年代对象对新生代临时对象的强持有，例如用 ThreadLocal 替代静态上下文、用对象池复用而非反复 new；
  • 对批量写场景（如消息消费、报表导出），预分配对象、复用容器、避免中间态对象逃逸到老年代。

RSet 不是瓶颈本身，而是应用内存布局与引用模式的一面镜子。压力大，往往意味着对象分配不聚、生命周期混杂、共享结构过度中心化。优化方向始终是：让相关对象尽量落在同一个 Region，让跨 Region 引用尽可能稀疏、短暂、可控。