硬件的真相：多核、缓存行与指令重排

第一个谎言：你以为你在读内存

先看一组数字。把 CPU 的一个时钟周期（约 0.3 纳秒）想象成 1 秒，然后按比例放大：

缓存行：64 字节的最小单位

关键事实：CPU 从不按字节读内存。它按「缓存行」读，一行 64 字节。

你读一个 int（4 字节），CPU 会把它周围的 64 字节一起搬进 L1。这个设计基于「空间局部性」假设 —— 你读了 arr[0]，多半马上要读 arr[1]。

这个设计在单线程里是纯赚。在多线程里，它会咬人。

伪共享：两个变量，一场灾难

// 两个计数器，两个线程各管一个。它们之间毫无关系。
class Counters {
    @Volatile var a = 0L   // 8 字节
    @Volatile var b = 0L   // 8 字节，紧挨着 a
}

// 线程 1: 疯狂 counters.a++
// 线程 2: 疯狂 counters.b++
//
// 它们没有共享任何数据。应该是完美并行的。
// 实测:比单线程还慢 2~10 倍。

为什么？因为 a 和 b 挨在一起，它们在同一个 64 字节的缓存行里。

而缓存一致性协议（MESI）的工作单位也是缓存行：

怎么修：把它们隔开

// 方法一:填充(padding)—— 老派但通用
class PaddedCounter {
    @Volatile var value = 0L
    // 填 7 个 long = 56 字节,把下一个变量挤到另一条缓存行去
    @Volatile var p1 = 0L; @Volatile var p2 = 0L; @Volatile var p3 = 0L
    @Volatile var p4 = 0L; @Volatile var p5 = 0L; @Volatile var p6 = 0L
    @Volatile var p7 = 0L
}

// 方法二:JVM 提供的官方姿势
@jdk.internal.vm.annotation.Contended   // JDK 8+,需要 -XX:-RestrictContended
class Counter { @Volatile var value = 0L }

// 方法三(最实用):根本不要共享。
// 每个线程一个自己的计数器,最后 sum 一次。
// ↑ 这就是 Java 的 LongAdder 和 Go 的 sync/atomic 分片计数器在做的事。

第二个谎言：你以为代码按顺序执行

看这段代码。x 和 y 初始都是 0。

// 线程 1              // 线程 2
x = 1                  y = 1
r1 = y                 r2 = x

// 问:r1 == 0 && r2 == 0 有可能吗?

凭直觉：不可能。因为不管两个线程怎么交错，总有一个线程的写会先发生，另一个线程就该读到它。

但在真实的 x86 CPU 上，r1 == 0 && r2 == 0 是会发生的。（在 ARM 上更容易。）

凶手一：CPU 的写缓冲区（Store Buffer）

凶手二：编译器

编译器也在重排，而且它的理由和 CPU 一样：「反正单线程看不出来」。

// 你写的
var flag = false
var data = 0

// 线程 1:
data = 42        // (1)
flag = true      // (2)

// 线程 2:
if (flag) {
    print(data)  // 期望打印 42
}

// 但编译器/CPU 完全可以把 (1) 和 (2) 换个顺序执行 ——
// 因为在「单线程」的视角里,它们互不依赖,换了也没区别。
//
// 于是线程 2 可能看到 flag == true, 但 data 还是 0。

这就是「可见性」和「有序性」问题的根。而下一章会把它和「原子性」一起拆开。

内存屏障：唯一的解药

解药只有一个：告诉编译器和 CPU 「这里不许重排」。这个指令叫内存屏障（memory barrier / fence）。

但你几乎永远不需要手写它。语言层面已经给你包好了：

下一章：线程本身。它凭什么这么贵？—— 一个 8MB 的承诺，和一笔 1 微秒的税。