硬件缓存与内存模型 on Dorkytiger 的小屋

CPU 缓存行（Cache Line）与 MESI 协议

Mon, 01 Jan 0001 00:00:00 +0000

完美！进入第二阶段，我们要从"原子操作"升级到"缓存一致性"，这是理解内存屏障和伪共享的基石。这个问题直击高性能并发编程的灵魂。

1. 缓存行（Cache Line）：CPU缓存的最小传输单位

什么是缓存行？

CPU和内存之间传输数据时，不是按字节，而是按块（Block） 传输。这个块的大小就是缓存行（Cache Line），现代CPU通常为 64字节。

内存地址空间 (假设从 0x0000 开始):
+--------+--------+--------+--------+--------+--------+
| 字节0   | 字节1   | 字节2   | ...    | 字节63  |        ← 缓存行 1 (0x0000 - 0x003F)
+--------+--------+--------+--------+--------+--------+
| 字节64  | 字节65  | ...    |         | 字节127 |        ← 缓存行 2 (0x0040 - 0x007F)
+--------+--------+--------+--------+--------+--------+

关键特性：

当CPU读取 int a（4字节），实际会加载整个64字节的缓存行到L1。
当CPU修改 int a，先把整个缓存行加载，修改后整行写回（或标记脏）。
缓存行是对齐的：地址必须是64的倍数（address & ~63 得到行首）。

为什么用缓存行？（空间局部性）

// 数组遍历：极快
int arr[1000000];
for (int i = 0; i < 1000000; i++) {
    arr[i]++; // 每次访问 arr[i]，相邻的 arr[i+1] 已经被预加载到缓存行
}
// 缓存命中率 > 95%

2. MESI协议：缓存一致性的"交通规则"

多个核心都有自己独立的L1/L2缓存，如何保证它们看到的数据一致？MESI协议定义了缓存行的四种状态，每个核心的缓存控制器维护这个状态机。

伪共享（False Sharing）与内存对齐（Padding）

Mon, 01 Jan 0001 00:00:00 +0000

这个问题问到了高性能并发编程的命门！伪共享是90%的性能劣化问题根源，而内存对齐是解决它的手术刀。我们今天不仅要讲理论，还要让你亲眼看到伪共享如何拖垮程序，以及如何用 alignas(64) 一招制敌。

1. 伪共享（False Sharing）的物理真相

硬件层面的"误伤"

内存布局 (缓存行大小 = 64字节):
+------------------------------------------------------------------+
| 缓存行 0x1000 - 0x103F                                           |
| +----------+----------+----------+----------+----------+         |
| | int a    | int b    | 填充     | 填充     | 填充     |         |
| | (0x1000) | (0x1004) | (0x1008) | ...      | (0x103C) |         |
| +----------+----------+----------+----------+----------+         |
+------------------------------------------------------------------+

核心A: 频繁修改 a (0x1000)
核心B: 频繁修改 b (0x1004)

虽然修改的是不同变量，但它们在同一个缓存行！
CPU被迫让这个缓存行在核心A和核心B之间"飞来飞去"。

缓存行乒乓（Cache Line Ping-Pong）

时间线 (微秒级):

[核心A] 读取缓存行 → 状态 E (独占)
[核心A] 修改 a → 状态 M (修改)
[核心B] 读取缓存行 → 需要从核心A获取 → 核心A 状态 M→S (共享)，写回主存
[核心B] 获取缓存行 → 状态 S
[核心B] 修改 b → 需要独占 → 广播 RFO (请求独占)
[核心A] 收到 RFO → 状态 S→I (失效)
[核心B] 状态 S→M (修改)
... 循环往复

每次乒乓: ~100ns 延迟 (相当于300个CPU周期)
如果每秒百万次操作 → 性能损失巨大！

2. 实战Demo：让伪共享现出原形

测试程序（对比有/无伪共享）

#include <atomic>
#include <thread>
#include <chrono>
#include <iostream>
#include <vector>

using namespace std::chrono;

// ==================== 版本1：有伪共享 ====================
struct FalseSharingStruct {
    std::atomic<int> a{0};  // 地址 0x1000
    std::atomic<int> b{0};  // 地址 0x1004 (同一缓存行!)
};
FalseSharingStruct fs_data;

void worker_false_sharing(int id, int iterations) {
    if (id == 0) {
        for (int i = 0; i < iterations; ++i) {
            fs_data.a.fetch_add(1, std::memory_order_relaxed);
        }
    } else {
        for (int i = 0; i < iterations; ++i) {
            fs_data.b.fetch_add(1, std::memory_order_relaxed);
        }
    }
}

// ==================== 版本2：无伪共享 (内存对齐) ====================
struct alignas(64) CacheLineAlignedStruct {
    std::atomic<int> a{0};  // 地址 0x1000 (缓存行开始)
    // 隐含填充：剩余60字节自动填充
};

struct alignas(64) CacheLineAlignedStruct2 {
    std::atomic<int> b{0};  // 地址 0x1040 (下一缓存行)
};

CacheLineAlignedStruct aligned_a;
CacheLineAlignedStruct2 aligned_b;

void worker_no_false_sharing(int id, int iterations) {
    if (id == 0) {
        for (int i = 0; i < iterations; ++i) {
            aligned_a.a.fetch_add(1, std::memory_order_relaxed);
        }
    } else {
        for (int i = 0; i < iterations; ++i) {
            aligned_b.b.fetch_add(1, std::memory_order_relaxed);
        }
    }
}

// ==================== 测试函数 ====================
template<typename Func>
void benchmark(const std::string& name, Func&& func, int iterations) {
    auto start = high_resolution_clock::now();
    func();
    auto end = high_resolution_clock::now();
    auto duration = duration_cast<milliseconds>(end - start).count();
    std::cout << name << ": " << duration << " ms" << std::endl;
}

int main() {
    const int THREADS = 2;
    const int ITERATIONS = 100'000'000; // 1亿次
    
    // 测试伪共享
    benchmark("False Sharing", [&]() {
        std::vector<std::thread> threads;
        for (int i = 0; i < THREADS; ++i) {
            threads.emplace_back(worker_false_sharing, i, ITERATIONS);
        }
        for (auto& t : threads) t.join();
    }, ITERATIONS);
    
    // 测试无伪共享
    benchmark("No False Sharing (aligned)", [&]() {
        std::vector<std::thread> threads;
        threads.emplace_back(worker_no_false_sharing, 0, ITERATIONS);
        threads.emplace_back(worker_no_false_sharing, 1, ITERATIONS);
        for (auto& t : threads) t.join();
    }, ITERATIONS);
    
    return 0;
}

预期运行结果

False Sharing: 2850 ms     ← 慢！
No False Sharing (aligned): 890 ms  ← 快 3.2 倍！

为什么差这么多？ 因为伪共享版本每次修改都需要缓存行失效+重新加载，相当于做了两次主存访问。

编译器重排 vs CPU 乱序执行

Mon, 01 Jan 0001 00:00:00 +0000

这个问题是理解内存屏障的终极门槛！很多开发者分不清"编译器重排"和"CPU乱序执行"，更不清楚Store Buffer和Invalidation Queue如何"合谋"制造出反直觉的内存可见性问题。

我们先从硬件架构出发，解剖现代CPU的"谎言"，再深入两种重排的本质区别。

1. 编译器重排 vs CPU乱序执行：本质区别

编译器重排（Compile-time Reordering）

发生时机：编译阶段（静态）

动机：优化寄存器分配、指令流水线。

// C++ 源码
int a = 1;  // 操作1
int b = 2;  // 操作2

// 编译器可能重排为（如果操作1更耗时）
int b = 2;  // 操作2 先执行
int a = 1;  // 操作1 后执行

关键：编译器认为单线程下结果等价，但多线程下可能暴露问题。

CPU乱序执行（Out-of-Order Execution）

发生时机：运行阶段（动态）

动机：填充流水线气泡，提高执行效率。

; 汇编代码（编译器生成顺序）
MOV [addr1], 1   ; 写操作1
MOV R1, [addr2]  ; 读操作2

; CPU实际执行（如果addr1 cache miss）
MOV R1, [addr2]  ; 先执行读（因为不需要等写完成）
MOV [addr1], 1   ; 后执行写

关键：CPU通过重排序缓冲区（ROB） 保证单线程语义，但多线程下其他核心看到的是乱序结果。

对比总结表

维度	编译器重排	CPU乱序执行
发生阶段	编译时	运行时
控制者	编译器（GCC/Clang）	CPU硬件（乱序执行单元）
防护手段	`asm volatile("" ::: "memory")`	`mfence` / `lfence` / `sfence`
C++控制	`std::atomic` 的 memory_order	同上（硬件层面）
可见性	二进制代码顺序已变	二进制顺序不变，但执行顺序变

2. Store Buffer（写缓冲区）：CPU的"谎言"之一

为什么需要Store Buffer？

核心问题：L1缓存写入太慢（需要等待缓存行变为E/M状态，可能要发RFO等待其他核心响应）。

C++11 内存序（Memory Order）的三大流派

Mon, 01 Jan 0001 00:00:00 +0000

这个问题是你打通硬件屏障之后，迈向高性能并发编程的临门一脚！

如果说 std::atomic 是C++发给你的“手枪”，那内存序（Memory Order）就是这把手枪的扳机力度。用对了，精准击杀（高性能）；用错了，走火入魔（Bug丛生）。

我们结合上一阶段讲的Store Buffer和Invalidation Queue，来看看C++11是如何把这三种“硬件武器”抽象成三个编程模型的。

核心认知：为什么要分流派？

底层硬件（ARM/RISC-V）是弱内存序（允许乱序），x86是强内存序（仅允许写-读乱序）。如果C++只提供一种“全围栏”（seq_cst），那在ARM上性能会崩塌。所以，C++11的策略是：“你（程序员）懂硬件，你就用轻量的；你不懂，就用最重的但最安全的。”

流派一：`memory_order_relaxed`（彻底放飞）

口头禅：“只保证原子性，不保证可见性，不保证顺序。”

编译器行为：不插入任何内存屏障（mfence/dmb）。CPU可以随便重排，编译器也可以随便优化。
硬件行为：允许Store Buffer延迟可见，允许Invalidation Queue堆积。

典型应用：纯计数器（比如统计QPS）。线程A加1，线程B加1，我们只关心最终累加结果，不关心A和B谁先看到谁。

std::atomic<int> counter{0};

void worker() {
    // 极度轻量，在x86上直接编译为 lock xadd（无额外屏障）
    // 在ARM上只编译为 LDXR/STXR 循环，不插入 dmb 屏障
    counter.fetch_add(1, std::memory_order_relaxed); 
}

翻车示例（千万不要这样用！）：

std::atomic<bool> ready{false};
int data = 0;

void producer() {
    data = 42;                     // 普通写（可能被重排到后面！）
    ready.store(true, std::memory_order_relaxed); // 彻底放飞
}
void consumer() {
    while(!ready.load(std::memory_order_relaxed)); // 看到true了，但data可能还是0！
    assert(data == 42); // 💥 断言失败！data的写入可能还在Store Buffer里没出来！
}

流派二：`acquire-release` 黄金搭档（精准半边墙）

这是工业界最常用的高性能并发模型！ 它理解硬件的本质：Store Buffer需要冲刷，Invalidation Queue需要清空。

硬件缓存与内存模型 on Dorkytiger 的小屋

CPU 缓存行（Cache Line）与 MESI 协议

1. 缓存行（Cache Line）：CPU缓存的最小传输单位

什么是缓存行？

为什么用缓存行？（空间局部性）

2. MESI协议：缓存一致性的"交通规则"

伪共享（False Sharing）与 内存对齐（Padding）

1. 伪共享（False Sharing）的物理真相

硬件层面的"误伤"

缓存行乒乓（Cache Line Ping-Pong）

2. 实战Demo：让伪共享现出原形

测试程序（对比有/无伪共享）

预期运行结果

编译器重排 vs CPU 乱序执行

1. 编译器重排 vs CPU乱序执行：本质区别

编译器重排（Compile-time Reordering）

CPU乱序执行（Out-of-Order Execution）

对比总结表

2. Store Buffer（写缓冲区）：CPU的"谎言"之一

为什么需要Store Buffer？

C++11 内存序（Memory Order）的三大流派

核心认知：为什么要分流派？

流派一：memory_order_relaxed（彻底放飞）

流派二：acquire-release 黄金搭档（精准半边墙）

伪共享（False Sharing）与内存对齐（Padding）

流派一：`memory_order_relaxed`（彻底放飞）

流派二：`acquire-release` 黄金搭档（精准半边墙）