Dirty Card Queue 背压是 G1 GC 中跨 Region 写操作引发的性能瓶颈，表现为 Update RS 耗时升高、TPS 下滑、Mixed GC 频繁但老年代存活率低；需结合 G1ConcRefinementThreads 与 G1RSetUpdatingPauseTimePercent 协同调优，并治理高频跨 Region 写模式。
Update Log Buffer 并不是 G1 GC 的标准术语——这是个常见误称，实际想指的通常是 Dirty Card Queue（脏卡队列），即 G1 用来暂存跨 Region 写操作记录的线程本地缓冲区。它不叫“日志缓冲区”，也不属于 redo log 或 binlog 体系，和 MySQL 的 log buffer 完全无关。
怎么确认你的应用正被 Dirty Card Queue 背压拖慢
G1 在每次跨 Region 写操作时，通过写屏障（write barrier）把对应内存页（card）标记为 dirty，并追加到当前线程的 Dirty Card Queue。这个队列满时，线程会阻塞等待刷新，直接表现为应用写延迟突增、TPS 下滑、GC 日志中 Update RS 耗时异常。
- 查看 GC 日志里
Update RS(ms)行：若Avg > 10ms或Max > 30ms，基本可判定 RSet 更新已成瓶颈 - 同时观察
Ext Root Scanning(ms)是否同步上涨：说明 GC 线程在等 RSet 刷新完成，进一步拖慢 Mixed GC - 出现大量
GC pause (G1 Evacuation Pause)(mixed)但老年代实际存活率不高：RSet 滞后导致回收集选错
注意：Dirty Card Queue 不是全局共享队列，每个应用线程都有自己的副本；所以高并发写场景下，不是“一个队列满了”，而是“几十个队列几乎同时满”，放大阻塞效应。
G1ConcRefinementThreads 和 G1RSetUpdatingPauseTimePercent 怎么调才不翻车
这两个参数控制的是“谁来刷队列”和“刷多久”，但它们之间有隐含依赖关系：
-
G1ConcRefinementThreads决定后台并发线程数，默认值是 CPU 核数 × 0.6（向下取整），最小为 1 -
G1RSetUpdatingPauseTimePercent是年轻代 GC 中允许花在Update RS上的时间占比，默认 10（即 10%）
常见错误配置：
- 只加大
G1ConcRefinementThreads却不调G1RSetUpdatingPauseTimePercent→ 后台线程空转，GC 时仍抢不到时间刷队列 - 把
G1RSetUpdatingPauseTimePercent设太高（如 25）→ 年轻代 GC 停顿拉长，接口 P99 直接破 200ms - 设
G1ConcRefinementThreads=1但并发写线程超 20 → 队列积压永远清不完
实操建议：
- 先用
jstat -gc -t <pid> 1s</pid>观察EC（Eden 使用量）和YGC频率，确认是否真由写屏障背压引起 - 若
Update RS耗时高且Processed Buffers数值波动剧烈（如单次从 5 跳到 800），优先加G1ConcRefinementThreads到 CPU 核数的 1–1.5 倍 - 再微调
G1RSetUpdatingPauseTimePercent：从默认 10 开始，每次 ±2 测试，配合 GC 日志看Update RS(ms)是否收敛
为什么光调参没用？必须配合写模式治理
Dirty Card Queue 是症状，不是病因。突发写操作（如批量导入、实时聚合、消息消费堆积）本质是短时间内制造大量跨 Region 引用，而 G1 的 Region 默认大小是 1–4MB（取决于堆大小），小对象频繁跨 Region 分配，天然推高脏卡数量。
典型高危写模式：
- 每次新建一个大 List 放几百个对象，然后 add 进 Map → 大量对象在不同 Region 分配，Map 引用它们 → 跨 Region 写爆炸
- 使用
new byte[1024*1024]拆分大消息，但未对齐 RegionSize → 小对象散落各处，引用链横跨多个 Region - 动态代理类 + 缓存对象混合写入，触发元空间与堆间交叉引用 → 写屏障额外触发 ClassLoader 关联检查
有效缓解手段（比调参更治本）：
- 预分配容器：用
ArrayList<t>(expectedSize)</t>避免扩容引发的对象迁移 - 对象复用：ThreadLocal 缓存临时 DTO，或用对象池管理高频创建的小对象
- 拆分大对象：确保
byte[]或char[]大小接近G1HeapRegionSize的整数倍，减少跨 Region 引用 - 避免无意义跨 Region 引用：比如把缓存 key 和 value 放在同一个 Region（可通过 -XX:+UseStringDeduplication 或自定义分配策略辅助）
真正卡住你的从来不是参数数字，而是那些在 GC 日志里不显眼、但在 Update RS 耗时里持续累积的跨 Region 写操作。队列满了可以调线程数，但写法不改，只是把背压从 GC 阶段转移到应用线程阻塞上——延迟不会消失，只会换个地方爆发。
