JavaScript 内存模型：顺序一致性（Sequential Consistency）与 TSO（Total Store Order）的差异

各位同仁，各位对JavaScript深感兴趣的开发者们，下午好！

今天，我们聚焦一个在JavaScript生态中相对年轻，但至关重要的概念：内存模型。长期以来，JavaScript以其单线程、事件循环的特性，让开发者们在并发编程的泥沼中得以喘息。然而，随着Web Workers、Service Workers的普及，特别是SharedArrayBuffer的引入，多线程共享内存的潘多拉魔盒被打开，我们不得不直面并发编程中最晦涩、最棘手的问题之一：内存一致性。

当多个线程试图同时访问和修改同一块内存区域时，我们不能再简单地假设代码会按照我们编写的顺序执行，也不能假设一个线程的写入会立即对所有其他线程可见。这种直觉上的“顺序一致性”在现代硬件和编译器优化面前，早已不堪一击。理解这些底层机制，特别是像Total Store Order (TSO) 这样的硬件内存模型，以及JavaScript如何通过其Atomics API构建自己的内存模型，对于编写健壮、高效的并发JavaScript代码至关重要。

一、 内存模型：编程的“社会契约”

在我们深入探讨顺序一致性（Sequential Consistency, SC）和Total Store Order (TSO) 之前，我们首先需要理解“内存模型”到底是什么。

1.1 处理器、缓存与内存的性能鸿沟

现代计算机系统是一个多层次的结构。CPU的速度与主内存（DRAM）的速度之间存在着巨大的鸿沟。为了弥补这个鸿沟，处理器引入了多级高速缓存（L1、L2、L3 Cache）。

• L1 Cache (一级缓存): 紧邻CPU核心，速度最快，容量最小，通常分为数据缓存和指令缓存。
• L2 Cache (二级缓存): 稍慢于L1，容量更大，通常每个核心或一组核心拥有一个。
• L3 Cache (三级缓存): 速度最慢，容量最大，通常由所有核心共享。
• Main Memory (主内存/RAM): 容量最大，速度最慢，是所有数据的最终归宿。

数据在这些层次之间移动，以满足CPU的计算需求。当CPU需要数据时，它首先检查L1，然后L2，L3，最后才去主内存。写入数据时，也可能先写入缓存，再“惰性”地刷回主内存。

1.2 缓存一致性协议与内存乱序

在单核时代，缓存的存在虽然引入了数据同步的问题（例如写回策略），但由于只有一个执行流，问题相对简单。然而，在多核处理器中，每个核心都有自己的L1/L2缓存，它们可能拥有同一块主内存区域的副本。这就引出了缓存一致性（Cache Coherence）问题：如何确保所有核心看到的同一内存位置的数据副本是一致的？

为了解决这个问题，硬件设计者开发了各种缓存一致性协议，例如著名的MESI (Modified, Exclusive, Shared, Invalid) 协议及其变种。这些协议通过监听（snooping）总线上的操作，在不同核心之间传递消息（如“我修改了这个数据，请你把你的副本标记为无效”），从而保证了数据在物理层面上的一致性。

然而，缓存一致性协议保证的是数据副本的最终一致性，它并不保证内存操作的可见顺序。为了进一步提高性能，现代处理器和编译器会进行大量的优化，其中最主要的就是乱序执行（Out-of-Order Execution）和内存操作重排序（Memory Reordering）。

• 指令重排序（Instruction Reordering）: 编译器和CPU为了充分利用流水线，可能会改变指令的执行顺序，只要不改变单个线程的可见行为（即满足数据依赖）。
• 写缓冲/存储缓冲（Store Buffer/Write Buffer）: 当CPU执行写操作时，它可能不会立即将数据写入缓存或主内存，而是先放入一个称为“写缓冲”的临时队列中。CPU可以继续执行后续指令，而写操作则在后台慢慢完成。这大大提高了写入操作的吞吐量，但副作用是，一个核心的写入可能暂时只对该核心自身可见，而对其他核心不可见。
• 失效队列（Invalidate Queue）: 类似写缓冲，用于处理来自其他核心的缓存失效请求。

这些优化虽然显著提升了单线程程序的性能，但它们在多线程共享内存的场景下，可能会导致一个核心看到的内存操作顺序与另一个核心看到的顺序不同，从而引发难以预料的错误。

1.3 内存模型的诞生

正因为硬件和编译器会进行这些复杂的重排序和优化，我们程序员不能再简单地假设内存操作会严格按照代码顺序执行，并且立即对所有线程可见。我们需要一个明确的“契约”或“规范”来定义在多线程环境下，内存操作的可见性和顺序性。这个契约就是内存模型（Memory Model）。

内存模型回答了以下关键问题：

• 一个线程的写操作何时对其他线程可见？
• 一个线程的读操作何时能看到另一个线程的写操作？
• 内存操作的执行顺序与程序代码的顺序有什么关系？

不同的内存模型在性能和编程复杂度之间做出了不同的权衡。从最严格的顺序一致性到最宽松的弱内存模型，它们为程序员提供了不同的保证级别。

二、 顺序一致性（Sequential Consistency, SC）：理想但昂贵

顺序一致性（Sequential Consistency），由Leslie Lamport在1979年提出，是内存模型中最直观、最严格的理想模型。

2.1 SC的定义

Lamport的定义是：

"The result of any execution is the same as if the operations of all the processors were executed in some sequential order, and the operations of each individual processor appear in this sequence in the order specified by its program."

翻译过来就是：

“任何执行的结果都等同于所有处理器上的操作以某种顺序交错执行，并且每个单独处理器上的操作在该序列中按照其程序指定的顺序出现。”

简单来说，SC模型有两大核心保证：

1. 程序顺序（Program Order）: 每个线程内部的内存操作都严格按照它们在代码中出现的顺序执行。
2. 全局顺序（Global Order）: 所有线程的内存操作（包括读和写）会以某种单一的、全局的、总体的顺序交错执行。所有线程都观察到这个相同的全局顺序。

这意味着，在SC模型下，你永远不会看到一个线程内部的指令被重排序，也不会看到一个线程的写操作对某些线程可见而对另一些线程不可见。一切都像是在一个单一的处理器上，所有线程的操作严格按照某种时间线穿插执行。

2.2 SC的优势与劣势

• 优势:
  • 直观易懂: 它的行为与我们直觉上的“一步步执行”模型完全一致，极大地简化了并发程序的推理。
  • 编程简单: 程序员不需要关心底层的重排序和可见性问题，可以专注于业务逻辑。
• 劣势:
  • 性能低下: 为了实现SC的严格保证，硬件和编译器必须放弃大量的性能优化手段。例如，处理器不能使用写缓冲来隐藏写延迟，也不能进行任何可能改变跨线程可见性的指令重排序。这会导致CPU的效率大大降低，因为它不得不经常等待内存操作完成。
  • 不切实际: 现代高性能处理器几乎都不直接实现SC作为其默认的硬件内存模型。

2.3 SC下的代码示例（假设场景）

假设我们有一个SharedArrayBuffer，被两个Web Worker共享。

// shared_memory.js
const sab = new SharedArrayBuffer(8); // 2 * Int32
const arr = new Int32Array(sab);

// Worker A (在workerA.js中运行)
// arr[0] = 0; arr[1] = 0; // 初始状态

function workerA() {
    arr[0] = 1; // (A1)
    arr[1] = 2; // (A2)
}

// Worker B (在workerB.js中运行)
function workerB() {
    let r1 = arr[1]; // (B1)
    let r0 = arr[0]; // (B2)
    console.log(`Worker B: r1 = ${r1}, r0 = ${r0}`);
}

在SC模型下，我们期望的行为是：

如果Worker B读取到r1为2，那么它必须读取到r0为1。不可能出现r1为2但r0为0的情况。

为什么？因为：

1. Worker A的A1操作 (arr[0] = 1) 必定发生在A2操作 (arr[1] = 2) 之前（程序顺序）。
2. 在SC模型下，如果B看到了A2的结果（arr[1]是2），那么它也必须看到A1的结果（arr[0]是1），因为所有操作都以一个单一的、全局的顺序交错。A2发生在A1之后，如果B看到了A2，就意味着它看到了A1以及之前的所有操作。

然而，在实际的硬件中，这并非总是成立。

三、 宽松内存模型：性能与复杂性的平衡

由于SC模型过于严格，不利于性能优化，现代处理器和编译器普遍采用宽松内存模型（Relaxed Memory Models）。这些模型允许在不改变单线程语义的前提下，对内存操作进行重排序和延迟可见性。

3.1 内存操作重排序的类型

宽松内存模型通过允许以下四种类型的内存操作重排序来提升性能：

1. 读-读重排序 (R-R Reordering): 两个读操作的顺序可以被交换。
   • r1 = arr[0]; r2 = arr[1]; 可能实际执行为 r2 = arr[1]; r1 = arr[0];
2. 读-写重排序 (R-W Reordering): 一个读操作与一个写操作的顺序可以被交换。
   • r1 = arr[0]; arr[1] = 2; 可能实际执行为 arr[1] = 2; r1 = arr[0];
3. 写-读重排序 (W-R Reordering): 一个写操作与一个读操作的顺序可以被交换。
   • arr[0] = 1; r1 = arr[1]; 可能实际执行为 r1 = arr[1]; arr[0] = 1;
   • 这是导致许多并发问题的主要类型，例如我们后面会提到的TSO模型。
4. 写-写重排序 (W-W Reordering): 两个写操作的顺序可以被交换。
   • arr[0] = 1; arr[1] = 2; 可能实际执行为 arr[1] = 2; arr[0] = 1;

不同的硬件架构支持不同程度的重排序。例如，x86架构相对较强（接近TSO），而ARM架构则更弱（允许更多重排序）。

3.2 内存屏障（Memory Barriers/Fences）

为了在宽松内存模型下仍然能够保证正确的并发行为，程序员需要使用内存屏障（也称为内存栅栏或内存栅）。内存屏障是一种特殊的指令，它强制处理器在屏障前后的内存操作之间建立起一个严格的顺序关系。

常见的内存屏障类型：

• 写屏障（Store Fence/Release Fence）: 确保屏障之前的所有写操作都已完成并对其他处理器可见，然后再执行屏障之后的写操作。
• 读屏障（Load Fence/Acquire Fence）: 确保屏障之后的所有读操作都能看到屏障之前所有处理器完成的写操作。
• 全屏障（Full Fence/Memory Fence）: 结合了读写屏障的功能，确保屏障之前的所有读写操作都在屏障之后的所有读写操作之前完成。

这些屏障是构建更高级同步原语（如锁、原子操作）的基础。

四、 Total Store Order (TSO)：x86/SPARC的现实

Total Store Order (TSO) 是一种具体的宽松内存模型，它在性能和一致性之间做出了特定的权衡。TSO模型通常与x86和SPARC处理器架构相关联，尽管它们之间有细微差别，但核心思想是相似的。

4.1 TSO的核心特性

TSO模型比SC模型宽松，但比其他一些弱内存模型（如PowerPC或ARMv7之前的模型）要强。它主要放松了写-读重排序（W-R Reordering）。

在TSO模型中，一个核心的写操作可能不会立即对所有其他核心可见，因为这些写操作会先进入该核心的写缓冲（Store Buffer）。然而，该核心自身可以立即从其写缓冲中读取到自己刚刚写入的数据，即使这些数据尚未刷回共享缓存或主内存。

这意味着：

1. 本线程的写操作对其本线程的读操作是立即可见的。
2. 本线程的写操作对其他线程的可见性是延迟的。
3. 其他线程的写操作对本线程的读操作也是延迟的。

TSO对程序顺序的保证：

• R -> R (读后读): 保持程序顺序。
• R -> W (读后写): 保持程序顺序。
• W -> W (写后写): 保持程序顺序。
• W -> R (写后读): 不保持程序顺序！ 这是TSO与SC的主要区别。一个读操作可以“越过”一个之前的写操作，直接从内存中读取旧值，而之前的写操作还在写缓冲中等待。

4.2 TSO下的“写缓冲旁路”（Store Buffer Bypass）现象

考虑以下经典的TSO示例，它展示了写-读重排序如何影响并发程序的行为。

// shared_data.js
const sab = new SharedArrayBuffer(8); // 2 * Int32
const data = new Int32Array(sab);
const flag = new Int32Array(sab, 4); // flag at index 1

// 初始状态: data[0] = 0, flag[0] = 0

// Worker A (Publisher)
function workerA() {
    data[0] = 1;   // A1: Write data
    flag[0] = 1;   // A2: Set flag
}

// Worker B (Consumer)
function workerB() {
    let r1 = 0;
    while ( (r1 = flag[0]) === 0); // B1: Wait for flag to be 1
    let r2 = data[0];            // B2: Read data

    console.log(`Worker B: r1 = ${r1}, r2 = ${r2}`);
}

在SC模型下，如果r1读取到1，那么r2必须读取到1。不可能出现r2为0的情况。

但在TSO模型下，情况就不同了：

1. Worker A:

   • A1 (data[0] = 1): 数据1被写入Worker A的写缓冲。
   • A2 (flag[0] = 1): 标志1被写入Worker A的写缓冲。由于W->W保持顺序，flag[0]的写操作会在data[0]的写操作之后进入写缓冲。
   • 写缓冲中的数据会被异步地刷回共享缓存。

2. Worker B:

   • B1 (while (flag[0] === 0)): Worker B不断读取flag[0]。
   • 假设在某个时间点，flag[0]的值从Worker A的写缓冲刷回共享缓存，并最终对Worker B的缓存可见。Worker B读取到flag[0] === 1，退出循环。
   • B2 (let r2 = data[0]): Worker B尝试读取data[0]。

TSO下可能发生的问题：

由于TSO允许写-读重排序，并且写操作会先进入写缓冲，Worker A的data[0] = 1虽然在程序顺序上先于flag[0] = 1，但data[0] = 1这个写操作可能仍在Worker A的写缓冲中，尚未对Worker B可见。而flag[0] = 1这个写操作可能已经从写缓冲刷出，并对Worker B可见了。

因此，Worker B在看到flag[0] === 1之后，读取data[0]时，可能仍然读到旧值0。这就是所谓的“写缓冲旁路”（Store Buffer Bypass）现象。Worker B的读操作“绕过”了Worker A的写操作，看到了一个不一致的状态。

这个例子深刻地揭示了SC与TSO之间的差异。在TSO这样的宽松内存模型下，如果不使用适当的同步机制，程序的行为将变得不可预测。

五、 JavaScript的内存模型：基于C++11的Atomics

JavaScript作为一种高级语言，其内存模型通常被底层实现（浏览器引擎、Node.js运行时）所定义。在SharedArrayBuffer出现之前，由于JavaScript是单线程执行的（主线程），内存一致性问题并不突出，因为所有内存访问都在同一个线程上下文中。但SharedArrayBuffer和Web Workers的结合，使得JavaScript进入了真正的多线程共享内存时代，从而需要一个明确的内存模型。

JavaScript的内存模型，特别是对于SharedArrayBuffer和Atomics API，是基于C++11的内存模型的。C++11内存模型是一个非常强大且灵活的模型，它允许开发者选择不同强度的内存序（memory order）来平衡性能和正确性。

5.1 Data-Race-Free (DRF) 的保证

JavaScript的内存模型设计的一个核心原则是数据竞争自由（Data-Race-Free, DRF）。

• 数据竞争（Data Race）: 当两个或多个线程同时访问同一内存位置，至少有一个访问是写入，且这些访问之间没有通过同步操作（如锁或原子操作）进行排序时，就发生了数据竞争。
• DRF 保证: JavaScript的内存模型规定，如果一个程序是数据竞争自由的（即所有对SharedArrayBuffer的共享内存访问都通过Atomics操作进行），那么它的行为就好像是顺序一致的。换句话说，如果你正确地使用了Atomics API，那么你就可以享受SC模型带来的易于推理的编程体验。

然而，如果程序中存在数据竞争（即你混合使用了常规的arr[idx] = value和Atomics操作，并且常规操作之间存在未同步的并发访问），那么程序的行为就是未定义的。这与C++11内存模型中的约定一致。

5.2 Atomics API：JavaScript的内存屏障

Atomics对象提供了一系列原子操作，它们不仅保证了操作本身的原子性（即不可中断性），更重要的是，它们提供了内存同步（Memory Synchronization）功能，充当了内存屏障。

Atomics操作支持不同的内存顺序（memory order），尽管在JavaScript中，这些选项通常是隐含的或默认设置为最强的"seqcst"（顺序一致）。

• Atomics.load(typedArray, index): 默认具有获取（Acquire）语义。这意味着在Atomics.load操作之后的任何内存访问，都保证能看到在Atomics.load操作之前，由其他线程完成的、并已经对当前线程可见的写操作。它阻止了Atomics.load之后的读操作与Atomics.load之前的内存操作发生重排序。
• Atomics.store(typedArray, index, value): 默认具有释放（Release）语义。这意味着在Atomics.store操作之前的任何内存访问（特别是写操作），都保证在Atomics.store操作本身对其他线程可见之前，就已经对这些线程可见。它阻止了Atomics.store之前的写操作与Atomics.store之后的内存操作发生重排序。
• Atomics.compareExchange(typedArray, index, expectedValue, replacementValue): 默认具有顺序一致（Sequential Consistent, "seqcst"）语义。它结合了获取和释放语义，并且参与到一个所有seqcst原子操作的全局总顺序中。
• Atomics.add, Atomics.sub, Atomics.and, Atomics.or, Atomics.xor, Atomics.exchange: 这些操作也默认是顺序一致的。
• Atomics.wait, Atomics.notify: 用于线程间的等待和唤醒，也具有内存同步效果。
• Atomics.fence(order): 提供显式的内存屏障。order可以是"seqcst"（默认），"acq_rel"，"acquire"，"release"。这是最直接的内存屏障，可以独立于原子操作使用。

5.3 重访TSO示例，这次用JavaScript Atomics

让我们用Atomics来修正之前在TSO模型下可能出错的“写缓冲旁路”示例。

// shared_data_with_atomics.js
const sab = new SharedArrayBuffer(8); // 2 * Int32
const data = new Int32Array(sab);
const flag = new Int32Array(sab, 4); // flag at index 1

// 初始状态: data[0] = 0, flag[0] = 0

// Worker A (Publisher)
function workerA() {
    data[0] = 123;   // A1: 非原子写入 (data[0])
    Atomics.store(flag, 0, 1); // A2: 原子写入 (flag[0])，具有释放语义
}

// Worker B (Consumer)
function workerB() {
    let r1 = 0;
    while ( (r1 = Atomics.load(flag, 0)) === 0); // B1: 原子读取 (flag[0])，具有获取语义
    let r2 = data[0];            // B2: 非原子读取 (data[0])

    console.log(`Worker B: r1 = ${r1}, r2 = ${r2}`);
}

在这个例子中：

1. A1 (data[0] = 123): 这是一个常规的非原子写入。它可能被重排序，也可能不是立即对其他线程可见。
2. A2 (Atomics.store(flag, 0, 1)): 这是一个原子写入，并且默认具有释放（Release）语义。这意味着：
   • 所有在A2之前的内存写入（例如A1写入data[0]）都必须在A2操作对其他线程可见之前，先对这些线程可见。
   • A2操作本身是原子性的。
3. B1 (Atomics.load(flag, 0)): 这是一个原子读取，并且默认具有获取（Acquire）语义。这意味着：
   • 所有在B1操作之后的内存读取（例如B2读取data[0]）都保证能看到在B1操作之前，由其他线程完成的、并已经对当前线程可见的写操作。
   • B1操作本身是原子性的。

结果：

由于Atomics.store的释放语义和Atomics.load的获取语义，它们协同工作，形成了一个同步屏障。

• Worker A的A2操作（Atomics.store）保证了A1操作（data[0] = 123）在A2对Worker B可见之前，也对Worker B可见。
• Worker B的B1操作（Atomics.load）在看到flag[0] === 1之后，保证了B2操作（data[0]的读取）能看到A1写入的123。

因此，在这个修正后的代码中，Worker B打印的r2必须是123。JavaScript的Atomics API有效地为我们提供了比底层TSO硬件模型更强的内存一致性保证，使其行为在同步操作点上更接近顺序一致性。

5.4 Atomics.fence() 的作用

虽然Atomics.load和Atomics.store隐式地提供了内存屏障，但有时我们可能需要更显式的控制，或者只是需要一个屏障而不需要进行原子读写。这时就可以使用Atomics.fence()。

// Worker A
sharedArray[0] = 1;
sharedArray[1] = 2;
Atomics.fence('release'); // 确保之前的写操作都已对其他线程可见
sharedArray[2] = 3; // 此写操作不受前一个 fence 影响

// Worker B
Atomics.fence('acquire'); // 确保之后的读操作能看到在 fence 之前所有线程完成的写操作
let val0 = sharedArray[0];
let val1 = sharedArray[1];
let val2 = sharedArray[2]; // 这个读操作可能看不到 Worker A 的 sharedArray[2]=3

Atomics.fence()接受一个可选的order参数，可以是"seqcst"、"acq_rel"、"acquire"或"release"。默认是"seqcst"，提供最强的保证。

• 'acquire' 类似于Atomics.load，保证后续内存访问能看到屏障前其他线程的写操作。
• 'release' 类似于Atomics.store，保证屏障前本线程的写操作能被后续其他线程的读操作看到。
• 'acq_rel' 结合了acquire和release。
• 'seqcst' 提供最强的顺序一致性保证，它既是acquire屏障又是release屏障，并且参与到所有seqcst操作的全局顺序中。

六、 总结与最佳实践

理解JavaScript的内存模型，特别是其与底层硬件内存模型（如TSO）的交互，对于编写正确的并发代码至关重要。JavaScript的SharedArrayBuffer结合Atomics API提供了一个强大而灵活的工具集，但它要求开发者放弃对“顺序一致性”的直觉假设，转而依赖Atomics提供的明确同步保证。

关键差异与建议：

• 顺序一致性 (SC) 是一个理想化的模型，它提供最强的直观一致性，但性能开销巨大，现代硬件通常不直接实现。
• Total Store Order (TSO) 是一个更现实的硬件内存模型，它允许写-读重排序（通过写缓冲旁路），从而提高了处理器性能。这意味着在TSO下，一个线程的写入可能不会立即对其他线程可见。
• JavaScript的内存模型 (通过SharedArrayBuffer和Atomics) 是基于C++11内存模型，通过提供原子操作和内存屏障来解决多线程数据一致性问题。
  • 核心原则是数据竞争自由 (DRF): 如果所有共享内存访问都通过Atomics操作进行，则程序行为是顺序一致的。
  • Atomics.load 提供获取（Acquire）语义，Atomics.store 提供释放（Release）语义，它们协同工作以建立必要的内存同步。
  • 常规的arr[idx]读写操作是非原子且非同步的，如果它们与并发访问的SharedArrayBuffer内存位置发生冲突，会导致未定义行为。

最佳实践：

1. 始终使用 Atomics 访问共享内存： 这是黄金法则。任何对 SharedArrayBuffer 中共享数据的读写，都应该通过 Atomics 方法进行，以避免数据竞争和未定义行为。
2. 理解获取/释放语义： 掌握 Atomics.load 的获取语义和 Atomics.store 的释放语义如何协同工作，建立起“先行发生”关系，确保数据在线程间的正确可见性。
3. 警惕非原子操作： 如果你混合使用常规的 arr[idx] 访问和 Atomics 操作，必须非常小心，确保常规访问不会与并发的 SharedArrayBuffer 内存区域发生竞争。在大多数实际场景中，这很难保证，因此建议完全避免混合使用。
4. 按需使用 Atomics.fence()： 在需要显式内存屏障而不涉及原子读写操作时，Atomics.fence() 是一个强大的工具。

JavaScript的并发编程不再是简单的单线程模型，而是步入了多线程共享内存的复杂世界。掌握内存模型是编写高性能、高可靠性Web应用程序的必备技能。愿各位开发者们能驾驭这些强大的工具，创造出更加精彩的未来。

---

驾驭JavaScript的并发力量，需要深入理解其内存模型，特别是Atomics API如何将宽松的硬件内存模型提升至可预测的顺序一致性行为。告别直觉，拥抱精确的同步语义，是编写健壮多线程代码的关键。