Young GC不扫描整个老年代，因为G1为每个Region维护独立RSet，仅记录“谁引用了我”；执行Young GC时，JVM只扫描Eden/Survivor对应RSet中的脏卡，避免全量老年代遍历，使停顿时间与堆总大小解耦。
为什么 Young GC 不扫整个老年代？RSet 是核心答案
因为 G1 的每个 Region 都自带一个 RSet，它只记录“谁引用了我”，而不是“我引用了谁”。当执行 Young GC 时，JVM 只需扫描 Eden/Survivor Region 对应的 RSet，从中提取出所有可能持有跨代引用的老年代 Region 和具体卡页（Card），再针对性扫描这些“脏卡”——完全绕开了全量老年代遍历。
这背后的关键假设是：跨代引用极少。RSet 把“查引用”从 O(整个老年代) 降为 O(活跃脏卡数)，停顿时间因此与堆总大小解耦。
写屏障如何触发 RSet 更新？别忽略它的开销
G1PostBarrier 是 G1 中负责维护 RSet 的写屏障实现。每次执行类似 obj.field = new_obj 这样的赋值，JVM 都会在运行时插入检查逻辑：
- 若
new_obj在年轻代，且obj在老年代，则定位obj所在Region的RSet - 计算
obj地址对应的老年代卡页索引（基于默认512字节卡大小） - 将该卡页标记为“脏”，并把引用关系注册进目标年轻代
Region的RSet
这个过程比 CMS 的写屏障更重——G1 要维护多对多映射（多个老 Region → 一个年轻 Region），所以高频修改老对象指向新生代的场景（如缓存 value 替换），会显著拖慢 mutator 线程，并推高 Young GC 前的 RSet 扫描耗时。
RSet 和 Card Table 到底什么关系？别混淆层级
Card Table 是底层内存划分机制，RSet 是上层逻辑结构：
-
Card Table是一个全局byte[]，把老年代按512字节切块，每块用 1 字节标记是否“脏” -
RSet是每个Region自带的数据结构，内容是“哪些老 Region 的哪些卡页里有指向我的引用” - 一个脏卡被扫描时，实际要遍历该卡内所有对象，检查其字段是否真指向本
Region；精度损失不可避免——哪怕只有 1 个引用，整张卡都要扫
也就是说：Card Table 决定“扫哪几块”，RSet 决定“这些块属于谁、该加到哪个 Region 的 GC Roots 里”。两者协同，但不是同一物。
RSet 内存开销有多大？Region 大小调得太小会踩坑
RSet 本身占堆内存，且不计入常规对象统计——它是 HotSpot VM 的原生内存分配，GC 日志里看不到，但压测时能观测到 RSS 明显升高。
影响因素很直接：
-
-XX:G1HeapRegionSize越小 →Region数越多 →RSet实例越多 → 总内存占用越大 - 默认
Region大小是2MB，若手动设为1MB或512KB，RSet开销可能上涨 2–4 倍 - 应用若大量使用老年代对象持有弱/软引用指向新生代（如某些连接池、事件总线），RSet 条目会密集增长
真正容易被忽略的是：RSet 占用不会触发 GC，但会挤压可用堆空间，间接导致更频繁的 GC——尤其在堆接近满载时，这种隐性压力会让问题变得难定位。
