自动关联目录：并发与内存序

并发问题的根源是：编译器、CPU、缓存都会重排你的代码，只要"单线程看起来一样"。多线程崩溃，几乎都是因为你假定了某种顺序，而没人向你保证过这个顺序。

一句话定位：用 mutex 就不用管内存序；只有为了性能放弃锁时，才需要理解六种 memory_order。

数据竞争

// 数据竞争 = 两个线程访问同一内存，至少一个写，且没有同步
int Counter = 0;
void Inc() { ++Counter; }   // 多线程调用 → 未定义行为

数据竞争是未定义行为，不是"可能算错"。编译器可以假设没有竞争，从而做出让你崩溃的优化（比如把循环里的读提到循环外）。

排查工具：ThreadSanitizer（-fsanitize=thread）、UE 侧的 FThreadSafeCounter 与断言。

互斥

std::mutex M;
int Counter = 0;

void Inc()
{
    std::lock_guard<std::mutex> Lock(M);   // RAII，见 [移动语义与 RAII](/fddca970.html)
    ++Counter;
}

// 同时锁两个，用 scoped_lock 避免死锁
std::scoped_lock Lock(MA, MB);

锁的代价不是"慢"，是"串行化"：临界区越长，并行度越低。优化方向是缩小临界区，不是换更快的锁。

原子与内存序

std::atomic<bool> Ready{false};
std::atomic<int>  Data{0};

// 线程 1
Data.store(42, std::memory_order_relaxed);
Ready.store(true, std::memory_order_release);

// 线程 2
if (Ready.load(std::memory_order_acquire))
{
    int V = Data.load(std::memory_order_relaxed);   // 保证看到 42
}

默认用 seq_cst。只有在确认是性能瓶颈（profile 证明）时才降级，而且必须能说清为什么安全。

理解 acquire/release 的口诀：

• release："我之前做的所有事，对拿到这个值的线程可见"
• acquire："拿到这个值之后，我能看到对方之前做的所有事"

两者配对使用（release 存、acquire 读）就构成了一次同步。

常见模式

// 典型的"发布"模式
void Producer()
{
    Payload = ComputeSomething();          // 普通写
    Ready.store(true, std::memory_order_release);
}

void Consumer()
{
    if (Ready.load(std::memory_order_acquire))
    {
        Use(Payload);                       // 安全：能看到 Producer 之前的所有写
    }
}

伪共享（False Sharing）

// 两个原子变量在同一缓存行 → 两核互相使对方缓存失效
struct alignas(64) Padded    // 缓存行对齐
{
    std::atomic<int> A;
};

解决：按 64 字节（缓存行大小）对齐或填充。这是"加了线程反而更慢"的经典原因。

与 OS / 硬件的关系

本页是语言层的内存模型；对应的下层在：

• 硬件为什么能重排：Computer Organization（流水线、缓存一致性）
• 操作系统提供的原语：Operating system / 并发（锁的实现、条件变量、死锁）

三层是同一件事的三个视角：硬件提供重排能力 → OS 提供同步原语 → 语言定义内存模型。

死锁

最实用的一条：给所有锁编号，永远按编号从小到大获取。

UE 侧对照

UE 里并发的第一约束不是内存序，而是"哪些东西只能在游戏线程碰"：UObject、Actor 的创建与销毁、渲染资源。跨线程访问这些，加锁也没用。

常见坑