深入理解 C++ 内存模型：为什么 `std::memory_order_relaxed` 并不意味着‘随机执行’？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

各位同学，各位编程爱好者，大家好！

欢迎来到今天的讲座。今天我们将深入探讨C++内存模型中一个经常被误解，但也极其重要的概念：std::memory_order_relaxed。当我们谈论并发编程时，性能和正确性往往是一对矛盾体。C++内存模型正是为了在多核处理器环境下，帮助我们在这两者之间找到平衡点而设计的。

在众多内存顺序选项中，std::memory_order_relaxed 常常让人感到困惑。许多人误以为它意味着“随机执行”，操作的顺序会变得不可预测，甚至结果也会变得随机。但事实并非如此。今天，我将作为一名编程专家，为大家揭开std::memory_order_relaxed的神秘面纱，阐明其真正的含义、工作原理、适用场景以及它为何绝不意味着“随机执行”。

引言：并发编程的挑战与C++内存模型的诞生

在单核处理器时代，程序的执行顺序相对直观：代码按照编写的顺序一步步执行。然而，随着多核处理器的普及，为了充分利用硬件资源，我们不得不转向并发编程。这意味着多个线程可能同时运行，共享相同的内存空间。

并发编程带来了巨大的性能潜力，但也引入了前所未有的复杂性。最核心的问题之一就是数据竞争（Data Race）。当至少两个线程并发访问同一个内存位置，并且其中至少一个访问是写入操作，同时这些访问没有通过适当的同步机制进行排序时，就会发生数据竞争。数据竞争会导致未定义行为（Undefined Behavior, UB），这意味着程序可能崩溃、产生错误结果，或者表现出任何出乎意料的行为，且这些行为在不同运行环境或不同时间点可能完全不同，极难调试。

为了解决数据竞争和未定义行为，我们不能仅仅依靠操作系统提供的互斥锁（如std::mutex）。互斥锁虽然能保证临界区的互斥访问，但它的开销相对较大。在某些高性能场景下，我们希望有更细粒度的控制，或者更轻量级的同步机制。

此外，现代计算机系统为了提高性能，会进行大量的优化：

编译器重排序（Compiler Reordering）：编译器会分析代码，在不改变单线程程序语义的前提下，调整指令的执行顺序，以更好地利用CPU流水线或缓存。
硬件重排序（Hardware Reordering）：CPU本身也会乱序执行指令，使用写缓冲区（Write Buffer）来暂存写入操作，以及缓存一致性协议（Cache Coherence Protocol）来管理多核缓存之间的数据同步。

这些优化在单线程环境下是透明且有益的，但在多线程环境下，它们可能导致一个线程观察到的内存操作顺序与另一个线程观察到的顺序不一致，从而引发逻辑错误。

C++11引入了内存模型（C++ Memory Model），正是为了解决这些问题。它提供了一套明确的规则，定义了在并发环境下，不同线程对共享内存的访问如何排序以及如何彼此可见。这套规则的核心就是std::atomic类型和std::memory_order枚举。

原子操作：并发编程的基石

在深入了解内存排序之前，我们必须先理解原子操作（Atomic Operations）。原子操作是C++内存模型的基础。

`std::atomic` 简介

std::atomic是一个模板类，用于封装一个类型T，并保证对该std::atomic<T>对象的读、写、修改-读等操作都是原子的。所谓原子性，指的是一个操作要么完全执行成功，要么完全不执行，中间状态对其他线程不可见。它就像一个不可分割的整体。

考虑一个简单的整型变量：

int counter = 0; // 非原子变量

如果两个线程同时执行counter++，会发生什么？
counter++看似一个操作，但在CPU层面通常分解为三个步骤：

读取counter的当前值。
将读取的值加1。
将新值写回counter。

如果线程A在步骤1和步骤2之间被抢占，线程B完成了counter++，然后线程A继续执行步骤3，那么线程A的更新就会覆盖线程B的更新，导致计数错误。这就是一个经典的数据竞争问题。

为了避免这种情况，我们可以使用std::atomic<int>：

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

std::atomic<int> atomic_counter(0); // 原子变量
int non_atomic_counter = 0;       // 非原子变量

void increment_atomic() {
    for (int i = 0; i < 100000; ++i) {
        atomic_counter++; // 原子操作
    }
}

void increment_non_atomic() {
    for (int i = 0; i < 100000; ++i) {
        non_atomic_counter++; // 非原子操作，存在数据竞争
    }
}

int main() {
    std::cout << "--- 测试非原子计数器 ---" << std::endl;
    non_atomic_counter = 0; // 重置
    std::vector<std::thread> threads_non_atomic;
    for (int i = 0; i < 10; ++i) {
        threads_non_atomic.emplace_back(increment_non_atomic);
    }
    for (auto& t : threads_non_atomic) {
        t.join();
    }
    // 预期结果：10 * 100000 = 1000000
    // 实际结果：通常小于1000000，且每次运行结果可能不同
    std::cout << "非原子计数器最终值: " << non_atomic_counter << std::endl;

    std::cout << "n--- 测试原子计数器 ---" << std::endl;
    atomic_counter = 0; // 重置
    std::vector<std::thread> threads_atomic;
    for (int i = 0; i < 10; ++i) {
        threads_atomic.emplace_back(increment_atomic);
    }
    for (auto& t : threads_atomic) {
        t.join();
    }
    // 预期结果：10 * 100000 = 1000000
    // 实际结果：总是1000000
    std::cout << "原子计数器最终值: " << atomic_counter << std::endl;

    return 0;
}

运行上述代码，你会发现non_atomic_counter的最终值几乎总是小于预期的1,000,000，并且每次运行结果可能不同，这就是数据竞争导致未定义行为的体现。而atomic_counter的最终值总是1,000,000，因为它保证了++操作的原子性。

需要注意的是，std::atomic只保证单个操作的原子性。如果你需要对多个原子操作进行组合，或者需要保护更复杂的临界区，仍然需要使用互斥锁或更高级的同步原语。

理解内存排序：`std::memory_order` 的全景

虽然原子操作保证了单个操作的完整性，但它本身并不能解决所有并发问题。比如，一个线程写入一个原子变量，然后写入另一个原子变量；另一个线程观察到这两个写入操作的顺序可能与写入线程的顺序不一致。这就是内存排序问题。

std::memory_order枚举定义了原子操作的内存同步语义，它告诉编译器和硬件如何对待这个原子操作与程序中其他内存操作的相对顺序。

C++标准定义了六种内存顺序：

| 内存顺序 | 语义
The only exception is std::memory_order_consume, which is deprecated and rarely used due to its complexity and limited practical benefits over acquire. We will focus on the more commonly used orders.

它们之间的关系与强度等级

这些内存顺序提供了不同级别的同步保障，强度从弱到强排列：

relaxed < release/acquire < acq_rel < seq_cst

relaxed: 仅保证原子性。不对内存操作的顺序做任何跨线程的保证。
release: 释放操作。保证在该操作之前的所有内存写入操作，对之后在相同原子变量上执行 acquire 操作的线程可见。
acquire: 获取操作。保证在该操作之后的所有内存读取操作，能看到之前在相同原子变量上执行 release 操作的线程所做的所有内存写入操作。
acq_rel: 获取-释放操作。兼具 acquire 和 release 的语义。对于读改写（RMW）操作，它既能像 acquire 那样看到之前的所有写入，又能像 release 那样让之后的写入对其他线程可见。
seq_cst (Sequentially Consistent): 顺序一致性。这是最强的内存顺序。它不仅提供 acquire 和 release 的所有保障，还额外保证所有 seq_cst 操作在所有线程中都以相同的、全局一致的顺序执行。所有线程看到的 seq_cst 操作的顺序是完全一致的。

`std::memory_order_relaxed` 深度解析：并非“随机执行”

现在，让我们来深入了解今天的主角：std::memory_order_relaxed。

核心定义：保证原子性，不提供跨线程排序

std::memory_order_relaxed 是最宽松的内存顺序。它对原子操作的唯一保证就是原子性。这意味着：

操作本身是原子的：无论其他线程如何并发访问，一个relaxed的读、写或读改写操作总是作为一个不可分割的单元完成。你不会看到部分写入，也不会有撕裂（tearing）的现象。这是std::atomic类型本身就提供的基本保证。
不提供跨线程的排序保证：这是relaxed的关键特性。它不保证一个线程的relaxed操作与另一个线程的relaxed操作之间有任何特定的顺序关系。编译器和硬件可以最大限度地对这些操作进行重排序，只要不违反单线程内部的因果关系。

让我们用一个例子来说明“不提供跨线程的排序保证”：

#include <atomic>
#include <thread>
#include <iostream>

std::atomic<int> x(0);
std::atomic<int> y(0);

void thread1_func() {
    x.store(1, std::memory_order_relaxed); // (1)
    y.store(1, std::memory_order_relaxed); // (2)
}

void thread2_func() {
    while (y.load(std::memory_order_relaxed) == 0); // (3) 等待y被写入
    // 此时，x是否已经为1？不确定！
    std::cout << "y is 1, x is " << x.load(std::memory_order_relaxed) << std::endl; // (4)
}

int main() {
    std::thread t1(thread1_func);
    std::thread t2(thread2_func);
    t1.join();
    t2.join();
    return 0;
}

在这个例子中，thread1_func先写入x，再写入y。thread2_func等待y变为1。一旦y变为1，thread2_func就会打印x的值。

如果你运行这段代码，你可能会发现x is 0或x is 1。
为什么会这样？

在thread1_func中，由于x.store和y.store都是relaxed操作，编译器或硬件可能会将它们的执行顺序对其他线程而言进行重排。也就是说，即使代码中x.store在y.store之前，thread2_func也可能先看到y被写入，再看到x被写入。
while (y.load(...) == 0)这一行，尽管它等待y的值变为1，但它与x的写入没有任何同步关系。y的值变化，并不意味着x的值也同步可见。

这就是relaxed操作的“无序”之处：它允许编译器和硬件最大限度地优化，不强制在这些操作之间建立任何跨线程的顺序关系。

“随机执行”的误解剖析

为什么说relaxed不意味着“随机执行”？

“随机执行”通常暗示着以下几种含义：

操作本身可能随机发生或不发生：这显然是错误的。relaxed操作依然是确定性的操作，它会执行，并且其结果是确定的（例如，写入1就是写入1）。
操作的结果是随机的：这同样是错误的。原子操作保证了结果的正确性，x.store(1)最终会使x的值变为1。
单线程内的指令顺序会随机打乱：这也是错误的。C++内存模型依然遵守happens-before原则。在一个线程内部，所有操作（无论是原子操作还是非原子操作）都严格按照程序顺序执行，除非编译器在不改变单线程语义的前提下进行重排序。relaxed只是不保证这种顺序对其他线程可见。

std::memory_order_relaxed的真正含义是：

对操作原子性的严格保证。
对单线程内部程序顺序的严格保证（即A操作在B操作之前，那么A操作的影响在B操作发生时是可见的）。
对跨线程操作之间顺序的最小化保证。它允许编译器和硬件在不破坏原子性及单线程内顺序的前提下，尽可能地进行重排序和延迟同步，以达到最佳性能。

例如，在上面的thread1_func中，x.store(1)和y.store(1)这两个操作，对于thread1自身来说，x肯定在y之前被写入（逻辑上），但对于thread2来说，由于没有同步屏障，y的写入可能先于x的写入变得可见。这里的“无序”是指可见性顺序上的无序，而不是操作执行本身的随机性。

工作原理与底层机制

要理解relaxed的本质，我们需要了解它在编译器和硬件层面是如何实现的。

编译器层面：
当编译器遇到relaxed原子操作时，它不会像处理acquire、release或seq_cst操作那样，插入内存屏障（memory barrier/fence）指令。内存屏障是一种特殊的CPU指令，它强制CPU按照特定的顺序执行内存操作，并确保某些内存操作在屏障之前或之后变得全局可见。relaxed操作的开销最小，因为它允许编译器最大限度地优化，例如将读操作提升（hoist）到循环外部，或者将写操作下沉（sink）到稍后执行，只要不影响单线程逻辑。
硬件层面：
不同的CPU架构有不同的内存模型（如x86/64的强顺序模型，ARM/PowerPC的弱顺序模型）。
- x86/64架构：其内存模型本身就相对较强，大多数普通的读写操作都具有一定的有序性。因此，std::memory_order_relaxed在x86/64上通常不会产生额外的内存屏障指令，其性能与普通非原子读写操作非常接近（但仍有原子性开销，例如对缓存行的锁定）。但这并不意味着它“什么都不做”，它仍然会保证原子性，例如通过LOCK前缀指令来保证RMW操作的原子性。
- ARM/PowerPC等弱内存模型架构：在这些架构上，硬件可以更自由地重排序读写操作。relaxed操作通常也不会插入额外的内存屏障，这使得它们比其他内存顺序的操作性能更好，但也更容易出现可见性问题。

所以，relaxed操作的“放松”体现在它不强制在编译器和硬件层面引入额外的同步开销（如内存屏障），从而允许最大的优化空间。

代码示例：计数器场景

relaxed操作最经典的适用场景就是计数器或统计数据收集。在这种场景下，我们只关心最终的累积值，而不关心中间更新的顺序。

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

std::atomic<long long> total_count(0);
const int num_threads = 8;
const long long increments_per_thread = 10000000; // 每个线程递增1000万次

void relaxed_incrementer() {
    for (long long i = 0; i < increments_per_thread; ++i) {
        // 使用memory_order_relaxed进行原子递增
        // 保证递增操作本身是原子的，但不对其可见性顺序做任何保证
        total_count.fetch_add(1, std::memory_order_relaxed);
    }
}

int main() {
    auto start_time = std::chrono::high_resolution_clock::now();

    std::vector<std::thread> threads;
    for (int i = 0; i < num_threads; ++i) {
        threads.emplace_back(relaxed_incrementer);
    }

    for (auto& t : threads) {
        t.join();
    }

    auto end_time = std::chrono::high_resolution_clock::now();
    std::chrono::duration<double> elapsed = end_time - start_time;

    long long expected_count = num_threads * increments_per_thread;
    std::cout << "预期总计数: " << expected_count << std::endl;
    std::cout << "实际总计数: " << total_count.load(std::memory_order_relaxed) << std::endl;
    std::cout << "耗时: " << elapsed.count() << " 秒" << std::endl;

    // 为了对比，我们也可以尝试使用std::memory_order_seq_cst
    // 通常性能会略差，但结果相同
    std::atomic<long long> total_count_seq_cst(0);
    start_time = std::chrono::high_resolution_clock::now();
    std::vector<std::thread> threads_seq_cst;
    for (int i = 0; i < num_threads; ++i) {
        threads_seq_cst.emplace_back([](){
            for (long long j = 0; j < increments_per_thread; ++j) {
                total_count_seq_cst.fetch_add(1, std::memory_order_seq_cst);
            }
        });
    }
    for (auto& t : threads_seq_cst) {
        t.join();
    }
    end_time = std::chrono::high_resolution_clock::now();
    elapsed = end_time - start_time;
    std::cout << "n--- 使用 seq_cst ---" << std::endl;
    std::cout << "实际总计数 (seq_cst): " << total_count_seq_cst.load(std::memory_order_seq_cst) << std::endl;
    std::cout << "耗时 (seq_cst): " << elapsed.count() << " 秒" << std::endl;

    return 0;
}

运行这个例子，你会发现无论是使用relaxed还是seq_cst，最终的total_count总是正确的1,000,000 * 8 = 80,000,000。这是因为fetch_add操作本身就是原子性的，它保证了每次递增操作都是完整的，不会丢失。

然而，在使用relaxed时，你无法保证线程A的某个递增操作在线程B的某个递增操作之后发生，即使从时间戳上看线程A的操作先完成。你只能保证最终结果的正确性。对于这种简单的计数器，我们通常只关心最终值，而不关心中间的精确顺序，因此relaxed是一个非常合适的选择，因为它提供了最佳的性能。

`relaxed` 的适用场景与局限性

理解relaxed的真正含义后，我们才能正确地判断其适用场景和规避其局限性。

适用场景

计数器和统计量：
如上例所示，当多个线程独立地更新一个共享计数器，且我们只关心最终的累积值，而不在乎中间更新的精确顺序时，relaxed是理想的选择。例如，统计网站访问量、记录日志事件数量等。
```
std::atomic<long long> hit_count(0);
void process_request() {
    // ... 处理请求 ...
    hit_count.fetch_add(1, std::memory_order_relaxed); // 简单记录请求次数
}
```

一次性设置的标志位（但需谨慎）：
如果一个标志位只被设置一次（从0到1），并且其设置不需要与其他内存操作进行同步，那么可以使用relaxed。然而，这通常是危险的，因为消费者线程可能看到标志位已设置，但看不到生产者线程在设置标志位之前写入的其他数据。

// 危险示例，不推荐
std::atomic<bool> is_ready(false);
int data[10];

void producer() {
    for(int i=0; i<10; ++i) data[i] = i; // 写入数据
    is_ready.store(true, std::memory_order_relaxed); // 设置标志
}

void consumer() {
    while (!is_ready.load(std::memory_order_relaxed)); // 等待标志
    // 此时，data数组的内容可能尚未完全可见！存在数据竞争。
    for(int i=0; i<10; ++i) std::cout << data[i] << " ";
    std::cout << std::endl;
}
// 正确的做法是使用 acquire-release 语义。

这个例子展示了relaxed的局限性：它不提供同步，因此is_ready变为true并不能保证data数组的写入也对消费者可见。

某些无锁数据结构中的非关键路径操作：
在高度优化的无锁数据结构中，有时会将一些不影响数据结构逻辑完整性，但用于追踪状态或辅助调试的原子变量设置为relaxed。例如，一个队列的消费者数量、一个哈希表的冲突计数等。但核心的指针交换、节点链接等操作，几乎总是需要更强的内存顺序（如acquire/release或seq_cst）。

局限性

std::memory_order_relaxed最大的局限性在于它不能用于同步。它无法保证一个线程写入的数据对另一个线程可见，除非有其他同步机制（如std::mutex、std::thread::join或更强的原子操作）介入。

如果你试图使用relaxed操作来建立因果关系（例如，“我看到A发生了，所以B也一定发生了”），你很可能会遇到难以调试的并发错误。

以下是relaxed的典型错误使用场景：

发布-订阅模型：如果一个线程发布数据，并通过relaxed标志通知其他线程，其他线程在看到标志后去读取数据，那么数据可能尚未完全发布或不可见。
资源初始化：一个线程初始化一个复杂对象，然后用relaxed标志表示初始化完成。另一个线程看到标志后就去使用该对象，可能导致使用未完全初始化的对象。
状态机转换：如果一个状态机的转换需要确保某些前置操作已经完成并对所有线程可见，relaxed操作不足以提供这种保证。

与其他内存顺序的对比：为何选择 `relaxed`？

为了更好地理解relaxed，我们有必要将其与更强的内存顺序进行对比。

| std::memory_order_release | 写入操作。保证当前操作之前的所有内存写入操作对所有线程可见，并且不能被重排到该操作之后。

引言：并发编程的挑战与C++内存模型的诞生

原子操作：并发编程的基石

std::atomic 简介

理解内存排序：std::memory_order 的全景

它们之间的关系与强度等级

std::memory_order_relaxed 深度解析：并非“随机执行”