card table是jvm优化跨代引用扫描的关键机制，将老年代划分为512字节卡页，每页对应卡表一个字节；写屏障在老年代引用新生代时标记对应卡页为脏；minor gc仅扫描脏卡页内对象，识别跨代引用作为gc roots。
Card Table 是 JVM 为优化跨代引用扫描而设计的关键辅助数据结构，它的核心作用就是让 Minor GC 不必扫描整个老年代，只聚焦于真正“可能持有新生代引用”的内存块——也就是被标记为“脏（Dirty）”的卡页。理解它，就等于看清了低停顿回收背后最朴素却高效的工程逻辑。
Card Table 是什么：512 字节一张“卡”
JVM 把老年代划分为固定大小的内存块，每块叫一个“卡（Card）”，大小固定为 512 字节。所有卡组成一张位图（BitMap），每个卡对应一个比特位：0 表示“干净”，即该卡内对象**没有**引用新生代对象；1 表示“脏”，意味着至少有一个对象持有了对年轻代的引用。
当老年代中的某个对象（比如一个 HashMap）在运行时被赋值指向了一个新创建的 String（在 Eden 区），JVM 就会通过写屏障（Write Barrier）机制，立即把该对象所在卡对应的比特位置为 1——这个过程极快，且由硬件指令级支持，几乎不拖慢业务线程。
为什么需要“脏卡”：避免全量扫描老年代
Minor GC 的本质是回收年轻代，但它必须确保：老年代中没有对象正引用着即将被回收的年轻代对象。否则就会误删“活对象”。如果没有 Card Table，每次 YGC 都得扫描整个老年代（可能是几 GB），STW 时间会随堆增长线性上升，完全不可控。
有了 Card Table，YGC 只需做两件事：
- 定位所有 dirty bit = 1 的卡（即“脏卡”）
- 仅扫描这些卡对应的老年代内存区域，检查其中对象是否引用了年轻代
这把扫描范围从“整个老年代”压缩到“少量脏卡”，直接把 YGC 的 STW 从几百毫秒压到几毫秒级别。
增量扫描怎么实现：按 stride 划分并行处理
“增量”不是指时间上切片，而是指空间上按需、分块、可并行地处理脏卡。JVM 把连续的脏卡打包成“stride”，每个 stride 默认包含 256 张卡（即 256 × 512B = 128KB）。多线程 GC 时，每个线程领取一个 stride 独立扫描，互不阻塞。
例如老年代 4GB，总卡数约 8M 张，stride 数量约为 32K。如果 stride 太小（如设为 32 张卡），线程频繁切换 stride，调度开销上升；如果太大（如设为 8K 张卡），单个线程工作不均，拖慢整体进度。因此可通过参数 -XX:ParGCCardsPerStrideChunk 调整 stride 大小，常见调优值有 256（默认）、4K、8K，需结合实际 GC 日志和 CPU 核心数验证。
写屏障与脏卡维护：谁来标记？何时标记？
脏卡标记不是 GC 触发后才开始，而是在日常运行中持续发生的：
- 每当发生一次老年代对象 → 新生代对象的引用写入（如 oldObj.field = newString），JVM 的写屏障会拦截该操作
- 写屏障快速计算出 oldObj 所在卡的索引，并原子性地将对应 bit 置为 1
- 这个动作在用户线程中完成，耗时纳秒级，不影响吞吐
也就是说，“脏”是实时产生的，“扫”是延迟批量做的——这种“写时标记、收时扫描”的分离设计，正是实现并发与低延迟的关键前提。CMS 和 G1 都依赖它，只是 G1 进一步用 RSet（Remembered Set）在 Region 粒度上做了更精细的引用记录。
