G1的RSet只记录老年代→年轻代引用，因年轻代对象生命周期短，其引用老年代对象不影响后者的存活判定；而年轻代回收需避免扫描全老年代，故必须记录反向引用以保障安全回收。
为什么 G1 的 RSet 只记录老年代→年轻代引用
因为年轻代对象生命周期短，它引用老年代对象不会影响老年代对象的存活判定——老年代回收时，自身 Region 的引用链 + 自身 RSet 已足够判断存活；而年轻代回收时，若不记录老年代→年轻代的引用，就得扫描整个老年代找 GC Roots，停顿直接失控。
写屏障只在 G1PostBarrier 中对老年代写入年轻代字段触发更新，伪代码逻辑类似：
if (is_old_to_young(field, new_val)) {
add_to_rs(region_of(field));
}
年轻代→老年代的赋值被完全跳过。实测中，这类引用占全部跨代写操作约 15%，但维护成本高、记录价值低——大量 young→old 引用随 Minor GC 消失，RSet 却要为“瞬间死亡”的引用分配空间和更新开销。
- 老年代→年轻代引用：必须记录，否则 Young GC 无法安全回收
- 年轻代→老年代引用：不记录，老年代回收本身就要遍历自身对象图
- 同 Region 内引用：从不记录，RSet 仅服务于跨 Region 场景
RSet 更新延迟如何拖慢混合回收（Mixed GC）
RSet 不是实时更新的，它依赖 G1ConcRefinementThreads 线程从脏卡队列异步构建。当应用写入频繁（如缓存批量 put、长生命周期 Map 持有年轻代对象），脏卡堆积会导致 RSet 扫描滞后——Mixed GC 开始时，RSet 还没反映最新跨区引用，GC 就可能漏标存活对象，触发 Concurrent mode failure 或被迫扩大根集合，Evacuation 时间飙升。
典型信号包括：
-
jstat -gc <pid></pid>中CCSU（Concurrent RS Update）时间占比持续 >10% - Young GC 后紧跟着一次 Mixed GC，且
G1EvacuationPause明显变长 - 堆外内存（Native Memory）使用量异常增长，
NativeMemoryTracking显示Internal区域占用突增
这不是 GC 策略问题，而是 RSet 生产消费失衡——Refine 线程跟不上写屏障节奏。
卡表（Card Table）和 RSet 是什么关系
卡表是 RSet 的底层支撑，不是替代品。卡表以 512 字节为单位（-XX:CardTableEntrySize 默认值）把老年代切分成“卡页”，写屏障只标记对应卡页为 dirty；RSet 则是在 Refine 线程里，对 dirty 卡页做精确扫描后，汇总出“哪些 Region 引用了当前 Region”的映射表。
换句话说：
- 卡表回答：“哪块内存可能有跨代引用”（粗粒度、快）
- RSet 回答：“具体是哪个 Region 在引用我”（细粒度、准）
- 两者配合，才能让 Young GC 只扫描少数几个老年代 Region，而不是全堆
如果卡表误标（比如伪共享导致多线程反复标记同一卡页），RSet 构建就会做无用功；反过来，如果卡表漏标（极罕见），RSet 就永远收不到那条引用，Young GC 必然错杀对象。
RSet 内存开销为什么常被低估
RSet 存在堆外（Native Memory），不受 -Xmx 控制，但受 -XX:MaxDirectMemorySize 和系统资源约束。一个 Region 的 RSet 大小取决于外部跨区引用数量，而非 Region 自身大小。高频跨 Region 引用场景（如分片缓存、Actor 模型中的 mailbox 引用）会让 RSet 占用数 GB 堆外内存——这不会触发 OOM，但会挤压元空间、压缩线程栈甚至引发系统级内存压力。
排查时注意：
- 用
jcmd <pid> VM.native_memory summary</pid>查看Internal分类增长 - 避免老年代对象长期持有年轻代临时对象（例如
ConcurrentHashMap<string list>></string>中的List是年轻代分配） - 混合回收阶段 RSet 扫描开销与引用密度呈近似线性关系，不是常量
最隐蔽的问题是：RSet 本身不参与三色标记，但它决定哪些 Region 要被加入根集合——这个决策一旦出错，后续所有标记都不可靠，而错误表现却像“随机 Full GC”或“对象提前消失”。
