写屏障和卡表协同实现分代gc的高效跨代引用追踪：写屏障在老年代对象引用年轻代对象时触发，通知系统记录跨代写操作；卡表以粗粒度标记对应内存页为脏，gc仅扫描脏页中的老年代对象，大幅减少扫描范围。
写屏障和卡表是分代垃圾回收中协同工作的两个底层机制，核心目标只有一个：让年轻代 GC 不用扫描整个老年代，就能准确找到所有可能引用年轻代对象的老年代对象。
写屏障负责捕获跨代写操作
它不是在每次赋值时都无差别拦截，而是有明确触发条件：只有当老年代对象的某个字段被赋值为一个年轻代对象时，才激活。比如 objA.child = youngObj，其中 objA 在老年代、youngObj 在新生区，此时写屏障就会介入。
- 它不记录具体引用关系，只做一件事：通知系统“这里发生了老→年的引用变更”
- 在 V8 或 HotSpot 中，它以编译期插入的轻量汇编指令形式存在，嵌入在赋值语句前后
- 对 JavaScript 或 Java 开发者完全透明，无需、也不应手动干预
- 年轻代对象引用老年代对象，不会触发写屏障——因为这不影响年轻代 GC 的正确性
卡表是写屏障作用的落脚点
卡表本质是一个字节数组，把堆内存按固定大小（如 512 字节）切分成若干“卡页”，每个字节对应一页。当写屏障检测到跨代写入，就计算出目标对象所在卡页的索引，并把对应字节标记为“脏”（dirty）。
- 例如地址 0x123456 经右移 9 位（÷512）得索引 i，CARD_TABLE[i] = 1
- 它不关心具体哪个对象、哪个字段，只标记“这一块内存里至少有一个跨代引用”
- 这种粗粒度设计大幅节省空间，避免为每个跨代引用单独建表
- 卡表本身不直接参与 GC 根扫描，而是作为记忆集（Remembered Set）的数据源
二者配合实现高效跨代扫描
年轻代 GC 开始前，回收器不遍历整个老年代，而是先扫描卡表中所有“脏”的卡页，定位出这些卡页内的老年代对象，再只检查它们的引用字段是否指向年轻代。
- 实测显示，在大型应用中，90% 以上老年代对象不含跨代引用，真正需要检查的不足 5%
- 记忆集就是由脏卡解析而来，是卡表的逻辑聚合，用于快速构建 GC Roots 子集
- G1 和 V8 都采用类似思路，只是 G1 每个 Region 自带卡表，而 HotSpot 全局一张
- 写屏障若缺失，就会漏标——本该存活的年轻代对象被误回收；卡表若精度太粗，则会多扫——降低效率但不破坏正确性
常见误区与实际影响
写屏障不是内存屏障（Memory Barrier），前者是 GC 层逻辑机制，后者是 CPU 层指令约束；卡表也不是哈希表或链表，它就是一个极简的索引数组。
- 高频修改老年代对象字段会轻微拖慢写性能，但现代引擎已通过条件跳转、延迟标记优化
- 多个线程同时标记相邻卡位可能引发伪共享（false sharing），可通过卡位对齐缓解
- 同代引用（如老→老、年→年）从不触发写屏障，因为 GC 扫描本代时自然覆盖全部对象
- 卡表大小固定，随堆增长线性扩展，但远小于堆本身，典型 HotSpot 卡表仅占堆内存约 0.1%
