偽共享與緩存行填充：從 Java 6 到 Java 8 的演進與最佳實踐

什麼是偽共享？

CPU 緩存以 緩存行 為單位讀寫內存（典型 64 字節）。當多線程修改**不同但相鄰**的變量，這些變量恰好落在**同一緩存行**時，會導致緩存行在核心間頻繁來回傳輸、失效、同步，嚴重拖垮性能——這就是偽共享。

圖解：核心 1 寫變量 X，核心 2 寫變量 Y，X/Y 同一緩存行 → 緩存行在兩核心間「乒乓」傳遞，經過 L3 甚至跨插槽，性能暴跌。

Java 6：手動填充字段（VolatileLong + p1..p6）

利用對象頭 (8/12 字節) + 6 個 long (48 字節) = 56/60 字節，接近 64 字節緩存行大小，使每個對象獨佔一行。

public final class VolatileLong {
    public volatile long value = 0L;
    public long p1, p2, p3, p4, p5, p6;  // 填充字段
}

• 測試證明：填充後性能提升數倍。
• 缺陷：字段數需精確計算；32/64 位 JVM 對象頭大小不同；填充過多（如 8 個 long）反而因佔用更多緩存行導致性能下降。

Java 7：逃逸分析優化導致填充失效

JDK 7 引入逃逸分析、標量替換，**判定填充字段無用而優化掉**，導致對象縮水，偽共享復發。

繞過優化的 Hack 方案：繼承鏈隔離

public class VolatileLongPadding {
    public volatile long p1, p2, p3, p4, p5, p6;
}

public class VolatileLong extends VolatileLongPadding {
    public volatile long value = 0L;
}

• 將填充字段放入父類，JDK 7 不會優化掉繼承鏈上的字段（具體原因涉及 JIT 編譯器對繼承結構的保守處理）。
• 缺點：代碼醜陋、依賴具體 JVM 實現細節、不可移植。

Java 8：原生支援 @Contended 註解（終極方案）

JDK 8 (JEP 142) 引入 sun.misc.Contended，由 JVM 自動在對象/字段周圍插入填充，完全透明、無侵入、跨平台穩定。

1. 類級別註解：整個對象獨佔緩存行（前後各 128 字節填充）

import sun.misc.Contended;

@Contended
public class VolatileLong {
    public volatile long value = 0L;
}

• JVM 在對象頭前後各填充 128 字節（2 倍緩存行），防止相鄰扇區預取導致的偽共享。
• 啟動必須添加 JVM 參數：-XX:-RestrictContended（默認限制僅 JDK 內部類使用）。

2. 字段級別註解：精確隔離熱點字段

public class VolatileLong {
    @Contended public volatile long value1 = 0L;
    @Contended public volatile long value2 = 0L;
    @Contended public volatile long value3 = 0L;
    @Contended public volatile long value4 = 0L;
}

• 每個被註解字段獨佔緩存行，其他普通字段緊湊排列。

3. 字段級別 + contention group：同組字段緊湊、組間隔離

public class VolatileLong {
    @Contended("group0") public volatile long value1 = 0L;
    @Contended("group0") public volatile long value2 = 0L;  // 與 value1 緊鄰
    @Contended("group1") public volatile long value3 = 0L;
    @Contended("group1") public volatile long value4 = 0L;  // 與 value3 緊鄰
    // group0 與 group1 之間、與普通字段之間有填充隔離
}

• 核心優勢：同一線程高頻同時更新的字段（如計數器雙指標）放入同組，**避免組內填充浪費內存**，同時隔離不同線程訪問的組。

實測對比：@Contended 分組威力

// 測試 1：線程 0 寫 value1/value2 (同組)；線程 1 寫 value3/value4 (同組) → 無偽共享
// 測試 2：線程 0 寫 value1/value3 (跨組)；線程 1 寫 value2/value4 (跨組) → 有偽共享
// 測試 3：無 @Contended 基準

結果（納秒，越小越快）：

使用檢查清單

1. 引入 import sun.misc.Contended;（屬於 JDK 內部 API，編譯需 -XDignore.symbol.file 或配置 Maven Compiler Plugin 允許內部 API）。
2. 運行時**必須**加 -XX:-RestrictContended，否則註解無效（許多教程漏提此點）。
3. 優先考慮字段級 + 分組，精準隔離熱點，節省內存。
4. 僅用於**高併發寫入熱點對象**（如計數器、環形隊列游標、Disruptor RingBuffer），濫用會增加內存佔用。
5. Java 9+ 可用 @jdk.internal.vm.annotation.Contended（模塊化後新位置），同樣需 --add-exports java.base/jdk.internal.vm.annotation=ALL-UNNAMED。

總結

• Java 6：手動填充，脆弱、不可移植。
• Java 7：JIT 優化破壞填充，需繼承 Hack，極不推薦。
• Java 8+：@Contended 為正解，JVM 級支援，配合分組機制完美平衡性能與內存。
• 記住 -XX:-RestrictContended，否則等於白寫。

偽共享是無聲的性能殺手，掌握 @Contended 讓你在高併發寫入場景中游刃有餘。