Card Table 不是让 YGC 跳过老年代，而是精准定位需扫描的“脏卡”区域：将老年代按512字节分卡，写屏障标记跨代引用对应的卡页为dirty，YGC仅扫描这些卡页（通常不足总量0.1%），使扫描量从GB级降至KB级，STW稳定在几毫秒。
Card Table 不是让 YGC “跳过老年代”，而是让它只扫真正需要扫的老年代区域。它的价值不在省略，而在精准定位——把原本必须扫描几 GB 老年代的暴力遍历，压缩成仅检查几百 KB 甚至更少的“脏卡”内存块。
为什么必须处理跨代引用？
年轻代对象可能被老年代对象持有（比如缓存容器、单例中的 long-lived 引用）。YGC 若忽略这点，会把仍被老年代引用的年轻对象当成垃圾回收，直接导致程序崩溃或数据丢失。
但全量扫描老年代不可行：4GB 老年代逐对象检查字段，STW 时间随堆线性增长，轻松突破百毫秒。
Card Table 就是为打破这个“全扫太慢、不扫出错”的两难而生的中间解。
Card Table 怎么工作？
它是一张极小的索引表，背后有三根支柱：
- 固定分块：老年代按 512 字节切分为“卡页”（Card），每页对应 Card Table 数组中一个字节
-
写屏障驱动标记：当老年代对象执行
obj.field = youngObj这类跨代写操作时，JVM 插入的写屏障立即把该对象所在卡页标记为 dirty（值设为 1） -
O(1) 地址映射：给定对象地址，通过右移 9 位（
(uintptr_t)obj >> 9）直接算出它属于哪张卡，无需遍历或哈希
YGC 扫描时如何靠它加速？
一次典型的 Minor GC 在跨代引用处理阶段只做两件事：
- 快速遍历 Card Table 字节数组（例如 4GB 老年代 → 卡表仅约 2MB），收集所有值为 1 的卡索引
- 对每个 dirty 卡，扫描其对应 512 字节内存块内的所有对象，检查其字段是否真指向新生代
实测中，真正 dirty 的卡通常不到总量的 0.1%。这意味着扫描量从 GB 级降到 KB 级，YGC STW 稳定在几毫秒。
增量扫描不是时间切片，而是空间并行
“增量”指 JVM 把连续 dirty 卡打包成 stride（默认 256 张卡 = 128KB 内存），供多线程 GC 并行处理：
- 每个 GC 线程领取一个 stride，独立扫描，无锁竞争
- 可通过
-XX:ParGCCardsPerStrideChunk调整 stride 大小（如 4K 或 8K），需结合 CPU 核数和 GC 日志验证效果 - stride 太小 → 线程调度开销大；太大 → 任务不均，拖慢整体进度
