背景
最近在跟同事进行jvm垃圾回收的交流，讨论到通过GC Roots进行对象的可达性分析，标记存活对象的时候，同事提出了一个疑问，因为年轻代中发生minor gc的频率很高，如果在经常会扫描年轻代中的对象进行标记，如果老年代中有对象引用了年轻代中的对象，那岂不是每次进行minor gc时也要进行全堆的扫描？嘿嘿，其实不然，jvm引入了卡表（card table）技术来解决这个问题。
卡表（card table）
jvm是如何通过卡表来避免每次进行minor gc时扫描全堆的问题呢？卡表是通过卡标记（card marking）来解决的。以Hotspot虚拟机为例，卡表的设计，是将整个堆空间分割成一个个卡页（card page），HotSpot虚拟机的每个卡页大小为512字节（其他虚拟机也基本都为2的n次幂），而卡表本事为一个简单的字节数组，记录当前对应卡页的标记值。当判断一个卡页中有存在对象的夸代引用时，将这个页标记为脏页，在进行 Minor GC 的时候，我们便可以不用扫描整个老年代，而是在卡表中寻找脏卡，并将脏卡中的对象加入到 Minor GC 的 GC Roots 里。当完成所有脏卡的扫描之后，Java 虚拟机便会将所有脏卡的标识位清零。
那么卡表是在何时进行写标记值呢？
卡表写标记的时机是在给引用型实例变量赋值时，只要有引用指向年轻代的对象，则将该页标记为脏页，这个动作对应解释执行时很容易办到的，Java 虚拟机需要截获每个引用型实例变量的写操作，并作出对应的写标识位操作。但是对于即时编译的代码来说就不好进行处理了，这时就引入了写屏障（write barrier）来进行处理，所谓的写屏障，就是在时编译器生成的机器码中，进行引用型实例变量赋值时插入额外的逻辑，写屏障需要尽可能地保持简洁，所以最终会把编译成一条指令：
CARD_TABLE [this address >> 9] = DIRTY;
这里右移 9 位相当于除以 512，Java 虚拟机便是通过这种方式来从地址映射到卡表中的索引的。
虽然这种机制会带来一些性能的开销，但是对于提高Minor gc的吞吐率来说，这点开销是值得的，但是在高并发场景下，写屏障又会带来虚共享的问题。
如何解决虚共享
虚共享：在现代中央处理器的缓存系统中，缓存是以缓存行（cache Line）来存储的，如果多个线程对多个独立的变量进行修改时，如果刚好这几个变量在同一个缓存行中，那么就会彼此影响，导致性能下降。
因为卡表是以字节数组的形式存在，假设一个缓存行大小为64字节，那么它能加载64张卡，每张卡512字节，也就是一个缓存行能加载32k的内存数据，如果两个线程刚好在这个32k的内存中更新引用，就会造成储卡表的同一部分的缓存行的写回、无效化或者同步操作，因而间接影响程序性能。为此，java7之后HotSpot 引入了一个新的参数 -XX:+UseCondCardMark，来尽量减少写卡表的操作，其伪代码如下：
if (CARD_TABLE [this address >> 9] != DIRTY)
CARD_TABLE [this address >> 9] = DIRTY;
