Card Table 卡表

本文主要是介绍Card Table 卡表，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

因何而生

现代JVM，堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么，需要跟踪从老年代到新生代的所有引用，从而避免每次YGC时扫描整个老年代，减少开销。

对于HotSpot JVM，使用了卡标记（Card Marking）技术来解决老年代到新生代的引用问题。具体是，使用卡表（Card Table）和写屏障（Write Barrier）来进行标记并加快对GC Roots的扫描。

底层设计

基于卡表的设计，通常将堆空间划分为一些列2次幂大小的卡页（Card Page）。卡表用于标记卡页的状态，每个卡表对应一个卡页。

HotSpot JVM的卡页大小为512字节，卡表被实现为一个简单的字节数组，即卡表的每个标记项为1个字节。当对一个对象引用进行写操作时（对象引用改变），写屏障逻辑将会标记对象所在的卡页为dirty。

OracleJDK/Oracle 1.6/1.7.1.8 JVM默认的卡标记简化逻辑如下：

CARD_TABLE [this address >>9] =0;

首先，计算对象引用所在卡页的卡表索引号，将地址右移9位，相当于用地址除以512，假设卡表卡页的其实地址为0 ，那么卡表项 0、1、2对应的卡页起始地址分别为 0 ，512，1024 （卡表项索引号诚意卡页512字节），其次通过卡表索引号，设置对应标识为dirty。

固有问题

无条件写屏障带来的性能开销

每次对引用的更新，无论是否更新了老年代对新生代对象的引用，都会进行一次写屏障操作。显然，这会增加一些额外的开销。但是，与YGC时扫描整个老年代相比较，这个开销就低得多了。不过，在高并发环境下，写屏障又带来了虚共享（false sharing）问题。
高并发下虚共享带来的性能开销（false sharing）

在高并发下，频繁的写屏障很容易发生虚共享(false sharing),从而带来性能开销。假设CPU缓冲行大小为64字节，由于一个卡表项占一个字节，这意味64个卡表项将共享一个缓存行。

HotSpot 每个卡页为512字节，那么一个缓存行将对应64个卡页，一共64*512 =32k ,

如果不同线程堆对象引用的更新操作，恰好谓语同一个32kb区域，这将导致同时更新卡表的同一个缓冲行，从而造成缓冲行的写回无效化或者同步操作，间接影响程序性能。

一个简单的解决方案，就是不采用无条件的写屏障，而是先坚持卡表标记，只有当该卡表项未被标记过才将其标记为dirty。

这就是JDK 7中引入的解决方法，引入了一个新的JVM参数-XX:+UseCondCardMark，在执行写屏障之前，先简单的做一下判断。如果卡页已被标识过，则不再进行标识。

if (CARD_TABLE [this address >> 9] != 0)CARD_TABLE [this address >> 9] = 0;

与原来的实现相比，只是简单的增加了一个判断操作。

虽然开启-XX:+UseCondCardMark之后多了一些判断开销，但是却可以避免在高并发情况下可能发生的并发写卡表问题。通过减少并发写操作，进而避免出现虚共享问题（false sharing）。

也用于CMS GC

CMS在并发标记阶段，应用线程和GC线程是并发执行的，因此可能产生新的对象或对象关系发生变化，例如：

新生代的对象晋升到老年代；
直接在老年代分配对象；
老年代对象的引用关系发生变更；
等等。

对于这些对象，需要重新标记以防止被遗漏。为了提高重新标记的效率，并发标记阶段会把这些发生变化的对象所在的Card标识为Dirty，这样后续阶段就只需要扫描这些Dirty Card的对象，从而避免扫描整个老年代。

应用场景

JVM虚拟机用了一个叫做CardTable（卡表）的数据结构来标记年轻代的某一块内存区域中对象是否持有新生代对象的引用，卡表的数量取决于老年代的代销和每张卡对应的内存大小，每张卡在卡表中对应一个比特位，当老年代中某个对象持有了新生代对象的引用时，JVM就会把这个对象的Card所在的位置标记为dirty(bit位设置为1)，这样在Minor GC时，就不需要扫描整个老年代，而是扫描Card中dirty对应的那些区域。

由于在做YGC时，需要扫描整个Old 区，效率非常低，所以JVM设计了CardTable，如果一个Old区CardTable 中有对象指向Y区，下次扫描的时候需要扫描Dirty Card，Dirty Card 记录了这些对象在内存区域是clean 还是dirty状态，在结构上Card Table用BitMap来实现。