在之前的文章《通过HotSpot源码详解Java堆空间创建过程》中，曾经提到了HotSpot里的卡表（card table），并且说它是解决跨代引用问题的。当时限于篇幅，讲得很潦草，本文说得详细一点（但今天没时间读源码了，抱歉）。
我们从JVM的环境中抽离出来，考虑一个独立的两分代内存模型。该模型已经运行了一段时间，经历了多次对象创建与GC的过程，如下图所示。
其中Gen 0表示较年轻的一代，Gen 1表示较年老的一代，看官如果读过前述文章的话，对这种表述应该已经熟悉了。
现在触发Gen 0代GC（相当于HotSpot中的Minor/Young GC），通过根搜索算法进行标记，可以判定图中Gen 0代右下角的3个对象已不可达，它们就有可能会被删除掉。这可能会出现问题，因为会存在Gen 1对象到Gen 0对象的引用，即跨代引用，见图中红色箭头。如果这些对象真的被GC掉，红色箭头所代表的指针就成了一个悬空指针（dangling pointer），会造成GC的结果不确定甚至程序崩溃。为了保证安全，必须把存在跨代引用的Gen 1对象也设为GC根或者类似的东西，如下图所示。
然后就可以安全地清理了，在GC过程中存活下来的对象会promote到Gen 1。
那么问题又来了：在Gen 0代GC的时候，如何知道哪些对象存在跨代引用呢？由于引用是单向的，因此按一般的思路，只能在每次GC时先把Gen 1扫一遍，找出那些跨代引用的源头，这无疑是十分低效的。所以需要有一个东西来“记住”跨代引用，它叫做记忆集合（Remembered Set/RemSet）。记忆集合的简要图示如下。
可见，记忆集合实际上就是内存空间的粗粒度的位图表示。它其中的每个元素分别对应内存中的一块连续区域是否有跨代引用对象，如果有，该区域会被标记为“脏的”（dirty），否则就是“干净的”（clean）。这样在GC时，只需要扫描记忆集合就可以简单地确定跨代引用的位置，是个典型的空间换时间的思路。
在HotSpot的CMS和G1垃圾收集器中，都存在记忆集合，并且其实现就是卡表，由CardTableRS类定义，是GenRemSet类的子类。之前我们已经知道，卡表是个字节数组，每个字节对应堆空间老生代中的512个字节（这512个字节叫做卡页）是否有跨代引用。
HotSpot通过写屏障（write barrier）来维护卡表。我们已经知道，内存屏障的主要作用是防止指令重排序，它也是volatile关键字的基础。有了写屏障，JVM就可以保证引用发生改变时，对卡表中的卡做标记与访问内存的顺序不发生变化。在CardTableRS初始化时，所做的第一件事就是创建卡表需要的屏障集合（barrier set），并且CMS和G1的屏障集合实现是不同的。写屏障在卡标记时的作用可以用下图来表示。
在JDK 7之前，卡表的写屏障是无条件的。也就是说，不管更新的引用是否为跨代引用，都会出现一次写屏障。虽然这个造成的overhead相当的小，但在大并发情况下，又会造成虚共享（false sharing）问题，最后就来解释一下它。
CPU的缓存体系是以缓存行（cache line）为单位的，一条缓存行包含2的整数次幂个连续字节，一般为64B大。以64B为前提的话，那么一条缓存行就可以放下64个卡表元素，而64个卡页可以映射到32KB的堆空间。如果同时有多个线程对同一块32KB堆空间内的引用进行更新，就会在同一个缓存行内发生碰撞，造成缓存频繁写回或者失效，影响性能。
下图示出虚共享的例子。核心1上的线程更新X的引用，而核心2上的线程更新Y的引用，它们落到了同一个缓存行内。
为了避免这种开销，在JDK 7及以后，引入了参数-XX:+UseCondCardMark来开启卡标记时有条件的写屏障，也就是先检查卡表中对应的位是不是脏的，如果不是脏的，再进行标记。这个思路非常简单，但有效地避免了虚共享问题。
网友评论