java写屏障通过自动插入代码标记卡表脏卡来追踪跨代引用，核心是计算地址索引、原子写入dirty值，并支持过滤与批量优化，确保分代gc高效准确。
Java 中的写屏障（Write Barrier）在垃圾回收器（如 G1、CMS）中用于维护卡表（Card Table），核心目标是：当对象引用发生变更时，快速标记“可能包含跨代引用”的内存区域，避免全堆扫描。卡表本身是一块连续的字节数组，每个元素（card）对应堆中一块固定大小的内存区域（如 512 字节），值为 clean（0）或 dirty（非 0）。
写屏障如何触发卡表更新
每当执行类似 obj.field = otherObj 的引用写入操作时，JVM 在编译或解释执行阶段会自动插入写屏障代码（通常由 JIT 或解释器生成）。该屏障判断目标字段所在的内存地址是否属于“年轻代”，且被赋值的对象（otherObj）位于老年代——若满足，则需标记该字段所在 card 为 dirty。
关键步骤包括：
- 计算字段地址对应的卡表索引：
card_index = (address >> card_shift) & card_table_mask（card_shift通常为 9，对应 512 字节） - 原子写入卡表数组对应位置为
dirty值（如 0xFF），确保多线程下不丢失标记 - 部分 GC（如 G1）还会进一步将脏卡加入“记忆集”（Remembered Set）缓冲区，后续并发处理
卡表更新的时机与优化
并非每次写操作都立即更新卡表。JVM 会做轻量级过滤以减少开销：
- 只对老年代对象的字段写入生效（年轻代对象间的引用不影响跨代收集）
- 若被写入字段本身就在老年代（如 static 字段），且新值也是老年代对象，可跳过（无跨代意义）
- G1 使用“后置写屏障”（Post-barrier），延迟批量处理；CMS 则用“卡表+二次标记”机制降低误标率
开发者无需手动干预，但需注意影响点
卡表维护完全由 JVM 自动完成，Java 代码无法直接访问或修改卡表。不过以下情况会影响其效率和准确性：
- 频繁修改老年代对象指向年轻代对象的字段（如缓存、监听器列表），会持续触发写屏障，增加 CPU 开销
- 使用反射或 Unsafe 写入对象字段，可能绕过写屏障（取决于 JVM 实现和选项），导致漏标、GC 错误回收
- 开启
-XX:+UseCondCardMark可使写屏障先检查 card 是否已为 dirty，避免重复写入（节省缓存行失效开销）
卡表是写屏障落地的关键数据结构，它用极小空间代价换取了分代 GC 的高效性。理解其触发逻辑有助于写出对 GC 更友好的代码，比如减少老-新跨代引用的高频更新。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
