RSet扫描成Mixed GC瓶颈，表现为RSet内存占比超1.5%或扫描超20ms；需调大RegionSize匹配缓存块、降低RSet条目、调整G1MixedGCCountTarget和OldCSet阈值，并收拢缓存写入以减少跨Region引用。
Region 活跃度高但 GC 停顿不降，说明 RSet 扫描成了瓶颈
缓存类应用（如商品、店铺、会话）常出现“Region 分配多、存活对象少、但 Mixed GC 耗时飙升”的现象。这不是因为对象没回收，而是每个 Region 的 Remembered Set（RSet）被高频更新——比如本地缓存 Map 里存了大量跨 Region 引用的 Value 对象，每次更新都会触发 write barrier，导致 RSet 条目暴涨。
关键判断：RSet 内存占比超过堆的 1.5% 或 GC 日志中 [RSet: XMB, Y entries] 后紧跟 [scan: Zms] 超过 20ms，基本可确认是 RSet 扫描拖慢 Mixed GC。
- 用
jstat -gc查看HU（Humongous Used）列，若持续 >5%，说明大对象频繁，RegionSize 太小，被迫进 Humongous 区，绕过 RSet 管理，反而让引用关系漏检 - 加
-Xlog:gc+remset*=debug（JDK 11+），重点观察Total remembered set memory占比和Scanned cards per region是否集中在少数几个 Region - 避免用
-XX:+PrintGCDetails试图找“卡表命中率”——G1 已弃用全局 Card Table，日志里没有这个指标
RegionSize 不是越大越好，得匹配缓存块大小
电商小时购系统批量更新商品缓存时，常分配 2–8MB 的 PooledByteBuf 或 byte[] 缓冲区。若仍用默认 1MB Region，一个缓冲区就得跨 2–8 个 Region，每个 Region 都要维护指向它的 RSet 条目，引用密度翻倍。
实测有效策略：把 -XX:G1HeapRegionSize 设为常见缓存块大小的 1.2 倍，例如：
- 主流缓存块为 4MB → 设
-XX:G1HeapRegionSize=4M - 存在较多 6MB 商品快照 → 设
-XX:G1HeapRegionSize=8M（必须是 2 的幂） - 若
jstat显示 Young GC 频次骤增、Eden 区 Region 数跳变，说明G1NewSizePercent和G1MaxNewSizePercent未同步调整，需用jstat -gc验证新生代 Region 实际数量
混合回收（Mixed GC）阶段优先级错位，导致老缓存滞留
G1 回收不是按“代”而是按 Region 活跃度排序。缓存系统里，刚写入的热点数据（如新上架商品）和长期未访问的冷数据（如半年前下架商品）可能混在同一个 Old Region 里。G1 默认按“垃圾占比”选 Region，结果冷数据 Region 因存活率低被优先回收，而真正该清理的旧缓存（因引用链长、存活率虚高）却被跳过。
解决办法不是关掉 Mixed GC，而是引导它盯住缓存生命周期：
- 给缓存对象加业务标记字段（如
cacheTTL），在 GC 前主动System.gc()触发一次并发标记，再用-XX:G1MixedGCCountTarget=8（默认 8）拉长 Mixed GC 轮次，让冷数据有更多机会暴露 - 若使用
WeakReference或SoftReference管理缓存，注意 G1 对软引用的清理策略更激进，-XX:SoftRefLRUPolicyMSPerMB可能需要调小（如设为 1000） - 禁用
-XX:G1OldCSetRegionThresholdPercent的默认值（默认 10%），对缓存密集型服务设为 5%，让更小比例的“低价值” Old Region 进入回收集
Region 划分影响跨节点缓存一致性延迟
分布式缓存更新常伴随远程调用（如发 MQ、调下游服务）。这些调用对象（如 KafkaProducerRecord、OkHttpClient 请求体）若分配在不同 Region，且彼此强引用，就会推高 RSet 更新频率。更隐蔽的问题是：RSet 更新本身不保证顺序，当多个线程并发修改跨 Region 引用时，可能导致某次 Mixed GC 扫描到“半更新”状态，进而漏掉应清理的缓存条目。
这不是 GC bug，而是设计约束。缓解方式很务实：
- 把缓存写入逻辑尽量收拢到单个线程或 Actor 模型中，减少跨 Region 引用的并发写入点
- 避免在
finalize()或 Cleaner 中做缓存清理——G1 下finalize触发不可控，容易堆积 - RegionSize 改动后，务必验证
G1ConcRefinementThreads（默认 3）是否足够：若日志中频繁出现Concurrent refinement overflow，说明 RSet 更新线程跟不上，需设为 CPU 核数的 1/4
Region 活跃度分析不能只看 GC 日志里的“回收了多少”，得结合缓存访问模式反推哪些 Region 其实是“伪活跃”——比如一个 Region 里全是 String key 和 WeakReference value，它物理上没多少垃圾，但 RSet 会被反复更新，这种 Region 就是隐形瓶颈。
