JavaScript Agent Clusters：ES 规范下跨 Worker 共享内存的数据竞争与一致性保证

各位技术同仁，大家好！

欢迎来到今天的技术讲座。今天我们将深入探讨 JavaScript 领域一个激动人心且充满挑战的话题——Agent Clusters。随着 Web 应用的复杂性日益提升，单线程模型在性能上的瓶颈逐渐显现。Web Workers 的出现打破了这一限制，但其基于消息传递的通信机制，在需要高频、大量数据共享的场景下，仍显得力不从心。

为了解决这一痛点，ECMAScript 引入了 SharedArrayBuffer 和 Atomics API，为 JavaScript 带来了真正的共享内存多线程能力。然而，力量越大，责任越大。共享内存编程必然会引入数据竞争（Data Races）和一致性（Consistency）问题。今天的讲座，我将带领大家从 ECMAScript 规范的视角，系统地理解 Agent Clusters 的概念，SharedArrayBuffer 如何作为共享内存的基石，数据竞争的本质与危害，以及 Atomics API 如何提供严谨的一致性保证，帮助我们构建健壮的并发应用。

---

第一讲：JavaScript 运行环境的演进与 Agent 概念

在深入共享内存之前，我们首先需要回顾 JavaScript 运行环境的演进，并理解 ECMAScript 规范中对“Agent”这一核心概念的定义。

1.1 单线程模型回顾

我们都知道，JavaScript 最初被设计为一门单线程语言。这意味着在任何给定时间点，JavaScript 引擎只能执行一段代码。这种设计简化了编程模型，避免了许多复杂的并发问题，如死锁和竞态条件。浏览器环境中的事件循环（Event Loop）、任务队列（Task Queue）等机制，使得 JavaScript 能够以非阻塞的方式处理异步操作，例如网络请求、定时器和用户交互。

然而，随着 Web 应用功能日益丰富，图形处理、大数据计算、复杂算法等密集型任务对性能提出了更高要求。单线程模型在这种情况下暴露出其局限性：长时间运行的脚本会阻塞主线程，导致页面卡顿，用户体验下降。

1.2 Web Workers 的引入

为了解决主线程阻塞问题，W3C 推出了 Web Workers 标准。Web Workers 允许开发者在后台线程中运行脚本，从而避免阻塞主线程。每个 Worker 都有自己独立的全局作用域、事件循环和执行栈。Worker 与主线程之间，以及 Worker 之间，通过 postMessage 和 onmessage 机制进行通信。

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

worker.postMessage({ type: 'startCalculation', data: [1, 2, 3] });

worker.onmessage = (event) => {
    console.log('主线程收到消息:', event.data);
};

// worker.js (Worker 线程)
onmessage = (event) => {
    if (event.data.type === 'startCalculation') {
        const result = event.data.data.reduce((sum, num) => sum + num, 0);
        postMessage({ type: 'calculationComplete', result: result });
    }
};

虽然 Web Workers 解决了主线程阻塞的问题，但其通信方式是基于消息传递的，这意味着数据在线程间传递时会被序列化（structured clone algorithm）并复制。对于大型数据结构或需要频繁更新的数据，这种复制开销可能非常大，效率低下。这就引出了对真正共享内存的需求。

1.3 Agent 的定义与 Agent Cluster

ECMAScript 规范为了形式化地描述并发执行环境，引入了 Agent 的概念。

Agent (代理):
在 ECMAScript 规范中，一个 Agent 是一个独立的执行实体，它拥有自己的执行栈、全局环境、事件循环以及一套私有状态。在浏览器环境中，主线程是一个 Agent，每一个 Web Worker 也是一个 Agent。每个 Agent 都是独立的，它们有自己的内存空间，通常无法直接访问其他 Agent 的内存。

Agent Cluster (代理集群):
Agent Cluster 是 ECMAScript 规范中为了描述共享内存而引入的关键概念。一个 Agent Cluster 是一组 Agent 的集合，这些 Agent 能够安全地共享同一个 Shared Data Block (共享数据块)。

• 共享数据块 (Shared Data Block): 这是 SharedArrayBuffer 实例底层实际的内存区域。
• 特性: 同一个 Agent Cluster 中的所有 Agent 都可以访问并修改这些共享数据块。
• 形成条件: 通常情况下，所有从同一个顶级浏览上下文（或 Worker）创建的 Workers，以及它们共享的 SharedArrayBuffer 实例，都属于同一个 Agent Cluster。跨域或不同顶级上下文的 Agent 通常不属于同一个 Agent Cluster。

为什么需要 Agent Cluster 概念？
Agent Cluster 概念的存在，是 ECMAScript 规范层面管理共享内存访问权限和行为的基础。它明确了哪些 Agent 可以看到和操作同一块共享内存，并为后续讨论的内存模型和一致性保证提供了上下文。

特性	Agent (独立执行实体)	Agent Cluster (代理集群)
构成	主线程、Web Worker	一组 Agents
内存	独立私有内存空间	共享一个或多个 Shared Data Block
通信方式	消息传递 (postMessage)	消息传递 + 共享内存 (SharedArrayBuffer, Atomics)
主要目的	隔离执行，避免阻塞主线程	实现高效的共享内存并发，解决数据复制开销
规范意义	定义基本执行单元	定义共享内存的边界和可见性范围

理解 Agent 和 Agent Cluster 是我们后续讨论 SharedArrayBuffer 和 Atomics 的前提。它们为我们描绘了 JavaScript 并发执行的宏观图景。

---

第二讲：SharedArrayBuffer – 共享内存的基石

有了 Agent Cluster 的概念，我们现在可以深入到实现共享内存的核心技术——SharedArrayBuffer。

2.1 ArrayBuffer 的局限性

在 SharedArrayBuffer 出现之前，JavaScript 提供了 ArrayBuffer，它代表了一段固定长度的二进制数据缓冲区。我们可以通过 TypedArray 视图（如 Int32Array, Uint8Array）来读取和写入 ArrayBuffer 中的数据。

const buffer = new ArrayBuffer(16); // 16字节的缓冲区
const view = new Int32Array(buffer); // 4个32位整数的视图

view[0] = 123;
console.log(view[0]); // 123

然而，ArrayBuffer 的关键局限在于它的“不可共享性”。当你通过 postMessage 将一个 ArrayBuffer 从一个 Agent 发送到另一个 Agent 时，实际上是创建了一个副本。原始 ArrayBuffer 在发送 Agent 中变得不可用，而接收 Agent 获得了一个完全独立的副本。这种“所有权转移”机制避免了数据竞争，但也意味着每次传输都需要付出复制的代价。

2.2 SharedArrayBuffer 的诞生

SharedArrayBuffer 的设计目的正是为了克服 ArrayBuffer 的这一局限。它允许在同一个 Agent Cluster 内的 Agents 之间共享同一段内存。这意味着，当一个 Agent 修改了 SharedArrayBuffer 中的数据时，其他 Agents 能够立即看到这些修改，而无需进行数据复制。

核心特性:

• 共享性: SharedArrayBuffer 实例代表的内存块可以被其 Agent Cluster 内的所有 Agents 同时访问和修改。
• 构造函数: new SharedArrayBuffer(byteLength)，参数 byteLength 指定了缓冲区的大小（字节）。
• 视图: 与 ArrayBuffer 类似，SharedArrayBuffer 本身不能直接操作，需要通过 TypedArray 视图（如 Int32Array, Uint8Array, Float64Array 等）来读写其底层数据。
• 不可转移性: SharedArrayBuffer 实例不能像 ArrayBuffer 那样被转移所有权。它被传递到 Worker 时，传递的是引用，而不是副本。

代码示例: 创建 SharedArrayBuffer 并在 Worker 之间共享

首先，我们需要一个主线程脚本 main.js 和一个 Worker 脚本 worker.js。

main.js:

// 确保页面处于跨域隔离环境，这是SharedArrayBuffer使用的前提
// 通常通过设置HTTP响应头 Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp 来实现
if (self.crossOriginIsolated) {
    console.log("环境已跨域隔离，可以安全使用 SharedArrayBuffer.");

    const sharedBuffer = new SharedArrayBuffer(1024); // 创建一个1KB的共享缓冲区
    const sharedArray = new Int32Array(sharedBuffer); // 创建一个Int32Array视图

    // 初始化共享数组
    for (let i = 0; i < sharedArray.length; i++) {
        sharedArray[i] = i;
    }

    console.log("主线程：初始共享数组值:", sharedArray[0], sharedArray[1]);

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

    // 将 SharedArrayBuffer 传递给 Worker
    // 注意：这里传递的是引用，不是副本
    worker.postMessage({ buffer: sharedBuffer });

    worker.onmessage = (event) => {
        console.log("主线程收到 Worker 消息:", event.data.message);
        console.log("主线程：Worker 修改后的共享数组值:", sharedArray[0], sharedArray[1]);
        // 观察 Worker 修改后的值
        console.log("主线程：检查共享数组内容:", Array.from(sharedArray.slice(0, 5)));
    };

    // 几秒后检查 Worker 是否修改了数据
    setTimeout(() => {
        console.log("主线程：延迟检查共享数组值:", sharedArray[0], sharedArray[1]);
        console.log("主线程：最终共享数组内容:", Array.from(sharedArray.slice(0, 5)));
    }, 2000);

} else {
    console.warn("当前环境未跨域隔离。SharedArrayBuffer 将不可用。请确保设置了 COOP/COEP HTTP 头。");
    // 提示用户设置COOP/COEP头
    document.body.innerHTML = `
        <p>当前页面未处于跨域隔离状态。</p>
        <p>请确保您的服务器响应头包含：</p>
        <ul>
            <li><code>Cross-Origin-Opener-Policy: same-origin</code></li>
            <li><code>Cross-Origin-Embedder-Policy: require-corp</code></li>
        </ul>
        <p>以便启用 SharedArrayBuffer。</p>
    `;
}

worker.js:

onmessage = (event) => {
    const sharedBuffer = event.data.buffer;
    const sharedArray = new Int32Array(sharedBuffer);

    console.log("Worker：收到共享缓冲区。初始值:", sharedArray[0], sharedArray[1]);

    // Worker 修改共享数组中的数据
    sharedArray[0] = 999;
    sharedArray[1] = 888;
    sharedArray[2] = 777; // 修改更多元素

    console.log("Worker：已修改共享数组值:", sharedArray[0], sharedArray[1]);

    postMessage({ message: "Worker 已修改共享数据" });
};

运行上述代码，你会看到主线程和 Worker 线程都能够访问并修改同一个 sharedBuffer。主线程在 Worker 修改后，无需任何额外操作，就能看到最新的值。

2.3 安全性考量：跨域隔离 (COOP/COEP)

SharedArrayBuffer 在 2017 年首次推出后，因为 Spectre 和 Meltdown 等侧信道攻击漏洞被临时禁用。这些攻击利用了 CPU 缓存行为的时序差异，而 SharedArrayBuffer 提供的纳秒级计时精度，可能有助于攻击者测量这些差异。

为了重新启用 SharedArrayBuffer，浏览器厂商与标准组织达成一致，要求使用 SharedArrayBuffer 的页面必须处于“跨域隔离”（Cross-Origin Isolation）状态。这意味着页面必须通过特定的 HTTP 响应头来声明其意图，以限制其与跨域资源的交互，从而缓解侧信道攻击的风险。

关键的 HTTP 响应头:

1. Cross-Origin-Opener-Policy (COOP): same-origin

   • 作用：将顶级文档与其打开的任何跨域窗口隔离开来。这意味着，如果你的页面设置了 COOP: same-origin，那么它打开的任何跨域弹出窗口都将不会与你的页面共享浏览上下文，从而无法直接访问你的 window 对象。反之亦然。

2. Cross-Origin-Embedder-Policy (COEP): require-corp (或 credentialless)

   • 作用：限制页面只能嵌入来自同源或其他明确声明为 Cross-Origin-Resource-Policy: cross-origin 的资源。这可以防止页面加载未经授权的跨域资源，从而减少攻击面。

当一个页面同时设置了 COOP: same-origin 和 COEP: require-corp 时，它就进入了“跨域隔离”状态。在 JavaScript 中，可以通过 self.crossOriginIsolated 属性来检测当前环境是否处于跨域隔离状态。只有当 self.crossOriginIsolated 为 true 时，SharedArrayBuffer 才能被创建和使用。

示例服务器配置 (Nginx):

server {
    listen 80;
    server_name yourdomain.com;

    add_header Cross-Origin-Opener-Policy "same-origin";
    add_header Cross-Origin-Embedder-Policy "require-corp";

    location / {
        root /path/to/your/web/root;
        index index.html;
    }
}

确保你的开发环境能够正确设置这些 HTTP 头，否则你将无法体验 SharedArrayBuffer 的强大功能。这是使用共享内存的先决条件，务必牢记。

---

第三讲：数据竞争 (Data Races) 的本质与危害

既然 SharedArrayBuffer 允许多个 Agents 共享同一块内存，那么数据竞争就成为了一个不可避免的问题。理解数据竞争的本质和危害，是编写正确并发程序的关键第一步。

3.1 并发编程的挑战：竞态条件

当多个线程（在 JavaScript 中是 Agents）并发访问和操作共享资源时，如果访问的顺序无法预测，导致程序行为依赖于这些不可预测的顺序，就可能发生竞态条件 (Race Condition)。数据竞争是竞态条件的一种特定形式。

3.2 数据竞争的严格定义 (ECMAScript 规范)

ECMAScript 规范对数据竞争有一个非常精确的定义：

当两个或多个 Agents 对同一个共享内存位置进行内存访问时，如果至少一个访问是写入，并且这些访问不是由 Atomics 操作同步的，那么就发生了数据竞争。

更具体地说，发生数据竞争的条件是：

1. 多个 Agents 访问同一内存位置： 至少有两个 Agents 试图读写 SharedArrayBuffer 中的同一个字节或字（取决于 TypedArray 的元素大小）。
2. 至少一个访问是写入： 如果所有访问都是读取操作，即使并发，也不会产生数据竞争（因为数据没有被修改）。
3. 访问不是由 Atomics 操作同步的： 这是最关键的一点。如果对共享内存的访问是通过 Atomics API 来完成的，那么这些访问被认为是原子性的和同步的，不会导致数据竞争。
4. 至少一个访问是非原子操作： 即直接通过 typedArray[index] = value 或 value = typedArray[index] 进行的读写。

3.3 数据竞争的危害

数据竞争会导致以下严重问题：

• 不可预测的结果 (Non-deterministic behavior): 程序的输出不再是确定的，每次运行的结果可能不同，这使得调试变得极其困难。
• 程序逻辑错误: 共享变量的值可能在不恰当的时机被修改，导致程序逻辑错误，例如计数器不准确、状态不一致等。
• 内存损坏 (Memory Corruption): 在低级语言如 C/C++ 中，数据竞争可能直接导致内存损坏。在 JavaScript 中，虽然 V8 引擎提供了内存安全保障，但数据竞争仍然会导致读取到不一致、过时或“半完成”的值，从而引发逻辑上的错误。

代码示例：演示数据竞争

我们将创建一个简单的计数器，在多个 Worker 中并发地增加它的值，但不使用任何同步机制。

main.js:

if (self.crossOriginIsolated) {
    const sharedBuffer = new SharedArrayBuffer(4); // 4字节，用于一个Int32计数器
    const counter = new Int32Array(sharedBuffer); // 计数器视图

    counter[0] = 0; // 初始化计数器为0

    const NUM_WORKERS = 5;
    const INCREMENTS_PER_WORKER = 100000;
    let completedWorkers = 0;

    console.log("主线程：计数器初始值:", counter[0]);

    for (let i = 0; i < NUM_WORKERS; i++) {
        const worker = new Worker('worker-race.js');
        worker.postMessage({ buffer: sharedBuffer, increments: INCREMENTS_PER_WORKER });

        worker.onmessage = () => {
            completedWorkers++;
            if (completedWorkers === NUM_WORKERS) {
                const expectedValue = NUM_WORKERS * INCREMENTS_PER_WORKER;
                console.log("------------------------------------------");
                console.log(`主线程：所有 Worker 完成。预期最终计数: ${expectedValue}`);
                console.log(`主线程：实际最终计数: ${counter[0]}`);
                if (counter[0] !== expectedValue) {
                    console.error("主线程：检测到数据竞争！实际值与预期值不符。");
                } else {
                    console.log("主线程：计数器结果正确 (这可能是偶然的，或在某些环境下不易复现)。");
                }
            }
        };
    }
} else {
    console.warn("环境未跨域隔离，SharedArrayBuffer 不可用。");
}

worker-race.js:

onmessage = (event) => {
    const sharedBuffer = event.data.buffer;
    const counter = new Int32Array(sharedBuffer);
    const increments = event.data.increments;

    for (let i = 0; i < increments; i++) {
        // 非原子操作：读取，增加，写入
        // 在这三步之间，其他 Worker 可能已经修改了 counter[0]
        let currentValue = counter[0];
        currentValue = currentValue + 1;
        counter[0] = currentValue;
    }

    postMessage('done');
};

运行结果分析:
当你运行上述代码时，你会发现 实际最终计数 几乎总是小于 预期最终计数（NUM_WORKERS * INCREMENTS_PER_WORKER）。

为什么会这样？
假设 counter[0] 当前是 50。

1. Worker A: 读取 counter[0] (得到 50)。
2. Worker B: 读取 counter[0] (得到 50)。
3. Worker A: 计算 50 + 1 = 51。
4. Worker B: 计算 50 + 1 = 51。
5. Worker A: 写入 counter[0] = 51。
6. Worker B: 写入 counter[0] = 51。

在这个场景中，两个 Worker 都尝试将计数器增加 1，但最终 counter[0] 的值只增加了 1，而不是预期的 2。这就是一个典型的数据竞争，两个写入操作互相覆盖，导致丢失更新。随着并发量的增加和循环次数的增多，这种错误会更加频繁地发生。

为了解决这种问题，我们需要引入原子操作，确保对共享内存的读-修改-写操作是不可中断的。

---

第四讲：Atomics API – 保证数据一致性与同步

为了解决 SharedArrayBuffer 带来的数据竞争问题，ECMAScript 规范引入了 Atomics 对象。Atomics 提供了一组静态方法，用于对 SharedArrayBuffer 上的 TypedArray 视图执行原子操作。这些操作是不可中断的，并且提供了内存顺序保证，从而解决了数据竞争和可见性问题。

4.1 为什么需要 Atomics

原子操作 (Atomic Operations) 具有以下关键特性：

• 不可中断性 (Indivisibility): 一个原子操作要么全部完成，要么全部不完成，在执行过程中不会被其他 Agent 的操作打断。这意味着它作为一个单一的、不可分割的步骤出现。
• 一致性保证: Atomics 操作不仅保证了操作本身的原子性，还通过特定的内存模型提供了可见性（Visibility）和顺序性（Ordering）保证，确保一个 Agent 的修改能被其他 Agents 及时且正确地看到。

4.2 ES 规范中的内存模型与顺序保证

ECMAScript 的共享内存模型是一种弱序内存模型 (Weakly Ordered Memory Model)，但 Atomics 操作提供了顺序一致性 (Sequentially Consistent, SC) 保证。

• 弱序内存模型 (对于普通访问): 对于非 Atomics 的普通内存访问（例如 typedArray[index] = value），ECMAScript 允许编译器和处理器进行指令重排。这意味着一个 Agent 观察到的内存操作顺序可能与其代码编写的顺序不同，并且不同 Agents 观察到的顺序也可能不同。这正是数据竞争的根源之一。
• 顺序一致性 (对于 Atomics 操作): Atomics 操作提供了最强的内存顺序保证。在一个 Agent Cluster 中，所有 Agent 都会观察到所有 Atomics 操作以一个全局一致的、总的顺序发生。这简化了并发编程，因为它消除了因指令重排导致的乱序观察。

Happens-before 关系: Atomics 操作通过建立“happens-before”关系来同步 Agents。如果操作 A happens-before 操作 B，那么 A 的所有效果都必须在 B 观察到之前完成。Atomics 的同步操作能够建立跨 Agents 的 happens-before 关系，确保内存修改的可见性。

4.3 Atomics 方法详解与代码示例

Atomics 对象提供了一系列静态方法，它们都操作于 SharedArrayBuffer 的 TypedArray 视图上。

方法名称	描述	原子性 & 顺序性
Atomics.load(arr, idx)	原子地读取指定索引的值。	原子读取，顺序一致 (SC)
Atomics.store(arr, idx, val)	原子地写入指定索引的值。	原子写入，顺序一致 (SC)
Atomics.add(arr, idx, val)	原子地将 val 加到 arr[idx] 上，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.sub(arr, idx, val)	原子地从 arr[idx] 减去 val，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.and(arr, idx, val)	原子地对 arr[idx] 和 val 执行位与操作，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.or(arr, idx, val)	原子地对 arr[idx] 和 val 执行位或操作，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.xor(arr, idx, val)	原子地对 arr[idx] 和 val 执行位异或操作，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.exchange(arr, idx, val)	原子地将 arr[idx] 设置为 val，并返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.compareExchange(arr, idx, oldVal, newVal)	原子地比较 arr[idx] 是否等于 oldVal。如果相等，则将其设置为 newVal；否则不修改。返回 arr[idx] 的旧值。	原子读-修改-写 (RMW)，顺序一致 (SC)
Atomics.wait(arr, idx, val, timeout)	如果 arr[idx] 等于 val，则阻塞当前 Agent，直到被 notify 唤醒或超时。返回 'ok', 'not-equal', 'timed-out'。	同步原语，用于线程等待，顺序一致 (SC)
Atomics.notify(arr, idx, count)	唤醒在 arr[idx] 上等待的 count 个 Agents。返回被唤醒的 Agents 数量。	同步原语，用于线程唤醒，顺序一致 (SC)
Atomics.isLockFree(size)	检查对给定大小（以字节为单位）的原子操作是否可以由硬件无锁地执行。	提供硬件信息，本身不是同步操作

4.3.1 使用 Atomics.add 解决数据竞争的计数器

我们来修改之前有数据竞争的计数器示例，使用 Atomics.add。

main.js (不变):

if (self.crossOriginIsolated) {
    const sharedBuffer = new SharedArrayBuffer(4);
    const counter = new Int32Array(sharedBuffer);

    counter[0] = 0;

    const NUM_WORKERS = 5;
    const INCREMENTS_PER_WORKER = 100000;
    let completedWorkers = 0;

    console.log("主线程：计数器初始值:", counter[0]);

    for (let i = 0; i < NUM_WORKERS; i++) {
        const worker = new Worker('worker-atomic.js'); // 注意这里引入的是新的 worker-atomic.js
        worker.postMessage({ buffer: sharedBuffer, increments: INCREMENTS_PER_WORKER });

        worker.onmessage = () => {
            completedWorkers++;
            if (completedWorkers === NUM_WORKERS) {
                const expectedValue = NUM_WORKERS * INCREMENTS_PER_WORKER;
                console.log("------------------------------------------");
                console.log(`主线程：所有 Worker 完成。预期最终计数: ${expectedValue}`);
                console.log(`主线程：实际最终计数: ${counter[0]}`);
                if (counter[0] !== expectedValue) {
                    console.error("主线程：计数器结果不正确，仍有数据竞争或逻辑错误。");
                } else {
                    console.log("主线程：计数器结果正确！Atomics.add 成功解决数据竞争。");
                }
            }
        };
    }
} else {
    console.warn("环境未跨域隔离，SharedArrayBuffer 不可用。");
}

worker-atomic.js:

onmessage = (event) => {
    const sharedBuffer = event.data.buffer;
    const counter = new Int32Array(sharedBuffer);
    const increments = event.data.increments;

    for (let i = 0; i < increments; i++) {
        // 原子操作：读取，增加，写入，这是一个单一的、不可中断的步骤
        Atomics.add(counter, 0, 1);
    }

    postMessage('done');
};

运行结果分析:
这次，你会发现 实际最终计数 总是等于 预期最终计数。Atomics.add 保证了对 counter[0] 的读取、加 1 和写入是一个原子操作，不会被其他 Agents 的操作打断，从而避免了丢失更新。

4.3.2 使用 Atomics.wait 和 Atomics.notify 实现生产者-消费者模式

Atomics.wait 和 Atomics.notify 是实现线程（Agent）间等待和唤醒机制的强大工具，类似于操作系统中的条件变量。

• Atomics.wait(typedArray, index, value, timeout):
  • typedArray: 必须是 Int32Array 或 BigInt64Array。
  • index: 要等待的元素索引。
  • value: 期望 typedArray[index] 具有的值。如果当前值不等于 value，wait 会立即返回 'not-equal'，不会阻塞。
  • timeout: 可选，等待的毫秒数。如果为 Infinity，则无限等待。
• Atomics.notify(typedArray, index, count):
  • typedArray: 必须是 Int32Array 或 BigInt64Array。
  • index: 要通知的元素索引。
  • count: 可选，要唤醒的 Agents 数量。Infinity 表示唤醒所有等待的 Agents。

代码示例：简单的生产者-消费者队列

假设有一个共享的缓冲区，生产者向其中写入数据，消费者从中读取数据。当队列满时，生产者等待；当队列空时，消费者等待。

main.js (生产者):

if (self.crossOriginIsolated) {
    const BUFFER_SIZE = 10;
    // 使用 Int32Array 存储队列数据，以及队头、队尾指针和信号量
    // 布局：
    // [0]: 锁 (用于保护队头/队尾指针和数据本身)
    // [1]: 队头指针 (readIndex)
    // [2]: 队尾指针 (writeIndex)
    // [3]: 待处理元素数量 (itemCount)
    // [4...BUFFER_SIZE+3]: 实际队列数据
    const sharedBuffer = new SharedArrayBuffer((BUFFER_SIZE + 4) * Int32Array.BYTES_PER_ELEMENT);
    const sharedQueue = new Int32Array(sharedBuffer);

    // 索引定义
    const LOCK_IDX = 0;
    const READ_PTR_IDX = 1;
    const WRITE_PTR_IDX = 2;
    const ITEM_COUNT_IDX = 3;
    const DATA_START_IDX = 4;

    // 初始化
    Atomics.store(sharedQueue, LOCK_IDX, 0); // 0: unlocked, 1: locked
    Atomics.store(sharedQueue, READ_PTR_IDX, 0);
    Atomics.store(sharedQueue, WRITE_PTR_IDX, 0);
    Atomics.store(sharedQueue, ITEM_COUNT_IDX, 0);

    console.log("主线程 (生产者): 队列初始化完成。");

    const consumerWorker = new Worker('worker-consumer.js');
    consumerWorker.postMessage({ buffer: sharedBuffer, bufferSize: BUFFER_SIZE });

    let producedCount = 0;
    const MAX_PRODUCTION = 20;

    function produce() {
        if (producedCount >= MAX_PRODUCTION) {
            console.log("主线程 (生产者): 生产完成。");
            return;
        }

        // 尝试获取锁
        while (Atomics.compareExchange(sharedQueue, LOCK_IDX, 0, 1) !== 0) {
            // 如果锁被占用，等待
            console.log("主线程 (生产者): 队列被锁定，等待...");
            Atomics.wait(sharedQueue, LOCK_IDX, 1); // 等待 LOCK_IDX 变为 1 (被锁)
        }

        // 锁已获取
        const itemCount = Atomics.load(sharedQueue, ITEM_COUNT_IDX);
        if (itemCount === BUFFER_SIZE) {
            // 队列满，释放锁，然后等待消费者消费
            Atomics.store(sharedQueue, LOCK_IDX, 0);
            Atomics.notify(sharedQueue, LOCK_IDX, 1); // 唤醒可能的等待者
            console.log("主线程 (生产者): 队列已满，等待消费者...");
            setTimeout(produce, 100); // 稍后重试生产
            return;
        }

        // 队列未满，生产数据
        const data = producedCount + 100; // 示例数据
        const writeIndex = Atomics.load(sharedQueue, WRITE_PTR_IDX);
        Atomics.store(sharedQueue, DATA_START_IDX + writeIndex, data);
        Atomics.store(sharedQueue, WRITE_PTR_IDX, (writeIndex + 1) % BUFFER_SIZE);
        Atomics.add(sharedQueue, ITEM_COUNT_IDX, 1); // 原子增加计数

        producedCount++;
        console.log(`主线程 (生产者): 生产了数据 ${data}。当前队列元素: ${Atomics.load(sharedQueue, ITEM_COUNT_IDX)}`);

        // 释放锁
        Atomics.store(sharedQueue, LOCK_IDX, 0);
        Atomics.notify(sharedQueue, LOCK_IDX, 1); // 唤醒可能的等待者 (如消费者)

        setTimeout(produce, Math.random() * 500 + 100); // 模拟生产间隔
    }

    produce(); // 启动生产
} else {
    console.warn("环境未跨域隔离，SharedArrayBuffer 不可用。");
}

worker-consumer.js (消费者):

onmessage = (event) => {
    const sharedBuffer = event.data.buffer;
    const BUFFER_SIZE = event.data.bufferSize;
    const sharedQueue = new Int32Array(sharedBuffer);

    // 索引定义 (与生产者一致)
    const LOCK_IDX = 0;
    const READ_PTR_IDX = 1;
    const WRITE_PTR_IDX = 2;
    const ITEM_COUNT_IDX = 3;
    const DATA_START_IDX = 4;

    console.log("Worker (消费者): 启动。");

    let consumedCount = 0;
    const MAX_CONSUMPTION = 20;

    function consume() {
        if (consumedCount >= MAX_CONSUMPTION) {
            console.log("Worker (消费者): 消费完成。");
            return;
        }

        // 尝试获取锁
        while (Atomics.compareExchange(sharedQueue, LOCK_IDX, 0, 1) !== 0) {
            // 如果锁被占用，等待
            // 这里等待的是 LOCK_IDX 变为 1 (被锁)，但实际上我们期望它变为 0 (解锁)
            // 这种等待方式实际上是等待锁释放，可以优化为直接轮询或更复杂的条件变量
            // 对于简单的示例，我们暂时用轮询+wait来模拟
            Atomics.wait(sharedQueue, LOCK_IDX, 1); // 等待 LOCK_IDX 保持 1 (被锁)
        }

        // 锁已获取
        const itemCount = Atomics.load(sharedQueue, ITEM_COUNT_IDX);
        if (itemCount === 0) {
            // 队列空，释放锁，然后等待生产者生产
            Atomics.store(sharedQueue, LOCK_IDX, 0);
            Atomics.notify(sharedQueue, LOCK_IDX, 1); // 唤醒可能的等待者
            console.log("Worker (消费者): 队列为空，等待生产者...");
            setTimeout(consume, 100); // 稍后重试消费
            return;
        }

        // 队列不为空，消费数据
        const readIndex = Atomics.load(sharedQueue, READ_PTR_IDX);
        const data = Atomics.load(sharedQueue, DATA_START_IDX + readIndex);
        Atomics.store(sharedQueue, READ_PTR_IDX, (readIndex + 1) % BUFFER_SIZE);
        Atomics.sub(sharedQueue, ITEM_COUNT_IDX, 1); // 原子减少计数

        consumedCount++;
        console.log(`Worker (消费者): 消费了数据 ${data}。当前队列元素: ${Atomics.load(sharedQueue, ITEM_COUNT_IDX)}`);

        // 释放锁
        Atomics.store(sharedQueue, LOCK_IDX, 0);
        Atomics.notify(sharedQueue, LOCK_IDX, 1); // 唤醒可能的等待者 (如生产者)

        setTimeout(consume, Math.random() * 700 + 50); // 模拟消费间隔
    }

    consume(); // 启动消费
};

这个示例展示了如何使用 Atomics.compareExchange 实现一个简单的自旋锁来保护对共享队列的访问，并使用 Atomics.wait 和 Atomics.notify 来在队列满或空时阻塞和唤醒 Agents。需要注意的是，Atomics.wait 只有在 typedArray[index] 与 value 相等时才会阻塞。在我们的锁示例中，Atomics.wait(sharedQueue, LOCK_IDX, 1) 是在锁已经被占用的情况下，等待 LOCK_IDX 保持 1，这实际上是等待锁的释放（当 notify 发生时）。更典型的 wait/notify 模式是将信号量设置为 0，然后等待它变为非 0。

4.3.3 Atomics.fence()

Atomics.fence() 方法在 ECMAScript 规范中被定义为提供一个内存屏障（Memory Barrier），确保在屏障之前的所有内存操作在屏障之后的所有内存操作之前完成。然而，在当前的 JavaScript 引擎实现中，大多数 Atomics 操作本身就提供了顺序一致性保证，这通常意味着它们已经包含了必要的内存屏障。因此，Atomics.fence() 在 JavaScript 中并不常用，因为它提供的额外保证通常已经被其他原子操作所涵盖。理解它的存在有助于我们理解更底层的内存模型概念。

---

第五讲：ES 规范下的内存模型与一致性保证

要真正掌握 SharedArrayBuffer 和 Atomics，我们必须对 ECMAScript 规范所定义的内存模型有一个清晰的理解。这决定了不同 Agents 之间共享内存操作的可见性和顺序性。

5.1 内存模型的层级

计算机系统中的内存模型是一个复杂的多层概念：

• 硬件内存模型 (Hardware Memory Model): CPU 架构（如 x86, ARM）定义了其处理器如何执行内存操作、如何缓存数据以及何时将数据从缓存写入主内存。不同的架构有不同的内存一致性级别。
• 操作系统内存模型 (OS Memory Model): 操作系统通过虚拟内存、分页、上下文切换等机制，在硬件之上提供了一个更抽象的内存视图。
• 语言运行时内存模型 (Language Runtime Memory Model): 编程语言的运行时（如 V8 引擎）在 OS 内存模型之上，进一步定义了语言层面的内存访问行为。ECMAScript 规范定义的正是这一层。

JavaScript 的内存模型是抽象的，它独立于底层硬件和操作系统。ECMAScript 规范旨在提供一个可移植的、跨平台的一致性保证。

5.2 ECMAScript Shared Memory Model 的核心原则

ECMAScript 的共享内存模型可以概括为：弱序模型 + 强序原子操作。

1. 弱序内存模型 (Weakly Ordered Memory Model) for Non-Atomic Accesses:

   • 指令重排: 对于非原子操作（即直接通过 typedArray[index] 进行的读写），JavaScript 引擎和底层硬件都可能为了优化性能而对指令进行重排。
     • 编译器重排：在编译时改变指令顺序。
     • 处理器重排：在运行时动态调整指令执行顺序。
   • 可见性延迟: 一个 Agent 对共享内存的写入，可能不会立即对其他 Agents 可见。缓存同步需要时间，并且在没有同步机制的情况下，无法保证可见性。
   • 非原子性: typedArray[index] = value 这样的操作不是原子性的。它可能被分解为多个微操作（例如，加载、修改、存储），这些微操作之间可能被其他 Agents 的操作打断。

   举例:
   如果 Agent A 写入 X = 1; Y = 2;
   而 Agent B 读取 console.log(Y, X);
   在弱序内存模型下，B 可能会看到 Y=2, X=0 (如果 X 初始为 0)，因为 A 对 X 的写入可能在 B 看到 A 对 Y 的写入之后才变得可见。

2. 顺序一致性 (Sequentially Consistent, SC) for Atomics Operations:

   • Atomics 对象的所有方法（除了 Atomics.isLockFree）都提供了顺序一致性保证。
   • 这意味着，所有 Agents 都会观察到所有 Atomics 操作以一个全局一致的、总的顺序发生，就像这些操作是按顺序在一个单核处理器上执行一样。
   • 原子性: Atomics 操作是不可中断的。例如，Atomics.add 在读取值、增加值和写入新值这三个步骤中是作为一个单一的、不可分割的操作完成的。
   • 可见性: Atomics 操作保证了内存的可见性。一个 Agent 通过 Atomics 写入的值，在其他 Agent 通过 Atomics 读取时，将总是看到最新的值。
   • 顺序性: Atomics 操作强制执行内存顺序。在任何一个 Agent 内部，一个 Atomics 操作之前的内存操作，其效果对其他 Agents 来说，都将在该 Atomics 操作之后变得可见。同样，一个 Atomics 操作之后的所有内存操作，都将看起来在该 Atomics 操作之后发生。

5.3 内存屏障 (Memory Barriers)

Atomics 操作内在包含了内存屏障。内存屏障是一种同步指令，它强制 CPU 或编译器在屏障之前完成所有内存操作，然后才能执行屏障之后的内存操作。

• Acquire Barrier (获取屏障): 确保屏障之后的所有内存访问都发生在屏障之前的所有内存访问之后。常用于锁的获取操作，保证在获取锁之后看到被保护资源的最新状态。
• Release Barrier (释放屏障): 确保屏障之前的所有内存访问都发生在屏障之后的所有内存访问之前。常用于锁的释放操作，保证在释放锁之前所有对被保护资源的修改都已完成并可见。
• Full Barrier (全屏障): 结合了获取和释放屏障的功能，提供最强的顺序保证。Atomics 的顺序一致性操作通常隐含了全屏障。

5.4 总结：普通访问 vs. 原子访问

下表总结了普通内存访问和原子内存访问在 SharedArrayBuffer 上的关键差异：

特性	普通内存访问 (arr[idx] = val)	原子内存访问 (Atomics.store(arr, idx, val))
原子性	非原子性，可能被中断	原子性，不可中断
可见性	不保证立即可见，可能读取到旧值或不一致值	保证可见性，总能读取到其他 Agent 最新写入的值
顺序性	弱序，可能发生指令重排和乱序观察	顺序一致，所有 Agents 观察到全局一致的操作顺序
数据竞争	容易导致数据竞争，引发错误	消除数据竞争，提供一致性保证
性能	通常较快，但有风险	引入额外开销 (原子指令，内存屏障)，但保证正确性
使用场景	不应用于多 Agent 共享的写操作	必须用于多 Agent 共享的写操作及同步读写

理解这个内存模型至关重要。它告诉我们，仅仅使用 SharedArrayBuffer 并不能自动解决并发问题。只有结合 Atomics API，我们才能在 JavaScript 中安全、正确地进行共享内存编程。否则，即使你看到了 SharedArrayBuffer 中的值似乎“正确”，那也可能是偶然，在更复杂的并发场景或不同硬件上，结果可能截然不同。

---

第六讲：常见并发模式与最佳实践

掌握了 SharedArrayBuffer 和 Atomics 的基本原理后，我们来看看如何将它们应用于常见的并发编程模式，并探讨一些最佳实践。

6.1 互斥锁 (Mutex)

互斥锁是一种最基本的同步原语，用于确保在任何给定时间只有一个 Agent 可以访问共享资源（临界区）。我们可以使用 Atomics.compareExchange 和 Atomics.wait/notify 来实现一个简单的用户态互斥锁。

锁的状态:

• 0: 未锁定 (unlocked)
• 1: 已锁定 (locked)

实现原理:

1. 获取锁 (lock()):
   • 尝试使用 Atomics.compareExchange 将锁状态从 0 设置为 1。
   • 如果成功（返回 0），表示获取到锁。
   • 如果失败（返回 1），表示锁已被其他 Agent 占用，则调用 Atomics.wait 等待锁状态变为 0。被唤醒后，再次尝试获取锁。
2. 释放锁 (unlock()):
   • 使用 Atomics.store 将锁状态设置为 0。
   • 调用 Atomics.notify 唤醒一个或多个正在等待的 Agents。

代码示例：Mutex 实现

// mutex.js
class Mutex {
    constructor(sharedBuffer, index = 0) {
        // 共享缓冲区必须是 Int32Array 或 BigInt64Array
        // index 是锁变量在 TypedArray 中的位置
        this.lockArray = new Int32Array(sharedBuffer, index * Int32Array.BYTES_PER_ELEMENT, 1);
        Atomics.store(this.lockArray, 0, 0); // 初始化锁为未锁定
    }

    lock() {
        // 尝试将锁从 0 (unlocked) 交换为 1 (locked)
        // 如果成功，compareExchange 会返回 0
        while (Atomics.compareExchange(this.lockArray, 0, 0, 1) !== 0) {
            // 如果返回 1，说明锁已被占用，则等待 lockArray[0] 变为 0
            // wait() 会在 lockArray[0] 与期望值 (这里是 1) 相等时阻塞，直到被 notify 唤醒
            // 在我们的互斥锁逻辑中，我们等待的是锁变为 0 (解锁状态)，然后我们才能尝试获取它。
            // 这里的 Atomics.wait(this.lockArray, 0, 1) 意为：
            // "如果 lockArray[0] 是 1（即锁已被占用），那么就等待；否则，如果不是 1，就继续执行。"
            // 这意味着当锁被占用时，它会阻塞。一旦锁被释放(变为0)，wait会返回'not-equal'，循环继续尝试获取锁。
            Atomics.wait(this.lockArray, 0, 1);
        }
    }

    unlock() {
        // 将锁设置为 0 (unlocked)
        Atomics.store(this.lockArray, 0, 0);
        // 唤醒一个或多个在等待的 Agent
        Atomics.notify(this.lockArray, 0, 1); // 唤醒一个等待者
    }
}

// main.js (使用 Mutex)
if (self.crossOriginIsolated) {
    const sharedBuffer = new SharedArrayBuffer(8); // 4字节用于计数器，4字节用于锁
    const counter = new Int32Array(sharedBuffer, 0, 1);
    const mutex = new Mutex(sharedBuffer, 1); // 锁变量从索引 1 开始

    counter[0] = 0; // 初始化计数器

    const NUM_WORKERS = 5;
    const INCREMENTS_PER_WORKER = 100000;
    let completedWorkers = 0;

    console.log("主线程：计数器初始值:", counter[0]);

    for (let i = 0; i < NUM_WORKERS; i++) {
        const worker = new Worker('worker-mutex.js');
        worker.postMessage({ buffer: sharedBuffer, increments: INCREMENTS_PER_WORKER, lockIndex: 1 });

        worker.onmessage = () => {
            completedWorkers++;
            if (completedWorkers === NUM_WORKERS) {
                const expectedValue = NUM_WORKERS * INCREMENTS_PER_WORKER;
                console.log("------------------------------------------");
                console.log(`主线程：所有 Worker 完成。预期最终计数: ${expectedValue}`);
                console.log(`主线程：实际最终计数: ${counter[0]}`);
                if (counter[0] !== expectedValue) {
                    console.error("主线程：计数器结果不正确。");
                } else {
                    console.log("主线程：计数器结果正确！Mutex 成功保护了数据。");
                }
            }
        };
    }
} else {
    console.warn("环境未跨域隔离，SharedArrayBuffer 不可用。");
}

// worker-mutex.js
// 假设 Mutex 类被导入或内联
class MutexWorker { // 重新定义一下，因为Worker不能直接访问主线程的类实例
    constructor(sharedBuffer, index = 0) {
        this.lockArray = new Int32Array(sharedBuffer, index * Int32Array.BYTES_PER_ELEMENT, 1);
    }

    lock() {
        while (Atomics.compareExchange(this.lockArray, 0, 0, 1) !== 0) {
            Atomics.wait(this.lockArray, 0, 1);
        }
    }

    unlock() {
        Atomics.store(this.lockArray, 0, 0);
        Atomics.notify(this.lockArray, 0, 1);
    }
}

onmessage = (event) => {
    const sharedBuffer = event.data.buffer;
    const increments = event.data.increments;
    const lockIndex = event.data.lockIndex;

    const counter = new Int32Array(sharedBuffer, 0, 1);
    const mutex = new MutexWorker(sharedBuffer, lockIndex);

    for (let i = 0; i < increments; i++) {
        mutex.lock(); // 获取锁
        try {
            // 临界区：安全地修改共享数据
            counter[0]++;
        } finally {
            mutex.unlock(); // 释放锁
        }
    }

    postMessage('done');
};

在实际应用中，你可能需要将 Mutex 类定义在一个共享文件中，或者在 Worker 内部重新定义，因为类实例不能通过 postMessage 传递。

6.2 信号量 (Semaphore)

信号量是一种更通用的同步原语，用于控制对有限资源的并发访问数量。它可以允许 N 个 Agent 同时进入临界区，而互斥锁只允许 1 个。

实现原理:
使用一个共享整数作为计数器，表示可用资源的数量。

• 获取 (acquire()): 尝试原子地减少计数器。如果计数器为正，则减少并继续；如果为零，则等待直到计数器变为正。
• 释放 (release()): 原子地增加计数器，并唤醒一个或多个等待的 Agents。

由于 Atomics 直接提供了 add 和 sub 操作，实现信号量非常直接。

6.3 生产者-消费者模式

我们已经在第四讲中展示了一个基于 Atomics.wait/notify 的生产者-消费者队列示例。这个模式是并发编程中最经典的模式之一，用于解耦生产者和消费者，提高系统的吞吐量和响应性。

核心思想:

• 生产者向共享队列添加数据。
• 消费者从共享队列移除数据。
• 当队列满时，生产者阻塞等待。
• 当队列空时，消费者阻塞等待。
• 需要锁来保护队列的读写指针和数据本身。
• 需要条件变量（通过 wait/notify 实现）来协调生产者和消费者。

6.4 无锁编程 (Lock-Free Programming)

无锁编程是一种高级并发技术，它旨在通过避免使用互斥锁来消除死锁和优先级反转等问题，并可能在某些情况下提供更好的性能和可伸缩性。Atomics.compareExchange 是实现无锁算法（如 CAS 循环）的关键原语。

例如，实现一个无锁的计数器：

function incrementLockFree(counterArray, index) {
    let oldValue;
    let newValue;
    do {
        oldValue = Atomics.load(counterArray, index);
        newValue = oldValue + 1;
    } while (Atomics.compareExchange(counterArray, index, oldValue, newValue) !== oldValue);
    return newValue;
}

这个 incrementLockFree 函数会不断尝试读取当前值，计算新值，然后通过 compareExchange 尝试更新。如果 compareExchange 发现 counterArray[index] 的值在读取和尝试交换之间被其他 Agent 修改了（即 counterArray[index] 不等于 oldValue），它会失败并返回当前值，循环将重新开始。这种模式称为“自旋锁”或“忙等待”，在竞争激烈时可能会消耗大量 CPU。

无锁编程非常复杂，需要对内存模型和算法有深刻的理解。对于大多数 JavaScript 应用，基于 Atomics 的锁（如我们实现的 Mutex）已经足够，并且更容易正确实现。

6.5 错误处理与超时

Atomics.wait 方法接受一个 timeout 参数。这是一个非常重要的特性，可以防止 Agent 无限期阻塞。

const status = Atomics.wait(sharedArray, 0, 0, 5000); // 最多等待 5 秒
if (status === 'timed-out') {
    console.error("等待超时，可能存在死锁或逻辑错误。");
    // 执行超时处理逻辑
} else if (status === 'not-equal') {
    console.log("等待条件不满足，无需等待。");
} else if (status === 'ok') {
    console.log("成功被唤醒。");
}

在设计并发系统时，务必考虑超时机制，以提高系统的健壮性。

6.6 调试挑战

并发问题是出了名的难以调试。数据竞争和竞态条件往往是偶发性的，难以复现，且在调试器下运行时的行为可能与正常运行时不同（Heisenbug）。

• 日志记录: 详细的日志可以帮助追踪事件发生的顺序。
• 确定性测试: 尽可能编写能够确定性地触发并发问题的测试用例。
• 隔离问题: 尝试将并发部分的代码尽可能地隔离，以便单独测试。
• 避免过度同步: 过多的锁或原子操作会引入不必要的开销，并可能导致死锁或降低性能。只在真正需要保护共享状态的地方使用同步原语。

---

第七讲：Agent Clusters 的未来展望与高级议题

SharedArrayBuffer 和 Atomics 为 JavaScript 带来了前所未有的并发能力，但这仅仅是开始。Agent Clusters 的概念也为未来的 Web 平台演进奠定了基础。

7.1 WebAssembly Shared Memory

WebAssembly (Wasm) 作为 Web 平台的低级语言，也支持共享内存。Wasm 模块可以直接访问 SharedArrayBuffer，并且 Wasm 线程也可以操作共享内存。这意味着 JavaScript 和 WebAssembly 模块可以协同工作，通过共享内存实现高性能的并发计算。例如，一个复杂的数值计算库可以用 WebAssembly 编写，并通过 SharedArrayBuffer 与 JavaScript Worker 共享数据，从而充分利用多核 CPU 的性能。

// 假设有一个名为 'module.wasm' 的 WebAssembly 模块
// 并且它导出了一个名为 'shared_memory' 的内存对象
// 以及 'increment' 函数来操作共享内存

// 在 JavaScript 中
const memory = new WebAssembly.Memory({
    initial: 1, // 1页 (64KB)
    maximum: 10,
    shared: true // 声明为共享内存
});

// 加载 WebAssembly 模块
WebAssembly.instantiateStreaming(fetch('module.wasm'), {
    env: {
        memory: memory,
        // 其他导入，例如 Atomics 相关的函数，如果 Wasm 需要直接使用它们
    }
}).then(result => {
    const { increment, shared_memory } = result.instance.exports;

    // shared_memory 是一个 SharedArrayBuffer
    const sab = shared_memory.buffer;
    const i32a = new Int32Array(sab);

    // Wasm 和 JS 可以同时操作这个 sab
    // ...
});

这种互操作性是 Web 平台在高性能计算领域的重要发展方向。

7.2 新的并发原语与抽象

虽然 Atomics API 提供了底层原子操作和同步原语，但在 C++ 等语言中常见的更高级的并发抽象，如读写锁（Read-Write Locks）、屏障（Barriers）等，目前在 JavaScript 中需要开发者自行基于 Atomics 构建。未来，ECMAScript 规范可能会考虑引入更高层次的并发原语，以简化并发编程的复杂性。

例如，一个原生的 Mutex 类或 Semaphore 类，将 Atomics.compareExchange 和 Atomics.wait/notify 的复杂性封装起来，提供更简洁、更安全的 API。

7.3 跨域隔离的重要性回顾

在整个讲座中，我们反复强调了跨域隔离 (Cross-Origin Isolation)对于 SharedArrayBuffer 可用性的重要性。这不仅仅是一个技术细节，它体现了 Web 平台在性能、功能和安全性之间权衡的哲学。随着 Web 平台功能的增强，安全沙箱的机制也需要不断进化。理解并正确配置 Cross-Origin-Opener-Policy (COOP) 和 Cross-Origin-Embedder-Policy (COEP) 是每一个希望利用 SharedArrayBuffer 的开发者必须掌握的知识。

---

展望与总结

今天，我们深入探讨了 JavaScript Agent Clusters、SharedArrayBuffer 以及 Atomics API，揭示了 ECMAScript 规范下跨 Worker 共享内存的数据竞争与一致性保证。我们理解了 Agent Cluster 如何定义共享内存的边界，SharedArrayBuffer 如何作为共享内存的基石，以及数据竞争的本质危害。最重要的是，我们学习了 Atomics API 如何通过原子操作和顺序一致性内存模型，为我们提供了构建正确、高效并发应用所需的强大工具。

SharedArrayBuffer 和 Atomics 为 JavaScript 带来了真正的多核并发能力，是现代 Web 应用迈向更高性能和更复杂架构的关键一步。然而，驾驭这些强大的工具需要开发者对并发编程的挑战有深刻的理解和严谨的态度。正确地使用 Atomics 避免数据竞争，精心设计同步机制，是确保并发程序健壮性的不二法门。希望今天的讲座能为大家在 JavaScript 并发编程的道路上提供有益的指导和启发。谢谢大家！