G1写屏障性能开销取决于写操作模式、对象分布和JVM版本；JDK26通过JEP522将x86-64指令数从约50条降至12条，吞吐量提升5%~15%，TLB缺失率降10%~20%，分支预测错误率显著降低。
G1 引入写屏障确实会带来可测量的性能开销，但这个“折损”不是固定值，而是取决于写操作模式、对象分布和 JVM 版本。关键不在于回避写屏障，而在于理解它在哪种场景下真正构成瓶颈，以及如何缓解。
写屏障为什么消耗性能
每次对引用类型字段或数组元素执行写操作（比如 obj.field = otherObj 或 arr[i] = obj），JVM 必须插入额外逻辑：判断是否跨 Region、更新目标 Region 的 RSet、维护 SATB 标记一致性。在 JDK 25 及更早版本中，x86-64 平台单次写屏障需约 50 条指令，涉及内存访问、分支跳转和原子操作，显著拖慢高频写路径。
这种开销在以下情况被放大：
- 大量短生命周期对象频繁修改引用字段（如链表节点赋值、缓存更新）
- 密集写入对象数组（如批量构建 DTO 列表、消息体填充）
- 高并发下多线程争用同一 Card Table 或 RSet 结构
JDK 26 起写屏障已大幅轻量化
通过 JEP 522，JDK 26 将 x86-64 上 G1 写屏障指令数从 ~50 条降至约 12 条。这直接带来：
- 吞吐量提升 5%~15%，尤其在写密集型应用中体现明显
- TLB 缺失率下降 10%~20%，减少地址翻译开销
- 分支预测错误率显著降低，提升 CPU 流水线效率
这意味着，如果你仍在使用 JDK 21 或 JDK 17 运行 G1，观察到的 5%~10% 折损是真实存在的；但升级到 JDK 26+ 后，这部分损耗已大幅收窄，甚至在部分基准测试中转为净收益。
比“是否启用”更重要的是“怎么写”
真正影响性能的往往不是写屏障本身，而是写操作引发的连锁反应：
- 避免跨 Region 引用：让强关联对象尽量分配在同一 Region（可通过 -XX:G1HeapRegionSize 调整 Region 大小，使常用对象簇能落入单个 Region）
- 减少不必要的引用更新：例如用原始类型替代包装类字段、复用对象而非反复新建再赋值
- 慎用大对象：≥50% Region Size 的对象会进入 Humongous 区，其写屏障处理更重，且无法被 Young GC 回收，易加剧 RSet 维护压力
- 关闭 G1BarrierSimple 需谨慎：该选项虽可进一步简化屏障逻辑，但仅适用于不依赖精确并发标记的场景（如无复杂跨代引用），默认不建议关闭
别只盯着写屏障，先确认它真是瓶颈
很多应用误将延迟归因于写屏障，实际可能是：
- RSet 增长过快导致并发标记阶段 CPU 占用飙升
- Eden 区过小引发频繁 Young GC，掩盖了写屏障开销
- 对象分配速率过高，触发 Evacuation Failure 或 Full GC
建议用 -Xlog:gc+refine=debug 观察 RSet 更新频率，用 -Xlog:gc+phases=debug 查看 Young GC 中 “Ref Proc” 和 “Evacuation” 阶段耗时占比——若写屏障相关阶段占比低于 10%，优化它带来的收益就非常有限。
