簡介
現代JVM，堆空間通常被划分為新生代和老年代。由於新生代的垃圾收集通常很頻繁，如果老年代對象引用了新生代的對象，那么，需要跟蹤從老年代到新生代的所有引用，從而避免每次YGC時掃描整個老年代，減少開銷。
對於HotSpot JVM，使用了卡標記（Card Marking）技術來解決老年代到新生代的引用問題。具體是，使用卡表（Card Table）和寫屏障（Write Barrier）來進行標記並加快對GC Roots的掃描。
卡表（Card Table）
基於卡表（Card Table）的設計，通常將堆空間划分為一系列2次冪大小的卡頁（Card Page）。
卡表（Card Table），用於標記卡頁的狀態，每個卡表項對應一個卡頁。
HotSpot JVM的卡頁（Card Page）大小為512字節，卡表（Card Table）被實現為一個簡單的字節數組，即卡表的每個標記項為1個字節。
當對一個對象引用進行寫操作時（對象引用改變），寫屏障邏輯將會標記對象所在的卡頁為dirty。
OpenJDK/Oracle 1.6/1.7/1.8 JVM默認的卡標記簡化邏輯如下：
CARD_TABLE [this address >> 9] = 0;
首先，計算對象引用所在卡頁的卡表索引號。將地址右移9位，相當於用地址除以512（2的9次方）。可以這么理解，假設卡表卡頁的起始地址為0，那么卡表項0、1、2對應的卡頁起始地址分別為0、512、1024（卡表項索引號乘以卡頁512字節）。
其次，通過卡表索引號，設置對應卡標識為dirty。
帶來的2個問題
1.無條件寫屏障帶來的性能開銷
每次對引用的更新，無論是否更新了老年代對新生代對象的引用，都會進行一次寫屏障操作。顯然，這會增加一些額外的開銷。但是，與YGC時掃描整個老年代相比較，這個開銷就低得多了。
不過，在高並發環境下，寫屏障又帶來了虛共享（false sharing）問題。
2.高並發下虛共享帶來的性能開銷
在高並發情況下，頻繁的寫屏障很容易發生虛共享（false sharing），從而帶來性能開銷。
假設CPU緩存行大小為64字節，由於一個卡表項占1個字節，這意味着，64個卡表項將共享同一個緩存行。
HotSpot每個卡頁為512字節，那么一個緩存行將對應64個卡頁一共64*512=32KB。
如果不同線程對對象引用的更新操作，恰好位於同一個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的對象，從而避免掃描整個老年代。