CPU 缓存行假共享：一次把高并发计数器吞吐压低 40% 的排查与治理

结论先行

先给结论：在一台 8 物理核 / 16 逻辑核的机器上，8 个线程各自累加一个 long 计数器，如果这些计数器在堆内存里"挨着"，总吞吐只有 1180 万 ops/s；把它们各自撑到独占一条 64 字节缓存行之后，同一台机器、同一套 JMH 基准，吞吐拉到 1970 万 ops/s，涨了约 67%。 这就是假共享（false sharing）：线程之间逻辑上各写各的变量、没有任何共享，却因为在同一条缓存行里，被 CPU 的缓存一致性协议拖了后腿。

我见过太多"加了线程反而更慢"的案子，大家第一反应是锁、是 GC、是上下文切换，很少想到缓存行。这篇文章把这件事从头讲清楚：为什么会出现、怎么量出来、怎么治、以及几个反直觉的坑。

一、现象与背景：逻辑上无共享，性能上却互相拖累

具体场景：我们有一个埋点聚合服务，每个 worker 线程维护自己的"本线程累计条数"计数器（long），用于本地统计、最后再汇总。代码看起来完全无锁、无竞争：

class Worker {
    long count;              // 每个 Worker 只写自己的
    void inc() { count++; }
}

8 个线程、每个线程一个 Worker 实例，count 字段在对象里是相邻的。压测（JMH 1.37，JDK 17.0.8，-f 2 -wi 5 -w 10）跑下来，8 线程版本吞吐只有 1180 万 ops/s；而把线程数降到 4，吞吐反而 1310 万 ops/s——加线程，吞吐不升反降。这是典型的"加并发 = 加等待"信号，但锁、GC、CPU 利用率都没异常：perf top 看不到自旋，jstat 的 GC 时间占比不到 1%。

二、原理：MESI 协议为什么把"各自写"变成"互相抢"

根因在 CPU 的缓存一致性协议。现代 CPU 的缓存以"缓存行"（cache line）为最小管理单位，x86_64 上一条通常是 64 字节（可用 getconf LEVEL1_DCACHE_LINESIZE 或 /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size 确认）。

当 A 核要写某条缓存行时，MESI 协议会先把其他核里持有这条行副本的标记为 Invalid（失效），由发起核独占。问题在于：JVM 把相邻的 count 字段放进了同一条 64 字节缓存行。于是线程 1 写 worker1.count、线程 2 写 worker2.count，虽然变量不同，却落在同一条行上——每次写都触发一次跨核的行失效与搬运。8 个核轮流把对方手里的这条行"打失效"，缓存行在核之间来回乒乓（cache line ping-pong），CPU 大量时间花在一致性流量上，而不是真正累加。

这就是"假共享"：逻辑不共享，物理上共享了同一条缓存行。注意它和真竞争不同——真竞争是抢同一个对象，监控能看到锁等待；假共享在 JVM 层面完全无锁、无任何共享对象，所以常规 Java 排障手段全部落空。

三、具体做法：先量出来，再对齐

1. 用 JMH 复现（不要相信"看起来没竞争"）

@BenchmarkMode(Mode.Throughput)
@State(Scope.Thread)
@Warmup(iterations = 5, time = 1)
@Measurement(iterations = 10, time = 1)
public class FalseSharingBench {

    @State(Scope.Benchmark)
    public static class ContendedState {
        long a, b, c, d, e, f, g, h;   // 相邻字段 → 假共享
    }

    @State(Scope.Benchmark)
    public static class PaddedState {
        long p1,p2,p3,p4,p5,p6,p7; long a;
        long q1,q2,q3,q4,q5,q6,q7; long b;
        // ... 每个目标字段两侧各垫 7 个 long（56 字节）撑满缓存行
    }

    @Benchmark public void contended(ContendedState s) { s.a++; }
    @Benchmark public void padded(PaddedState s) { s.a++; }
}

跑 java -jar bench.jar -f 2 -wi 5 -w 10，对比 contended 与 padded 的 Throughput。我们实测：8 线程下 contended 1180 万、padded 1970 万 ops/s；4 线程时两者差距收窄（约 1310 万 vs 1520 万）——线程越多、物理核越多，假共享越明显，这也解释了"加线程反而更慢"。

2. 三种治理手段（按推荐度）

方案 A：手动 padding（最直接、最可控） 在会高频写、且会被多线程相邻分配的字段两侧各垫 7 个 long（7×8=56 字节 + 目标 8 字节 = 64 字节，正好一条缓存行）：

static class PaddedCounter {
    long p1, p2, p3, p4, p5, p6, p7; // 前置 56 字节
    long value;                        // 目标
    long q1, q2, q3, q4, q5, q6, q7; // 后置 56 字节
}

方案 B：JDK 的 @Contended（JDK 8+，但坑多，见下节）

import jdk.internal.access.Contended;
static class Counter { @Contended long value; }

需要 -XX:-RestrictContended 解锁（它默认只允许 java.* 包内使用），且 @Contended 是 jdk.internal API，普通业务代码不建议依赖。

方案 C：从设计上避开（最优雅） 如果"每个线程一个计数器、最后汇总"，直接用 LongAdder 而不是 AtomicLong。LongAdder 内部用 Cell[] 分散写、读时再累加，天然把热点分散到不同缓存行，8 线程下我们实测吞吐能到 2100 万 ops/s，比手动 padding 还略高，且代码最干净。

四、踩过的坑与反直觉之处

1. @Contended 默认"不生效"。 它是 jdk.internal.access 包，且受 -XX:RestrictContended（默认开启）限制，只在 java.* 类上允许。业务代码直接加注解，编译能过、运行却可能没 padding，性能毫无变化——我们第一次加上去测，发现根本没起作用，查了半天才发现是 RestrictContended 挡着。
2. 缓存行大小不是写死的 64。 x86_64 常见 64 字节，但 ARM（如 Graviton）可能是别的值，padding 的字节数要按 coherency_line_size 对齐，不要硬编码 7 个 long 就以为万事大吉。
3. JVM 不会自动帮你 padding 业务对象。 只有 JDK 内部某些类用了 @Contended，你自己的 Worker、Counter 它一概不管。"我加了注解为什么没变快"多半是没解锁或没对齐。
4. 单线程几乎无感。 假共享的代价来自跨核一致性流量，线程少、或都落在同一个物理核（超线程）时，差距很小甚至测不出来。别用 1~2 线程的基准去"证明没有假共享"。
5. 别把它和 GC 混为一谈。 现象里 GC 占比 <1%、锁等待为 0，恰恰是假共享的特征——常规 Java 排障全落空，得从 CPU 缓存层看。

五、结论与可复用清单

结论：高并发下"加线程反而更慢、无锁无 GC 异常"，第一个该怀疑的是缓存行假共享，而不是锁或 GC。

排查清单（按顺序）

1. 确认现象：加线程吞吐不升反降，且 perf top 无自旋、GC 占比低、jstack 无锁等待。
2. 看是不是多线程相邻写多个独立字段（long 计数器、批量累加器、并行数组填充）。
3. cat /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size 确认缓存行大小。
4. 用 JMH 对比"相邻字段" vs "padding 后"的吞吐，量化差距。
5. 治理：能改成 LongAdder/分散结构就改；不行就手动 padding 撑满缓存行；谨慎使用 @Contended（记得 -XX:-RestrictContended）。

一句话记忆：CPU 按 64 字节一条缓存行管理一致性，逻辑不共享 ≠ 物理不共享；把高频写的字段彼此隔开一条缓存行，"假共享"就消失了。