512字节粒度易引发伪共享，因一个64字节缓存行容纳64个卡表项，覆盖32kb堆内存，多线程修改该范围内不同对象会竞争同一缓存行；hotspot通过条件式卡标记和卡表对齐填充缓解。
卡表中每个字节标记512字节内存区域是否“脏”，这个设计在高并发写场景下容易引发伪共享（False Sharing）问题。
为什么512字节粒度会撞上CPU缓存行
CPU缓存以缓存行为单位加载数据，主流x86-64处理器缓存行大小为64字节。而卡表是连续的字节数组，每1个字节对应1个卡页（512字节堆内存）。这意味着：一个64字节的缓存行能容纳64个卡表项，覆盖64 × 512 = 32KB的堆内存空间。
当多个线程频繁修改这32KB范围内的不同对象（比如往不同ArrayList里add年轻代对象），它们实际更新的是卡表中**物理相邻甚至同一缓存行内的不同字节**——即使逻辑无关，硬件层面却触发反复的缓存行失效、写回与同步。
伪共享带来的典型表现
- Minor GC前扫描卡表耗时明显上升，尤其在ParNew或CMS中出现[CardTableEntryClosure: 数万 cards]日志
- CPU缓存未命中率（如perf stat -e cache-misses）显著升高
- 应用吞吐量下降，但单线程性能无变化，线程数增加后反而更慢
- 热点线程堆栈常停留在CardTableModRefBS::write_ref_field_post等写屏障入口
HotSpot的缓解机制
JVM并未完全消除伪共享，而是通过两种方式降低影响：
- 条件式卡标记（-XX:+UseCondCardMark）：写屏障先比较旧引用和新引用是否相同，仅在真正变更时才标记dirty。避免了大量无意义的卡表写入
- 卡表内存对齐与填充（内部实现）：HotSpot在分配CardTable内存时，会对数组做cache-line对齐，并在关键位置插入padding字节，使高竞争区域尽量分散到不同缓存行
应用层可做的配合
- 避免让多个高频更新对象长期落在同一512字节区间内（例如批量创建小对象时控制分配节奏）
- 减少老年代对象对新生代的“间接高频引用”，比如用弱引用缓存替代强引用持有临时对象
- 在压测中开启-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察每次Minor GC前后card处理数量是否突增且不收敛
