跨代引用迫使gc扫描老年代中可能指向年轻代的引用，记忆集（rset）通过卡表和写屏障精准标记脏卡页，避免全老年代扫描；g1为每个region维护独立rset，提升并发效率但增加内存与性能开销，cms则仅用粗粒度卡表，不维护rset，导致浮动垃圾增多。
跨代引用为什么会让GC变慢
新生代GC（比如Minor GC）只扫描年轻代对象，但若老年代对象引用了年轻代对象，就可能漏掉本该回收的年轻代对象——所以JVM必须知道“哪些老年代区域可能持有对年轻代的引用”，否则就得扫描整个老年代，开销爆炸。
记忆集（Remembered Set，简称RSet）就是干这个的：它记录了老年代中哪些内存块（比如卡页）里存有指向年轻代的引用。每次老年代对象修改引用时，JVM会检查目标是否在年轻代，若是，就标记对应卡页为“脏”。后续Minor GC只需扫描这些脏卡页里的对象，而不是整块老年代。
-
RememberedSet不是Java代码能直接访问的类，而是HotSpot VM内部结构，由GC算法（如G1、ZGC）自动维护 - 卡表（Card Table）是RSet的底层实现之一：把老年代划分为512字节/块的“卡”，每卡用1字节标记是否脏；
card table本身是byte数组，地址映射靠位运算计算 - 写屏障（Write Barrier）是触发卡表更新的关键机制：所有
obj.field = new_obj这类赋值，在编译后都会插入一段检查逻辑，判断new_obj是否在年轻代，是则标记对应卡为脏
G1中的RSet和卡表怎么配合工作
G1把堆切成大小相等的Region，每个Region都维护一个独立的RSet，记录“谁指向我”。这比全局卡表更精细：比如Region A的RSet里存着Region B、C中具体哪些卡页改写了对A的引用。
这种设计让并发标记和混合GC更高效，但也带来额外内存开销——RSet本身要占堆空间，且Region越小、RSet数量越多，总开销越大。
立即学习“Java免费学习笔记（深入）”；
- 默认卡页大小是512字节，不可配置；
-XX:G1HeapRegionSize影响Region大小，间接影响RSet粒度 - RSet更新由
G1PostBarrier写屏障触发，它比CMS的卡表写屏障更重（因需维护多对多映射），所以G1对mutator性能影响略高 - 如果应用频繁在老年代对象中修改指向新生代的引用（如缓存池反复替换value），会导致大量卡页变脏，Minor GC前扫描RSet变慢——这是
Young GC time increasing的常见隐形原因
为什么CMS不依赖RSet而用卡表就够了
CMS是“标记-清除”老年代收集器，它不移动对象，也不做跨代精确扫描；它的跨代引用处理很粗暴：在Minor GC时，直接把整个young_gen加入GC Roots，并扫描老年代中所有已知的“跨代引用卡页”（即卡表中标记为脏的页）。
也就是说，CMS的卡表只用于避免全老年代扫描，不构建对象级引用关系，也没有Region级RSet的概念。
- CMS启用卡表靠
-XX:+UseConcMarkSweepGC自动开启，卡表结构与G1相同，但语义不同：CMS卡表只标记“可能含跨代引用”，不区分引用方向或目标Region - 因为不维护RSet，CMS在老年代并发标记阶段无法知道“哪个老年代对象被年轻代引用”，所以无法提前清理无用跨代指针，容易导致浮动垃圾增多
- 一旦出现
Concurrent Mode Failure，CMS被迫退化为Serial Old，此时卡表失效，所有跨代引用逻辑回退到全堆扫描
排查RSet相关性能问题的实际抓手
没有直接日志说“RSet太大”，但可以从GC日志里反推：关注Minor GC中[RS]和[SATB]阶段耗时（G1），或[CardTableScanning]时间（CMS）。这些字段背后就是RSet操作。
另外，jstat -gc <pid></pid>输出里的EC（Eden Capacity）、EU（Eden Used）变化正常，但YGC次数没涨、YGCT却飙升，大概率是RSet扫描拖慢了。
- 用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps打开详细GC日志，找类似[RS Threads: 8]或[Update RS (ms): Min: 0.2, Avg: 1.7, Max: 4.3]这样的行 - G1下可加
-XX:+G1PrintRegionLivenessInfo看各Region RSet大小，但仅限调试，生产慎用（性能损耗大） - 真正压测时发现RSet相关阶段占比持续＞30%，说明跨代引用太密集——这时该检查业务代码：是不是在静态map里长期持有新创建的对象？或者用
ThreadLocal<object></object>存了短命对象？
跨代引用本身无法消除，但RSet的负担取决于“谁在什么时候改了什么引用”。写屏障开销藏得深，日志不报错，只悄悄拖慢GC——这点最容易被忽略。
