C++11引入了标准化的内存模型和多线程支持。这不是简单地在语言层面加了几个库——它重新定义了C++程序在并发环境下的行为基础。理解这个内存模型，是写出正确并发程序的前提。
一、内存模型：为什么需要它
多线程环境下，代码的执行顺序不是源代码顺序。编译器的指令重排、CPU的乱序执行、CPU缓存的不一致性，都会导致一个线程看到的内存操作顺序与另一个线程看到的顺序不同。
硬件上，CPU通过缓存一致性协议（如MESI）保证同一地址的读写顺序，但对不同地址的操作可能被重排。x86架构以较强的内存顺序著称，它保证load-load和load-store有序。ARM和PowerPC架构的内存模型则宽松得多——读操作可以越过写操作执行，编译器也可以任意重排内存访问指令。跨平台代码必须考虑这些差异。
内存模型定义了“什么情况下，一个线程的写入对另一个线程可见”。它提供了两种保证：原子性（操作不可分割）和可见性（写入能被其他线程看到）。没有这些保证，并发程序的行为在逻辑上无法推理。
二、原子操作：硬件的支持
std::atomic<T>提供了原子操作，保证对共享变量的读写不会产生数据竞争。
cpp
std::atomic<int> counter{0}; counter.fetch_add(1, std::memory_order_acq_rel);原子操作通常映射到CPU的原子指令（如x86的LOCK前缀、ARM的LDREX/STREX）。如果硬件不支持，编译器会退回到使用锁保护，但其接口保持一致。
std::atomic<bool>、std::atomic<int>、std::atomic<指针>是常用类型。自定义类型也可以作为原子类型，前提是它满足is_trivially_copyable约束——类型可以逐字节复制而不需要自定义拷贝构造或析构逻辑。
硬件层面，原子操作的可用性随平台变化。x86提供完整的原子操作支持，而ARM的LL/SC机制可能在某些条件下重试或失败，需要编译器在生成机器码时处理这些分支。
三、内存序：控制可见性的粒度
std::memory_order参数允许程序员在原子操作上指定内存序，在性能与正确性之间做权衡。
宽松顺序（memory_order_relaxed）：仅保证操作的原子性，不保证操作的顺序。同一线程内，不同原子操作的顺序可能被重排。不同线程之间没有可见性保证，除非操作同一个原子变量。fetch_add(1, relaxed)用于不需要同步语义的计数器，一个线程累加，另一个线程只读取最终值，中间值不重要。
获得-释放顺序（memory_order_acquire/memory_order_release）：成对使用，建立同步关系。释放操作之前的写入，在对应的获得操作之后可见。
cpp
std::atomic<bool> ready{false}; int data = 0; void producer() { data = 42; ready.store(true, std::memory_order_release); } void consumer() { while (!ready.load(std::memory_order_acquire)); // data == 42 保证成立 }release之前的写入在acquire返回后对消费者可见。这种顺序常用于一对一的线程通信，一个生产者写入数据，一个消费者读取。
顺序一致性（memory_order_seq_cst）：最严格的内存序，全局存在一个一致的操作顺序。所有线程看到的内存操作顺序相同。实现上，编译器会插入完整的内存屏障，防止所有重排。
cpp
std::atomic<bool> flag{false}; int value = 0; // 线程A value = 100; flag.store(true, std::memory_order_seq_cst); // 线程B while (!flag.load(std::memory_order_seq_cst)); // value == 100代价是性能开销，频繁使用时显著影响吞吐量。
消费-释放顺序（memory_order_consume）：这是release的优化版本，仅保证依赖的数据可见，不保证所有操作。C++17中，consume的语义尚未完全实现，编译器通常将其提升为acquire，按acquire处理。
四、锁与无锁编程
std::mutex是对底层系统锁的封装。std::lock_guard和std::unique_lock通过RAII管理锁的生命周期。
互斥锁的代价可能包含：系统调用开销（如果锁被占用，线程进入内核态睡眠）、自旋开销（等待锁的线程短暂自旋）、上下文切换开销（线程在排队等待时被切换出去）。过度加锁是并发程序性能下降的常见原因。
无锁编程使用原子操作代替锁，目标是避免阻塞。std::atomic配合适当的内存序是实现无锁数据结构的基础。
cpp
// 无锁栈的部分实现 struct Node { int value; Node* next; }; std::atomic<Node*> head{nullptr}; void push(int value) { Node* new_node = new Node{value, head.load()}; while (!head.compare_exchange_weak(new_node->next, new_node)) { // 更新失败时，head已变化，new_node->next更新为当前head } }compare_exchange_weak是典型的CAS（比较并交换）操作。weak版本在部分平台上因指令限制可能出现假失败，循环重试即可解决；compare_exchange_strong保证不会假失败。
无锁编程的难度：ABA问题（需要版本号解决）、内存管理（节点何时安全释放）等。通常优先使用锁，锁成为瓶颈时再考虑无锁方案。
五、线程安全的设计
设计线程安全的类时，不变量的维护是关键——类的方法执行前后，对象状态必须保持有效。多个方法组合使用时，外部加锁比内部同步更可靠。
cpp
class ConcurrentCounter { mutable std::mutex mtx; int count{0}; public: void increment() { std::lock_guard<std::mutex> lock(mtx); ++count; } int get() const { std::lock_guard<std::mutex> lock(mtx); return count; } };get和increment各自是线程安全的，但if (counter.get() > 0) counter.decrement()组合操作外部加锁保护。
六、典型工程陷阱
死锁：两个线程各自持有一个锁并等待对方持有的锁。预防措施包括锁的固定顺序获取、使用std::lock同时获取多个锁。
数据竞争：一个线程写入变量，另一个线程同时读取该变量，且没有同步机制。数据竞争导致未定义行为——程序可能崩溃或产生不可预测的结果。
虚假唤醒：条件变量的wait可能在没有收到通知时返回，必须循环检查条件。
cpp
while (!condition) { cv.wait(lock); }七、小结
C++的内存模型不是抽象的概念，它对实际代码有直接影响。原子操作和内存序控制在性能与正确性之间提供了选择，release-acquire提供同步，relaxed允许最大程度的优化，seq_cst保证一致的顺序。这些工具不是为所有代码设计的，而是为正确实现并发数据结构准备的。错误的内存序会导致难以复现的数据竞争——选择正确的内存序需要对底层模型有准确的理解。
