多线程环境下的 JavaScript 内存一致性模型（JMM）：顺序一致性（SC）与松散模型（Relaxed）的权衡

各位同仁，各位对JavaScript并发编程抱有热情的开发者们，大家好。

今天，我们将深入探讨一个在多线程JavaScript环境中至关重要的议题：内存一致性模型（Memory Consistency Model），特别是它如何在JavaScript中，在顺序一致性（Sequential Consistency, SC）与松散模型（Relaxed Model）之间进行权衡。这不仅仅是一个理论概念，更是决定我们并发代码能否正确运行、能否高效执行的基石。

多年来，JavaScript一直以其单线程、事件循环的特性而闻名，这使得开发者无需过多关注复杂的内存一致性问题。然而，随着Web Workers和SharedArrayBuffer的引入，JavaScript正式迈入了多线程共享内存的时代。这带来了巨大的性能潜力，但同时也引入了传统并发编程中固有的挑战，其中最核心的挑战之一就是——内存一致性。

一、 内存一致性模型：并发编程的隐形契约

在探讨细节之前，我们首先需要理解什么是内存一致性模型。

想象一下，你和你的同事（线程）正在共享一个白板（内存）。你们可以读写白板上的信息。当一个同事写下一些信息后，另一个同事何时能看到这些信息？如果多个同事同时写不同的信息，它们最终在白板上呈现的顺序是怎样的？这就是内存一致性模型要回答的问题。

内存一致性模型定义了多处理器或多线程系统中，内存操作（读和写）的顺序在不同线程之间如何被观察到。它本质上是硬件、编译器和运行时环境对程序员做出的一个契约，承诺了内存操作的可见性和顺序性。

为什么这会成为一个问题？

在理想世界中，我们希望所有的内存操作都像在一个单一、全局、有序的序列中执行一样。然而，现代计算机系统为了追求极致性能，会大量采用各种优化手段：

1. CPU缓存（CPU Caches）：每个CPU核心都有自己的私有缓存，数据在写入主内存之前可能只存在于某个核心的缓存中。
2. 写缓冲器（Write Buffers）：CPU将写操作放入写缓冲器，然后继续执行后续指令，而写操作稍后才提交到缓存或主内存。
3. 指令重排序（Instruction Reordering）：编译器和处理器为了提高效率（例如，隐藏内存访问延迟，优化流水线），可能会在不改变单线程内部逻辑结果的前提下，重新安排指令的执行顺序。

这些优化虽然显著提升了单线程程序的性能，但在多线程共享内存的环境下，它们会导致一个线程对内存的写入，可能不会立即对另一个线程可见，或者写入操作的顺序在不同线程看来是不同的。这就是内存一致性模型的复杂性所在。

核心概念速览：

• 程序顺序（Program Order）：单个线程中指令的编写顺序。
• 执行顺序（Execution Order）：指令实际在处理器上执行的顺序，可能因重排序而与程序顺序不同。
• 可见性（Visibility）：一个线程的写入何时能被另一个线程观察到。
• 顺序性（Ordering）：多个线程的内存操作在全局上被观察到的相对顺序。

二、 顺序一致性（Sequential Consistency, SC）：直觉的理想

我们首先来了解最直观、最容易理解的内存模型：顺序一致性。

定义：

顺序一致性模型由Leslie Lamport在1979年提出。它要求：

1. 所有处理器对内存的操作，都好像是按照某个单一的、全局的顺序执行的。
2. 这个全局顺序中，每个处理器（或线程）的内存操作，都与其自身的程序顺序一致。

简单来说，顺序一致性就像所有线程都在一个房间里，轮流向一个共享的黑板上写字。每个人写下的内容，对房间里的所有人都是立即可见的，并且每个人写字的顺序都严格按照他们心中的计划。

优点：

• 易于理解和推理：程序员可以像编写单线程程序一样思考，无需担心内存重排序或可见性问题。这使得并发程序的正确性验证变得相对简单。
• 极少出现意外行为：由于严格的顺序保证，数据竞态（Data Race）导致的不可预测行为大大减少，甚至在某些定义下可以完全避免。

缺点：

• 性能开销：为了实现顺序一致性，处理器和编译器需要放弃大量的优化机会。例如，处理器可能需要频繁地刷新缓存、等待写缓冲器清空，并在每次内存访问时插入内存屏障（Memory Barrier）来强制排序。这会显著降低系统的并发性能。

概念示例：

考虑两个线程，共享一个数据data和一个标志flag。

线程A (Writer):

// 假设这是在SharedArrayBuffer上操作
data[0] = 123; // (1) 写入数据
flag[0] = 1;   // (2) 设置标志

线程B (Reader):

// 假设这是在SharedArrayBuffer上操作
while (Atomics.load(flag, 0) === 0) {
    // 等待标志被设置
}
console.log(data[0]); // (3) 读取数据

如果采用顺序一致性模型，我们可以确信：

1. 操作(1)一定在操作(2)之前发生（程序顺序）。
2. 当线程B观察到flag[0]变为1时，它也一定能观察到data[0]已经被设置为123。
3. console.log(data[0])一定会打印出123。

这是因为顺序一致性保证了所有线程看到的内存操作顺序都是一样的，并且与每个线程自身的程序顺序一致。

三、 松散内存模型（Relaxed Memory Models）：性能的妥协

为了克服顺序一致性带来的性能瓶颈，现代计算机系统和编程语言普遍采用了更加松散的内存模型。

定义：

松散内存模型允许在某些条件下，内存操作的执行顺序与程序顺序不一致，或者一个线程的写入不会立即对其他线程可见。这种“松散”是为了给编译器和处理器提供更大的优化空间。

松散模型的核心思想是：除非程序员明确要求，否则系统不会强制所有内存操作都严格排序。只有在需要建立特定同步点时，才使用特定的原子操作（Atomic Operations）或内存屏障来恢复必要的顺序保证。

优点：

• 卓越的性能：通过允许重排序、延迟写入等优化，松散模型能够充分利用现代硬件的并发能力，显著提高程序的执行效率。

缺点：

• 极难理解和推理：程序员需要深入理解内存模型的细节，精确地识别何时需要同步、何时可以放松。这使得并发程序的调试变得异常困难，因为问题可能只在特定硬件、特定负载或特定时间窗口下偶发。
• 容易引入数据竞态和逻辑错误：如果未正确使用同步原语，程序可能会读取到过时的数据，或者观察到意料之外的执行顺序，导致程序行为不正确。

松散模型的典型分类（非JS特有，但概念通用）：

• Relaxed (无序)：最弱的保证，操作之间没有顺序关系，除非被其他操作显式排序。
• Acquire/Release (获取/释放)：提供了一种“happens-before”关系。
  • Acquire Load (获取加载)：保证所有后续的内存操作不会被重排到此加载操作之前。
  • Release Store (释放存储)：保证所有先前的内存操作不会被重排到此存储操作之后。
  • 当一个线程执行一个释放存储，另一个线程执行一个获取加载时，如果获取加载读取到了释放存储写入的值，那么释放存储之前的所有操作都会在获取加载之后变得可见。
• Sequentially Consistent (顺序一致)：最强的保证，通常由特定的原子操作提供，能够强制所有内存操作都遵循一个全局的顺序。

概念示例：

我们再次审视线程A和线程B的例子，但在一个松散模型下。

线程A (Writer):

data[0] = 123; // (1) 写入数据
flag[0] = 1;   // (2) 设置标志

线程B (Reader):

while (flag[0] === 0) {
    // 等待标志被设置
}
console.log(data[0]); // (3) 读取数据

在松散模型下，编译器或处理器可能会进行重排序：

• 处理器重排序：线程A的flag[0] = 1可能会先于data[0] = 123被写入到主内存或对其他核心可见。
• 编译器重排序：编译器可能会改变指令的生成顺序。

如果发生这种情况：

1. 线程A将flag[0]设置为1。
2. 线程B观察到flag[0]变为1，跳出循环。
3. 线程B立即读取data[0]。
4. 此时，data[0]的写入可能尚未完成或对线程B不可见。线程B读取到的可能是旧的、未初始化的，甚至是垃圾值（在C/C++中是未定义行为）。

这清楚地展示了松散模型下的挑战：如果没有明确的同步机制，程序的行为将是不可预测的。

四、 JavaScript的内存模型：SharedArrayBuffer与Atomics

在SharedArrayBuffer出现之前，JavaScript的内存模型相对简单。由于其单线程事件循环的特性，所有的内存访问都发生在同一个线程内，因此自然地具备了顺序一致性（即一个操作完成，下一个操作才能开始）。

然而，随着Web Workers能够通过SharedArrayBuffer共享内存，JavaScript环境下的多线程并发成为了现实，一个正式的内存一致性模型变得不可或缺。ECMA-262标准为SharedArrayBuffer定义了一个内存模型，它借鉴了C++11/C++14的内存模型，但有所简化和调整，旨在提供内存安全的同时，也允许必要的性能优化。

JavaScript的内存模型是混合的、弱序的：

1. 非原子访问 (SharedArrayBuffer的直接读写)：

   • 对于通过TypedArray直接访问SharedArrayBuffer（例如 int32Array[0] = 10; 或 let x = int32Array[0];）的非原子操作，ECMA-262标准明确指出这些操作是memory_order_relaxed。
   • 这意味着这些操作没有强制的顺序保证。它们可以被编译器和处理器重排序，对其他线程的可见性也没有立即保证。
   • 关键点：与C++不同，JavaScript的这种“relaxed”访问是数据竞态安全的（data-race-free）。这意味着即使多个线程同时对同一个内存位置进行非原子读写，也不会导致程序崩溃、内存损坏或未定义行为。JavaScript运行时会确保内存安全。但是，这并不意味着逻辑上的正确性！你可能读到过时或意料之外的值，导致程序逻辑错误。

2. 原子操作 (Atomics对象)：

   • 为了在需要时提供强内存顺序保证，JavaScript引入了Atomics对象。Atomics对象提供了各种原子操作，如load、store、add、sub、compareExchange等，以及等待/通知机制（wait/notify）。
   • ECMA-262标准规定，所有Atomics方法对SharedArrayBuffer执行的读写操作都使用memory_order_seq_cst（顺序一致性）语义。
   • 这意味着，所有的原子操作在整个系统中都遵循一个单一的、全局的顺序。一个线程执行的原子操作，对其他线程来说，其可见性和顺序性是严格保证的。这使得Atomics操作可以作为全内存屏障（Full Memory Barrier），阻止其前后指令的重排序，并确保内存的可见性。

总结JS内存模型特性：

特性	非原子访问 (e.g., arr[0] = 10;)	原子访问 (e.g., Atomics.store(arr, 0, 10);)
可见性	不保证立即对其他线程可见	立即对其他线程可见，并遵循全局顺序
顺序性	memory_order_relaxed，可能发生重排序	memory_order_seq_cst，强制顺序，充当内存屏障
数据竞态安全	是（不会导致崩溃或未定义行为，但可能逻辑错误）	是（天然安全）
性能	通常更快，因为允许更多优化	通常较慢，因为需要强制同步和排序
用途	读写不涉及跨线程同步的数据	跨线程同步、计数器、锁等需要严格顺序和可见性的场景

这意味着什么？

JavaScript的内存模型是性能和正确性之间的一种实用权衡。它默认采用性能更优的松散模型（针对非原子访问），但提供了强大的Atomics原语，允许开发者在需要时显式地强制顺序一致性，以确保并发程序的正确性。

因此，在JavaScript多线程编程中，我们的基本原则是：
除非你明确使用Atomics操作，否则不要对SharedArrayBuffer上的数据访问做出任何跨线程的可见性或顺序性假设。

五、 实践中的权衡与Atomics的应用

现在，我们通过具体的代码示例来深入理解这种权衡，以及如何正确使用Atomics来构建健壮的并发程序。

示例 1：非原子访问的陷阱（松散模型的挑战）

让我们回到之前生产者-消费者模式的简化版。

main.js (主线程)

// main.js
const worker = new Worker('worker.js');

const sab = new SharedArrayBuffer(2 * Int32Array.BYTES_PER_ELEMENT);
const data = new Int32Array(sab, 0, 1); // 存储数据
const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1); // 存储标志

worker.postMessage({ sab });

// 模拟主线程作为生产者
setTimeout(() => {
    console.log('主线程：开始写入数据和标志...');
    data[0] = 42; // (1) 写入数据
    flag[0] = 1;  // (2) 设置标志
    console.log(`主线程：data[0] = ${data[0]}, flag[0] = ${flag[0]} 已写入。`);
}, 100);

// 在实际应用中，你可能需要一个更复杂的机制来等待worker完成，这里简化
setTimeout(() => {
    console.log('主线程：程序结束。');
    worker.terminate();
}, 500);

worker.js (工作线程)

// worker.js
onmessage = function(e) {
    const { sab } = e.data;
    const data = new Int32Array(sab, 0, 1);
    const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1);

    console.log('工作线程：等待标志...');
    let value = 0;
    while (flag[0] === 0) { // (3) 读取标志
        // 忙等待，实际应用中应使用Atomics.wait
    }
    value = data[0]; // (4) 读取数据
    console.log(`工作线程：标志已设置，读取到数据: ${value}`);

    if (value === 42) {
        console.log('工作线程：数据正确。');
    } else {
        console.error(`工作线程：数据错误！期望 42, 实际 ${value}`);
    }
};

分析：

在这个例子中，主线程先写入data[0]，然后设置flag[0]。工作线程则循环等待flag[0]变为1，一旦检测到，就读取data[0]。

由于data[0] = 42;和flag[0] = 1;是非原子操作，它们在JavaScript的内存模型中是memory_order_relaxed的。这意味着：

• 重排序：主线程写入data[0]和flag[0]的顺序可能会被编译器或处理器重排序。例如，flag[0] = 1的操作可能会在data[0] = 42完成之前，或者在data[0] = 42对工作线程可见之前，就对工作线程可见。
• 可见性延迟：即使没有重排序，data[0] = 42的写入也可能不会立即对工作线程可见，而flag[0] = 1的写入却可能先一步可见。

结果：

在某些情况下，工作线程可能会在flag[0]变为1之后，读取到data[0]的旧值（例如0），而不是期望的42。这种错误很难重现，因为它依赖于特定的运行时环境、CPU架构、编译器优化以及时间竞争。这就是松散模型下数据竞态的典型表现：程序行为不确定。

示例 2：使用Atomics.store和Atomics.load修复

为了保证data的写入在flag的写入之前对所有线程可见，我们需要使用Atomics来强制顺序。Atomics.store和Atomics.load都提供memory_order_seq_cst语义，它们自身会强制排序，并确保对该位置的写入对所有后续读取者可见。

main_atomic.js (主线程)

// main_atomic.js
const worker = new Worker('worker_atomic.js');

const sab = new SharedArrayBuffer(2 * Int32Array.BYTES_PER_ELEMENT);
const data = new Int32Array(sab, 0, 1);
const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1);

worker.postMessage({ sab });

setTimeout(() => {
    console.log('主线程：开始写入数据和标志 (使用 Atomics)...');
    data[0] = 42; // (1) 写入数据 (非原子，但此处的重点是Atomics.store(flag))
    Atomics.store(flag, 0, 1); // (2) 原子设置标志
    console.log(`主线程：data[0] = ${data[0]}, flag[0] = ${Atomics.load(flag, 0)} 已写入。`);
}, 100);

setTimeout(() => {
    console.log('主线程：程序结束。');
    worker.terminate();
}, 500);

worker_atomic.js (工作线程)

// worker_atomic.js
onmessage = function(e) {
    const { sab } = e.data;
    const data = new Int32Array(sab, 0, 1);
    const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1);

    console.log('工作线程：等待标志 (使用 Atomics)...');
    let value = 0;
    while (Atomics.load(flag, 0) === 0) { // (3) 原子读取标志
        // 忙等待，实际应用中应使用Atomics.wait
    }
    value = data[0]; // (4) 读取数据 (非原子)
    console.log(`工作线程：标志已设置，读取到数据: ${value}`);

    if (value === 42) {
        console.log('工作线程：数据正确。');
    } else {
        console.error(`工作线程：数据错误！期望 42, 实际 ${value}`);
    }
};

分析与结果：

这里，我们用Atomics.store(flag, 0, 1)来设置标志，用Atomics.load(flag, 0)来读取标志。
由于Atomics.store和Atomics.load都具有memory_order_seq_cst语义，它们会强制执行顺序和可见性。

1. 当主线程执行Atomics.store(flag, 0, 1)时，这个操作不仅会原子性地将1写入flag[0]，还会确保所有在Atomics.store之前发生的内存写入（包括data[0] = 42）都已完成并对所有线程可见，并且不会被重排序到Atomics.store之后。
2. 当工作线程执行Atomics.load(flag, 0)并读取到1时，这个操作会确保所有在Atomics.load之后发生的内存读取（包括value = data[0]）不会被重排序到Atomics.load之前。

因此，Atomics.store(flag, 0, 1)在这里充当了一个“释放存储”（Release Store），而Atomics.load(flag, 0)充当了一个“获取加载”（Acquire Load）。它们共同建立了一个happens-before关系：主线程中data[0] = 42的操作，happens-before工作线程中value = data[0]的操作。

结果： 工作线程将始终读取到正确的42。这种方式解决了数据竞态问题，但引入了原子操作的性能开销。

示例 3：使用Atomics.wait和Atomics.notify实现高效等待

上述的while (Atomics.load(flag, 0) === 0)是忙等待（busy-waiting），会消耗大量的CPU资源。Atomics对象还提供了更高效的等待/通知机制。

main_wait_notify.js (主线程)

// main_wait_notify.js
const worker = new Worker('worker_wait_notify.js');

const sab = new SharedArrayBuffer(2 * Int32Array.BYTES_PER_ELEMENT);
const data = new Int32Array(sab, 0, 1);
const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1); // 标志位用于Atomics.wait/notify

worker.postMessage({ sab });

setTimeout(() => {
    console.log('主线程：开始写入数据和通知 (使用 Atomics.notify)...');
    data[0] = 42; // (1) 写入数据
    // (2) 写入标志并通知。Atomics.store在此处也是必要的，因为它在Atomics.notify之前，确保数据可见性
    Atomics.store(flag, 0, 1);
    Atomics.notify(flag, 0, 1); // (3) 通知一个等待的线程
    console.log(`主线程：data[0] = ${data[0]}, flag[0] = ${Atomics.load(flag, 0)} 已写入并通知。`);
}, 100);

setTimeout(() => {
    console.log('主线程：程序结束。');
    worker.terminate();
}, 500);

worker_wait_notify.js (工作线程)

// worker_wait_notify.js
onmessage = function(e) {
    const { sab } = e.data;
    const data = new Int32Array(sab, 0, 1);
    const flag = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1);

    console.log('工作线程：等待通知 (使用 Atomics.wait)...');
    // (4) 等待，如果flag[0]不是0，则立即返回；否则阻塞直到被通知
    const status = Atomics.wait(flag, 0, 0); // 等待flag[0]的值为0
    console.log(`工作线程：Atomics.wait 返回状态: ${status}`);

    // (5) 读取数据
    const value = data[0];
    console.log(`工作线程：标志已设置，读取到数据: ${value}`);

    if (value === 42) {
        console.log('工作线程：数据正确。');
    } else {
        console.error(`工作线程：数据错误！期望 42, 实际 ${value}`);
    }
};

分析与结果：

Atomics.wait(typedArray, index, value)：

• 原子性地检查typedArray[index]是否等于value。
• 如果相等，线程将阻塞并进入休眠状态，直到被Atomics.notify唤醒，或者超时。
• 如果不相等，它会立即返回'not-equal'，表示条件不满足。

Atomics.notify(typedArray, index, count)：

• 唤醒在typedArray[index]上等待的count个线程。

关键的内存一致性保证：

Atomics.wait和Atomics.notify在内部包含了必要的内存屏障，以确保它们的正确同步。

• Atomics.store(flag, 0, 1)（释放语义）：确保它之前的写入（data[0] = 42）对其他线程可见。
• Atomics.notify：在唤醒等待线程时，也起到了内存屏障的作用，确保了发生在通知之前的内存写入对被唤醒线程是可见的。
• Atomics.wait（获取语义）：当它返回时，确保了在此之后发生的内存读取（const value = data[0]）会看到所有发生在唤醒之前的写入。

因此，这个版本也能保证data的正确性，并且消除了忙等待，提高了效率。

示例 4：使用Atomics.compareExchange实现自旋锁

Atomics.compareExchange是一个非常强大的原子读-改-写（RMW）操作，它是实现无锁数据结构和各种同步原语（如互斥锁）的基础。它同样具有memory_order_seq_cst语义。

main_lock.js (主线程)

// main_lock.js
const worker1 = new Worker('worker_lock.js');
const worker2 = new Worker('worker_lock.js');

const sab = new SharedArrayBuffer(2 * Int32Array.BYTES_PER_ELEMENT);
const lock = new Int32Array(sab, 0, 1); // 锁的状态：0=解锁，1=锁定
const counter = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1); // 共享计数器

// 初始化锁为解锁状态
Atomics.store(lock, 0, 0);
Atomics.store(counter, 0, 0);

worker1.postMessage({ sab, id: 1 });
worker2.postMessage({ sab, id: 2 });

setTimeout(() => {
    console.log('主线程：所有工作线程已启动。');
    // 让工作线程运行一段时间
}, 100);

setTimeout(() => {
    console.log(`主线程：最终计数器值: ${Atomics.load(counter, 0)}`);
    worker1.terminate();
    worker2.terminate();
    console.log('主线程：程序结束。');
}, 1000);

worker_lock.js (工作线程)

// worker_lock.js
const LOCK_UNLOCKED = 0;
const LOCK_LOCKED = 1;

/**
 * 尝试获取锁
 * @param {Int32Array} lockArray
 * @param {number} index
 */
function acquireLock(lockArray, index) {
    while (true) {
        // 尝试将锁从UNLOCKED状态变为LOCKED状态
        // 如果当前值是UNLOCKED，就CAS成功，返回UNLOCKED
        // 如果当前值不是UNLOCKED，就CAS失败，返回当前值
        const oldValue = Atomics.compareExchange(lockArray, index, LOCK_UNLOCKED, LOCK_LOCKED);
        if (oldValue === LOCK_UNLOCKED) {
            // 成功获取锁
            return;
        }
        // 否则，锁已被其他线程持有，继续尝试
        // 实际应用中可以短暂休眠或使用Atomics.wait
        // console.log(`Worker ${self.id}: 锁被占用，等待...`);
        // Atomics.wait(lockArray, index, LOCK_LOCKED, 10); // 等待10ms再重试
    }
}

/**
 * 释放锁
 * @param {Int32Array} lockArray
 * @param {number} index
 */
function releaseLock(lockArray, index) {
    // 将锁设置为解锁状态
    Atomics.store(lockArray, index, LOCK_UNLOCKED);
    // 理论上，如果其他线程在等待，可以Atomics.notify唤醒
    // Atomics.notify(lockArray, index, 1);
}

onmessage = function(e) {
    const { sab, id } = e.data;
    self.id = id; // 为worker实例设置一个ID
    const lock = new Int32Array(sab, 0, 1);
    const counter = new Int32Array(sab, Int32Array.BYTES_PER_ELEMENT, 1);

    const iterations = 100000;
    console.log(`Worker ${id}: 开始递增计数器 ${iterations} 次`);

    for (let i = 0; i < iterations; i++) {
        acquireLock(lock, 0); // 获取锁
        try {
            // 临界区：只有持有锁的线程才能访问
            const currentValue = Atomics.load(counter, 0);
            Atomics.store(counter, 0, currentValue + 1);
        } finally {
            releaseLock(lock, 0); // 释放锁
        }
    }
    console.log(`Worker ${id}: 完成递增，最终计数器值 (局部): ${Atomics.load(counter, 0)}`);
};

分析与结果：

这个例子展示了如何使用Atomics.compareExchange来实现一个简单的自旋锁。

• acquireLock函数通过不断调用Atomics.compareExchange来尝试将锁的状态从LOCK_UNLOCKED（0）原子性地切换到LOCK_LOCKED（1）。只有当锁当前确实是LOCK_UNLOCKED时，compareExchange才会成功并返回旧值0，表示当前线程成功获取了锁。
• releaseLock函数则简单地将锁状态设置为LOCK_UNLOCKED。

由于Atomics.compareExchange是一个原子读-改-写操作，它能够确保在多线程环境下，只有一个线程能够成功地将锁从解锁状态变为锁定状态。它以及Atomics.load和Atomics.store（在临界区内）都提供了memory_order_seq_cst的内存语义。这意味着：

• 互斥：任何时候只有一个线程能进入临界区。
• 可见性：当一个线程释放锁时，它在临界区内对共享变量（如counter）的所有修改都会对其他线程可见。当另一个线程获取锁时，它会看到最新的共享变量值。

结果： 最终的counter值将是两个工作线程迭代次数的总和（2 * 100000 = 200000）。如果没有锁，由于数据竞态，计数器值将远小于此。

六、 总结与展望

通过今天的探讨，我们深入理解了JavaScript多线程环境下的内存一致性模型。我们看到了顺序一致性（SC）的直观性和高成本，以及松散模型（Relaxed）在性能上的优势和对程序员提出的更高要求。

JavaScript通过SharedArrayBuffer和Atomics对象，巧妙地在两者之间取得了平衡：默认的非原子访问是memory_order_relaxed且数据竞态安全的，为性能优化留下了空间；而Atomics操作则提供了memory_order_seq_cst的强一致性保证，使开发者能够在需要时精确地控制内存可见性和操作顺序，从而构建出正确且高效的并发程序。

理解并正确运用Atomics是现代JavaScript多线程编程的关键。它要求我们改变过去单线程的思维模式，转而拥抱并发编程的复杂性，但同时也解锁了JavaScript在高性能计算领域的巨大潜力。随着WebAssembly线程等技术的进一步发展，对内存模型的深入理解将变得愈发重要。