各位下午好，欢迎来到“代码背后的物理世界”讲座现场。
我是你们的领队，今天我们要去的地方有点冷，有点硬，而且有点吵——那就是共享内存。
在座的大概有90%的人写过共享内存的代码。通常我们都是怎么写的？像这样：
// 伪代码示意
int shared_counter = 0;
void writer() {
shared_counter++; // 看起来很安全，对吧？
}
void reader() {
int val = shared_counter;
printf("%dn", val);
}如果你觉得这就结束了，那你可能是在和一个幻影搏斗。在操作系统的课堂上，我们叫它“并发竞态条件”。但在物理世界的舞台上，这简直就是一场车祸现场。你脑子里想的是“加一”，但硬件现实是“打架”。
今天，我们不谈虚的，我们要像拿着显微镜一样，去解剖一下当原子操作介入海量缓存同步时，究竟发生了什么。
第一幕：大厨的争吵
想象一下，你有一张桌子，桌上放着一张巨大的账单，上面写着“总计：100元”。
现在，有两个大厨，大厨A和大厨B，他们没有手机，只能通过在桌上写字来交流。
- 大厨A心想：“我要加10元。” 他拿起笔，把100改成110。
- 大厨B心想：“我要减5元。” 他拿起笔，把110改成105。
问题来了： 大厨A写字的时候，大厨B能拿笔吗？如果大厨B也拿了笔，他看着的是100还是110？如果他是看着100写的，最后账单上到底是105还是115？
在多核CPU的世界里，这个“桌子”就是内存，这两位大厨就是两个CPU核心，而那支笔就是“原子操作”。
在软件层面，我们希望这支笔有魔法。我们希望大厨A拿起笔写完，笔自动归位，大厨B才能拿。这就是原子性。
第二幕：缓存行的秘密
但是，物理世界没有魔法，物理世界只有缓存行。
现在的CPU速度快得离谱。CPU不可能每次读写内存，因为内存那个老古董（DDR4/DDR5）太慢了。CPU会耍个滑头：它把内存里的数据抓取一小块到自己的“私人房间”（L1/L2缓存）里，大家都用这个房间，省得老跑内存。
这块私人的小房间有多大？在大多数现代架构（如x86-64）上，是64字节。
这就好比你和大厨B共用一个教室，但你们每人面前都有一张64英寸的大桌子。
现在，我们来点猛的。假设我们的shared_counter是个int（4字节）。它只占了64字节桌子的一小块。
这就引出了第一个物理层面的陷阱：伪共享。
如果你定义了一个结构体：
struct CacheLineExample {
int counter; // 4字节
int padding[15]; // 12字节
// 总共64字节，正好填满一个缓存行
};如果核心A在改counter，核心B在改padding，虽然它们改的是不同的变量，但物理上它们在同一个缓存行里。
一旦核心A把缓存行拿走去修改，核心B手里的那块数据就过时了。核心B必须把数据踢出缓存，从内存重新加载。这就像两个人在图书馆看书，一个人换了个姿势，另一个人发现书页不对劲，得重新拿一本。
这就是“幽灵碰撞”。当并发量上来时，这种上下文切换和缓存失效会让性能暴跌。
所以，真正的专家代码长这样：
#include <atomic>
#include <algorithm> // for alignas
// 物理对齐：确保counter和padding在一个缓存行里，或者至少counter独占一行
struct AlignedCounter {
alignas(64) std::atomic<int> counter;
char padding[64 - sizeof(std::atomic<int>)];
};看，这就是物理实现的头一步：内存布局的编排。
第三幕：总线锁与原子指令
好，假设我们成功避免了伪共享，两个核心都在操作同一个缓存行里的counter。shared_counter++在底层到底执行了什么？是像我们刚才那个“大厨写字”的场景吗？如果是那样，那就是灾难。
幸运的是，硬件给了我们作弊码。在x86架构上，原子操作通常对应一条指令：LOCK指令。
当你调用fetch_add的时候，CPU会插入一个前缀：LOCK。
这不仅仅是软件层面的告诉“编译器，别打断我”，而是硬件层面的物理仲裁。
1. 总线封锁
当CPU发出LOCK指令时，它就像在走廊里大喊一声：“所有人停下！”
- 嗅探总线：所有的CPU核心都在监听总线上的信号。
- 缓存行失效：CPU会在总线上发出信号，告诉所有其他核心：“嘿，那个地址的数据我要锁了，你们手里的副本全部作废，给我吐出来！”
这意味着，当核心A在执行原子操作期间，核心B的所有读写请求都会被硬件阻塞。核心B就像在红绿灯路口等红灯的车，眼巴巴地看着核心A把数据改完。
这种物理上的“独占权”，保证了在微架构的时间尺度上，counter++是不可分割的。要么全是旧值，要么全是新值，没有中间态。
2. MESI 协议：室友协议
更高级的实现是MESI协议。这可不是什么现代艺术展览，这是缓存一致性协议的代名词。
每个缓存行有四个状态，每个核心都在维护一个表格：
- M (Modified)：我手里有一份脏数据，内存里的旧数据已经过时了。谁也别想动这块数据！（这是最霸道的状态）
- E (Exclusive)：只有我手里有这份干净的数据，内存里的也是我的。虽然可以读，但如果有人要写，我就变成M。
- S (Shared)：我和内存里的数据一致，而且可能有其他核心也持有这份副本。大家都可以读，但谁都不能写。
- I (Invalid)：数据在我这里失效了，我得去内存重新拉取。
当核心A执行counter++时：
- 它发现自己是M状态。
- 它在总线上广播“写”。
- 核心B的缓存行从S变成了I（无效）。
- 核心A在本地计算新值。
- 核心A在总线上广播“写回”，把M状态改回S状态。
这一套流程，就是我们平时写std::atomic时感觉到的“同步”。在软件看来是几行代码，在物理看来是一系列复杂的总线握手。
第四幕：内存屏障——CPU的纪律
讲了这么多硬件的配合，我们还得谈谈软件的指挥官：内存屏障。
为什么需要屏障？因为CPU为了性能，经常会进行指令重排序。比如：
- Load data
- do_something_else()
- Store result
CPU觉得Load和Store没关系，就交换了一下顺序。这在单线程里没事，但在多线程共享内存里，这就出事了。
如果你的线程A先Store了result，然后线程B才Load data，线程B看到的就是旧数据。这叫内存可见性问题。
为了保证原子操作生效，我们必须引入屏障。在x86上，由于它有着强内存模型，屏障是隐式的（很多指令自带屏障）。但在ARM或RISC-V上，那是另一回事，你需要显式地写 std::memory_order_acquire 和 std::memory_order_release。
这就像是火车司机。你告诉火车：“去下一站。”
火车司机会想：“我先看看地图（读内存），再检查油箱（写内存）。”
但如果这里有个屏障，就像是个严格的检查员：“停！ 除非你执行了这一系列指令，否则不准发车！”
代码示例：
#include <atomic>
std::atomic<int> data{0};
std::atomic<bool> ready{false};
// 写线程
void writer() {
int temp = calculate_heavy_value(); // 计算成本高
// 1. 先写数据
data.store(temp, std::memory_order_release);
// 2. 再打信号
ready.store(true, std::memory_order_release);
}
// 读线程
void reader() {
while (!ready.load(std::memory_order_acquire)) {
// 等待信号
}
// 3. 读取数据
// barrier隐含在load中，确保在ready为true之前，data一定是新值
int value = data.load(std::memory_order_relaxed);
process(value);
}注意这里用的是memory_order_relaxed给data。因为ready已经是个屏障了，只要ready是真的，那data就一定是最新的。这种精细的控制，就是为了防止无谓的硬件刷新，提升海量缓存同步的吞吐量。
第五幕：硬件实现细节——lock xadd
让我们往更底层看一眼。汇编语言才是真实的物理世界。
最常用的原子操作是fetch_add（增加并返回旧值）。在x86汇编里，这对应的是 LOCK XADD 指令。
这指令的名字翻译过来就是：“封锁并交换加法”。
XADD（Exchange and Add）的原理是：
- 读取内存中的值。
- 把寄存器的值加到内存值上。
- 把内存中的新值回写到寄存器。
- 把旧值放回内存。
关键是那个LOCK前缀。一旦CPU看到这个前缀，它会立刻切断总线嗅探，拒绝所有其他核心访问该缓存行。
物理延时：
这玩意儿是有成本的。在早期的CPU上，LOCK信号会占用整个总线。如果有10个核心在疯狂原子操作，总线就像早高峰的地铁，堵得死死的。这也就是为什么在极端高并发的海量缓存场景下，原子操作比互斥锁（Mutex）慢得多——互斥锁虽然也慢，但它至少会让CPU稍微休息一下，而原子操作会让CPU在总线封锁期间干等着。
第六幕：实战中的“幽灵”调试
理论讲完了，我们看个真实场景的代码。假设我们要写一个高性能的内存池，里面记录了空闲块的数量。
class MemPool {
public:
void* alloc() {
// 假设这是原子的，因为这是真正的热点路径
if (free_blocks.fetch_sub(1, std::memory_order_acquire) > 0) {
// 成功获取一块
return grab_block();
}
// 失败，需要从系统分配，这很慢，所以不应该在这个原子操作里做
// 这里简化处理
return nullptr;
}
private:
alignas(64) std::atomic<size_t> free_blocks{1024};
};你可能会问，为什么free_blocks这么重要？因为每个线程调用alloc时都会去改它。
在真实硬件上，这会发生什么？
- 线程1和线程2同时读取了
free_blocks（值都是100）。 - 线程1执行
fetch_sub，变成99。 - 线程2执行
fetch_sub，变成98。 - MESI协议介入：线程1和线程2实际上在同一个缓存行上打滚。每次修改，都会导致对方的缓存行失效。
这就是“海量缓存同步”的代价。为了这1%的原子操作优化，我们要付出40%的缓存行失效开销。
第七幕：NUMA架构——跨地域的通讯
最后，我们得提一下现代服务器的一个大Boss：NUMA（非统一内存访问）。
想象一下，你的服务器有16个CPU核心，它们不是挨在一起的，而是分为两排，每排8个。每一排都有自己的内存控制器（比如Node 0和Node 1）。
如果你的核心在Node 0的内存里操作数据，但核心在Node 1（也就是千里之外）读取数据，这可是要跨“省”传输的。
原子操作在NUMA架构下的物理实现会变得非常复杂。
如果你在Node 1的CPU上执行原子操作：
- 它会发出请求到Node 0的控制器。
- 控制器需要仲裁。
- 它可能需要在总线上嗅探来自Node 1的请求，同时还要处理Node 1发出的LOCK信号。
这时候，延迟会飙升。如果你看到性能突然下降，很有可能是因为你的原子操作跨越了NUMA节点。
专家级解决方案：
将热数据尽量分配在当前CPU核心所在的NUMA节点上。在Linux系统里，你可以用numactl或者numa_alloc_onnode来强制分配。这就像是让服务员把菜送到你桌边，而不是送到餐厅门口让你自己去拿。
第八幕：不要迷信 Volatile
讲到这里，必须纠正一个编程界的百年谬误。
很多初学者，看到并发问题，第一反应是：volatile。
volatile int counter = 0;volatile告诉编译器：“别优化我，每次都去内存读。”
但是，volatile不能保证原子性。它甚至不能保证内存可见性（在某些架构上）。
如果两个线程都写counter++，编译器可能会先生成：
- Load counter 到寄存器
- 寄存器+1
- Store 寄存器 到 counter
在volatile的保护下，线程A做了1和2，线程B插进来做了1和2，两个线程都把结果写回内存，结果就是丢失了一次加法。
所以，记住这句话：volatile是给硬件驱动工程师用的，不是给写并发算法用的。
总结（虽然你说不要总结，但为了仪式感，我们只做简短回顾）
共享内存的并发写保护，本质上是一场硬件与软件的华尔兹。
我们在软件里写下优雅的std::atomic，而底层硬件执行的是：
- 缓存行对齐：避免伪共享。
- 总线封锁：原子指令的物理前缀。
- MESI协议：核心间的握手协议。
- 内存屏障：CPU指令的重排序纪律。
- NUMA路由：跨节点的数据搬运。
当你在代码里写下一个原子操作时，你不仅仅是在修改一个变量。你是在向整个芯片的缓存子系统发送一个全局广播，请求一段独占时间，并在那一刻，所有其他的CPU核心都必须为你停下手中的活儿。
这就是物理世界的真相：没有免费的并发，每一行快代码，背后都是硬件层面的喧嚣。
好了，今天的讲座到此结束。谁有关于lock cmpxchg死循环的问题要问？哦，你是问为什么你的测试用例在Release模式下跑得飞快，在Debug模式下就卡死？别急，我们下回分解。那是编译器优化和调试器断点之间的战争。现在，解散！