卡表机制通过将老年代划分为512字节卡页并用字节数组标记“可能含跨代引用”的脏页，使minor gc仅扫描脏页而非全老年代，从而以极小写入开销实现gc扫描范围的指数级压缩。
Java内存模型中，跨代引用与卡表（Card Table）的设计核心，是用极小的写入开销换取GC扫描范围的指数级压缩——它不追求精准定位引用，而专注高效圈定“可疑区域”。
为什么必须处理跨代引用
年轻代回收（Minor GC）只清理Eden和Survivor区，但老年代对象可能正持有对年轻代对象的引用。若忽略这些引用，被引用的年轻代对象会被误判为垃圾，导致程序出现NullPointerException或数据丢失。全量扫描老年代虽能保证正确性，但面对GB级堆内存，停顿时间会飙升至百毫秒以上，无法满足低延迟要求。
卡表不是引用地图，而是脏页线索表
Card Table本质是一个字节数组，每个byte对应老年代中512字节的内存块（即一个“卡页”）。初始全为0（clean），仅当老年代对象字段被赋值为指向年轻代对象时，写屏障触发以下动作：
- 计算该对象地址在卡表中的索引：地址右移9位（等价于 ÷ 512）
- 将对应byte设为非零值（如0xff），标记为dirty
- 该操作仅对“老→年轻”写入生效；其他方向不触发
关键点在于：卡表不记录任何引用地址，也不说明哪个对象引用了谁，只回答一个问题——“这512字节里，可能有跨代引用吗？”
Minor GC如何靠卡表提速
每次Minor GC前，JVM不遍历整个老年代，而是：
- 快速遍历Card Table数组，收集所有dirty位置
- 对每个dirty卡页覆盖的512字节内存，逐对象检查其字段是否真实指向年轻代
- 把确认的跨代引用源对象加入GC Roots
假设老年代1GB，共约200万个卡页；若只有0.1%变dirty（约2000个），扫描总量从1GB降至约1MB，停顿时间从百毫秒级压至几毫秒。
卡表必须与写屏障、Remember Set协同工作
卡表本身只是线索生成器，真正维护引用关系的是Remember Set（RSet）：
- Refinement线程异步从Dirty Card Queue取出dirty卡页
- 扫描卡页内对象，用OopMap识别出真实跨代字段
- 将“老年代对象 → 年轻代区域”的映射登记进对应Survivor区的RSet
Minor GC实际使用的GC Roots = 传统根（如栈帧、静态变量） + 年轻代各区域对应的RSet条目。没有写屏障，卡表就失效；没有卡表，RSet构建成本过高；三者缺一不可。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
