rset是g1收集器中每个region独立维护的堆外反向索引结构，精准记录跨region引用来源，使young gc仅扫描少量脏卡而非全老年代，从而实现停顿时间与堆大小解耦。

Remembered Set（RSet）是 G1 收集器实现低延迟回收的关键基础设施，它不解决“我引用了谁”，而是精准回答“谁引用了我”——尤其聚焦于跨 Region 的反向引用，让年轻代 GC 能跳过全量老年代扫描。

RSet 的本质：每个 Region 自带的反向索引本

RSet 不是全局大表，也不是 Card Table 的复制品，而是一个 Region 级别的、堆外存储的哈希表 + 卡页位图结构。它只登记“哪些其他 Region 的哪些卡页里，存在指向本 Region 的引用”。例如：Region A 中的对象被 Region B（老年代）中的对象引用，那么 Region A 的 RSet 就会记录一条“B→A”的映射，并标记 B 中对应卡页为脏。

• 每个 Region 独立维护自己的 RSet，互不共享
• 仅记录跨 Region 引用，同 Region 内引用从不进入 RSet
• 只追踪老年代 → 年轻代/其他老年代的写入，年轻代 → 老年代的赋值不触发 RSet 更新
• RSet 内存分配在堆外（HotSpot 的 Native Memory），不参与 GC 统计，但真实占用 RSS

为什么必须有 RSet：避免 Young GC 停顿失控

没有 RSet，G1 在年轻代回收时就无法知道哪些老年代对象正持有对 Eden/Survivor 中对象的强引用。只能退化为把整个老年代加入 GC Roots——停顿时间随堆大小线性增长，彻底丧失低延迟特性。

• Young GC 实际只扫描 Eden/Survivor Region 对应的 RSet，从中提取出“可能持有引用”的老年代 Region 和脏卡范围
• 扫描粒度从“全老年代”降为“少量脏卡”，使停顿时间与堆总大小解耦
• 混合回收（Mixed GC）同样依赖 RSet，精准定位待回收 Old Region 的外部引用来源

RSet 如何更新：写屏障驱动，非实时同步

RSet 更新完全由 G1PostBarrier 写屏障触发，不是自动或周期性行为。每次发生跨 Region 赋值（如 oldObj.field = youngObj），JVM 插入检查逻辑：

• 判断目标字段所在 Region 与新值所在 Region 是否不同
• 若跨 Region，定位源 Region（oldObj 所在）的卡页索引（默认 512 字节/卡）
• 将该卡标记为 dirty，并交由并发 Refine 线程异步处理，最终注册进目标 Region（youngObj 所在）的 RSet

这个过程有开销：高频写入（如缓存批量更新）会导致 dirty card 积压、Refine 线程跟不上，进而引发 Concurrent Mode Failure 或 RSet 扫描滞后。

RSet 的调优关键点：粒度、密度与节奏平衡

RSet 性能瓶颈往往来自三方面失衡：Region 太小导致实例爆炸、跨 Region 引用太密导致哈希冲突、Refine 线程太少导致更新延迟。

• Region Size 选择：默认 2MB；堆 ≥32GB 可设为 4M 或 8M；避免设为 512KB（RSet 实例翻倍，堆外内存碎片激增）
• 控制引用密度：避免老年代长期持有大量新生代临时对象（如 Map> 中 DTO 分配在 Eden）
• 提升 Refine 吞吐：增加 -XX:G1ConcRefinementThreads（默认 6，高写场景可设为 12–16）
• 监控信号：jstat -gc 中 CCSU（Concurrent RS Update）占比持续 >10%，或 GC 日志中 [RSet: XMB, Y entries] 后 [scan: Zms] >20ms，即需干预