Survivor复制带宽损耗在G1中称为RSet更新开销而非“拷贝带宽”，因为瓶颈在于跨Region引用的Remembered Set维护，而非内存搬运本身；其耗时源于卡表标记、写屏障及并发refinement处理。
为什么 Survivor 复制带宽损耗在 G1 里不叫“拷贝带宽”而是 RSet 更新开销
因为 G1 中 Survivor 区本身不是固定物理区域，而是由若干个动态分配的 Region 扮演；对象从 Eden 复制到 Survivor 时，真正耗时的瓶颈往往不在内存搬运本身，而在维护跨 Region 引用的 RSet（Remembered Set）。每次复制一个对象，若它被其他 Region 中的对象引用，G1 就得更新目标 Region 的 RSet —— 这个过程涉及卡表（Card Table）标记、并发写屏障、以及后续的并发 refinement 线程处理，实际吞吐受限于这些元数据操作，而非 memcpy 带宽。
如何定位 Survivor 复制阶段的真实瓶颈：看 GC 日志里的 Ref Proc 和 RS Update 时间
启用详细 GC 日志后（-Xlog:gc*,gc+refine*,gc+region*=debug），重点关注 Young GC 日志中以下字段：
-
[Ref Proc: X.Xms]：处理软/弱/虚等引用的时间，若占比高，说明大量短生命周期对象持有可回收引用，需检查缓存或监听器泄漏 -
[RS Update: Y.Yms]：RSet 更新耗时，直接反映跨 Region 引用写入压力；超过 5ms/次 Young GC 就值得警惕 -
[Evacuation Failure]或[to-space exhausted]：说明 Survivor 区（即目标 Region）空间不足，触发提前晋升，此时会绕过复制但加重 Old 区压力
影响 Survivor 复制效率的关键参数与陷阱
以下配置看似无关，实则显著放大 RSet 开销：
-
-XX:G1HeapRegionSize=1M：Region 越小，相同堆大小下 Region 数越多 →RSet数量指数级上升 → 每次 Young GC 更新 RSet 的总开销飙升 -
-XX:MaxGCPauseMillis=50且堆 >16GB：G1 会强制缩小 Eden 区以满足停顿目标 → 更频繁的 Young GC → 更多复制 + 更多 RSet 更新 - 大量使用
ThreadLocal或ConcurrentHashMap：它们内部常含跨 Region 引用（如 value 指向堆外对象），导致 RSet 高频 dirty card 标记 - 未禁用
-XX:+UseStringDeduplication：字符串去重会在 Young GC 后额外扫描对象图，干扰 Survivor 复制路径
实操建议：用 jstat 和 jcmd 快速验证是否是 RSet 成为瓶颈
运行中服务可执行：
jstat -gc <pid> 1000 3
观察 EC（Eden 当前容量）、EU（Eden 已用）、YC（Young GC 次数）变化速率；若 YC 激增但 EU 始终低于 70%，说明 Eden 提前耗尽 —— 很可能是 Survivor 区碎片化或 RSet 更新阻塞了 Region 分配。
再执行：
jcmd <pid> VM.native_memory summary scale=MB
检查 Internal 类别是否持续增长（G1 的 RSet 元数据就计入此处），超过 200MB 且随 GC 次数线性上升，基本锁定 RSet 内存与更新开销双高。
真正难调的点在于：RSet 开销无法通过单个 JVM 参数关闭或绕过，它内生于 G1 的分区模型。你得在 Region 大小、停顿目标、对象生命周期分布之间做权衡，而不是期待“优化掉”它。
