直接看日志里 RSet 刷新耗时和频率即可判断跨代引用是否拖慢 GC；关键看 CCSU 占比是否超 10%、Refine 线程处理脏卡是否滞后（如单次超 2000 张且耗时超 100ms）、Native Memory 中 Internal 区域是否持续攀升超 30%，三者任一成立即表明 RSet 更新已成瓶颈。
直接看日志里 RSet 刷新相关的耗时和频率，就能判断跨代引用是否正在拖慢 GC。关键不是“有没有”，而是“刷新节奏是否跟得上应用写入节奏”。
关注 jstat 中 CCSU 和 CCPU 指标
运行 jstat -gc <pid>，重点盯住这两列：
- CCSU（Concurrent RS Update）：表示并发线程花在 RSet 更新上的总时间（单位：秒）
- CCPU（Concurrent RS Update CPU time）：对应 CPU 时间消耗
如果 CCSU 占整个 GC 周期比例持续超过 10%，或单次 Mixed GC 前后 CCSU 突增明显，说明 RSet 更新已成瓶颈。这不是“偶尔抖动”，而是 Refine 线程长期积压脏卡。
检查 GC 日志里的 RSet 扫描延迟信号
启用 -Xlog:gc+refine=debug 后，日志中会出现类似这样的条目：
[2026-05-23T05:20:14.112+0000][debug][gc,refine] Refinement thread processed 1287 dirty cards (142ms)注意两个数字：
- 处理的 dirty card 数量——若单次超 2000，说明写入密集
- 耗时（如 142ms）——若稳定在 100ms 以上，且与 Young GC 间隔接近，就容易导致 Mixed GC 开始时 RSet 尚未收敛
更危险的是出现 "RSet scan incomplete due to timeout" 或 "Skipping RSet scan for region X"，这代表 GC 主动放弃扫描，漏标风险已实际发生。
结合堆外内存增长反向验证
RSet 元数据存在堆外（Native Memory），不是 Java 堆的一部分。开启 -XX:NativeMemoryTracking=detail 后，用 jcmd <pid> VM.native_memory summary 查看：
- 关注 Internal 区域占用是否随 GC 频次线性上升
- 若 Internal 占比超过总 Native 内存的 30%，且 Thread 和 Code 区域稳定，大概率是 RSet 缓冲区（Dirty Card Queue）持续堆积、Refine 线程消费不过来
此时即使 GC 日志没报错，RSet 已处于“半失效”状态：新跨代引用进不来，旧引用又没及时清理，混合回收效率必然下滑。
定位高产脏卡的代码模式
高频触发 RSet 更新的典型场景有固定特征，可配合 -XX:+PrintGCDetails 和业务监控交叉比对：
- 缓存批量写入：比如
ConcurrentHashMap.putAll()往老年代 map 里塞一批指向年轻代对象的 value - 长生命周期容器持有短生命周期对象：如静态
ArrayList<Future>不断 add 新提交的CompletableFuture - 消息体与元数据跨 Region 分配：例如 Kafka ConsumerRecord 的 header（老年代）引用了 body 中的 byte[]（可能落在年轻代 Region）
这类操作不会立刻报错，但会让 RSet 插入频次陡增，而每条插入都需哈希查找 + 位图更新 —— 开销远高于卡表标记。
