rset解决跨region引用扫描爆炸问题，是g1中记录“谁引用了我”的反向索引结构；它使young gc无需扫描全老年代，仅检查rset所列源region的脏卡页，大幅降低停顿时间。
Remembered Set（RSet）解决什么问题
G1 的 RSet 是为了解决跨 Region 引用扫描爆炸问题而设计的反向索引结构。它不记录“我引用了谁”，而是精确维护“谁引用了我”。没有 RSet，每次 Young GC 都得扫描整个老年代找指向年轻代的引用，停顿时间随堆大小线性增长；有了 RSet，GC 只需检查那些真正可能持有跨 Region 引用的源 Region 的卡页，把扫描范围从“全堆”压缩到“几个 Region 的部分卡页”。
RSet 的实际更新时机和触发条件
RSet 并非实时同步更新，而是依赖写屏障（write barrier）+ Dirty Card Queue + Refinement 线程异步精炼。只有发生跨 Region 赋值时才会触发记录，例如：oldObj.field = youngObj 或 oldObj.map.put("k", youngObj)。注意以下几点：
- 同 Region 内的对象赋值（如
obj1.field = obj2，两者都在同一个 Region）不会触发 RSet 更新 - 仅当目标对象（
youngObj）所在 Region 是年轻代，且源对象（oldObj）在老年代或其他 Region 时，才写入目标 Region 的 RSet - 频繁修改 Map/ConcurrentHashMap 的 value（尤其 value 是年轻代对象），会持续触发写屏障，推高 RSet 维护开销
RSet 膨胀和性能瓶颈的典型信号
RSet 本身不存对象地址，只存“Region A 的第 X 张卡页里有引用指向我”，所以它的内存占用取决于“被多少 Region 引用”，而非自己 Region 里有多少对象。容易踩坑的地方包括：
-
[RSet: 128MB, 4.2M entries]占堆比例超过 1.5%，或日志中紧跟着[scan: 38ms]>20ms，说明 RSet 扫描已成瓶颈 -
-XX:G1HeapRegionSize=512K导致 Region 总数暴增（比如 32GB 堆 → ~65536 个 Region），RSet 元数据吃掉大量堆外内存 - 缓存类应用高频更新
ConcurrentHashMap，value 对象分散在多个小 Region 中，每个都被不同老年代 Region 引用，RSet 条目数飙升
调优 RSet 的三个实操动作
不是调参数，而是改行为和结构：
- 按业务对象块大小选
-XX:G1HeapRegionSize：电商商品快照平均 4MB，就设4M；缓冲区常见 6–8MB，选8M（必须是 2 的幂） - 收拢写入路径：用对象池复用
PooledByteBuf，避免 value 对象在多个 Region 间跳来跳去；把 key-value 关联数据尽量分配在同一 Region - 辅助 GC 识别冷热：给缓存 entry 加
cacheTTL字段，让 G1 在 Mixed GC 选区时能区分“垃圾多但已过期”的 Region，减少无效 RSet 扫描
RSet 的复杂性不在代码层面，而在它把写屏障、卡页队列、Refinement 线程、Region 分配策略全部耦合在一起——改其中一环，其他环节的负载可能陡变。观察 GC 日志时，别只盯 [RSet: XMB]，要连着看它后面的 [scan: Yms] 和 [refine: Zms] 才算真正看清 RSet 的实际开销。
