JS共享内存实现方法及SharedArrayBuffer详解

在IT行业这个发展更新速度很快的行业，只有不停止的学习，才不会被行业所淘汰。如果你是文章学习者，那么本文《JS共享内存怎么实现？SharedArrayBuffer详解》就很适合你！本篇内容主要包括##content_title##，希望对大家的知识积累有所帮助，助力实战开发！

JavaScript通过SharedArrayBuffer实现共享内存，允许多个线程访问同一内存块，提升大数据处理性能。2. 创建SharedArrayBuffer实例并用postMessage传递引用，实现主线程与Worker间高效通信。3. 必须配合Atomics对象进行原子操作，防止数据竞争。4. 使用受限于跨域隔离策略，需服务器配置COOP和COEP头部以确保安全。5. 相比postMessage的序列化复制，SharedArrayBuffer避免了数据传输开销，适合高性能场景。

在JavaScript中实现共享内存，核心就是利用SharedArrayBuffer。它提供了一种机制，让多个执行上下文（比如主线程和Web Worker）能够访问同一个内存块，而不是通过序列化和反序列化来复制数据，从而在处理大量数据时显著提升性能。

解决方案

要使用SharedArrayBuffer，你首先需要创建一个它的实例，这个实例代表了一块可以在不同线程间共享的固定大小的原始二进制数据缓冲区。与普通的ArrayBuffer不同，SharedArrayBuffer的实例在创建后可以被多个Worker或主线程引用，并且它们操作的是同一份内存。

创建一个SharedArrayBuffer很简单：

const sharedBuffer = new SharedArrayBuffer(1024); // 创建一个1KB的共享内存
const sharedInt32Array = new Int32Array(sharedBuffer); // 创建一个视图，以便操作其中的整数数据

创建后，你可以通过postMessage方法将这个sharedBuffer传递给Web Worker。但这里有个关键点，传递的不是数据的副本，而是对同一个SharedArrayBuffer对象的引用。

在主线程：

const worker = new Worker('worker.js');
const sharedBuffer = new SharedArrayBuffer(1024);
const sharedArray = new Int32Array(sharedBuffer);

// 初始化一些数据
for (let i = 0; i < sharedArray.length; i++) {
    sharedArray[i] = i;
}

worker.postMessage({ buffer: sharedBuffer });

worker.onmessage = (event) => {
    console.log('Worker更新后的数据:', sharedArray[0]); // 看看worker是不是真的改了
};

在worker.js中：

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

    // Worker修改共享内存中的数据
    sharedArray[0] = 999;
    console.log('Worker内部修改数据:', sharedArray[0]);

    // 通知主线程，或者继续操作
    postMessage('数据已更新');
};

需要特别注意的是，为了防止数据竞争（race condition）和确保操作的原子性，当多个线程同时读写共享内存时，必须配合Atomics对象进行同步操作。Atomics提供了一系列原子操作，比如Atomics.add()、Atomics.load()、Atomics.store()、Atomics.wait()和Atomics.notify()，它们保证了对共享内存的读写操作是不可中断的，从而避免了数据损坏或不一致。

一个简单的原子操作示例：

// 在主线程或Worker中
Atomics.add(sharedArray, 0, 1); // 原子地将sharedArray[0]的值增加1
const value = Atomics.load(sharedArray, 0); // 原子地读取sharedArray[0]的值

另外，SharedArrayBuffer的使用受到了严格的浏览器安全限制。它要求页面必须启用跨域隔离（Cross-Origin Isolation），这意味着你的服务器需要发送特定的HTTP响应头：Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp。如果缺少这些头部，SharedArrayBuffer将无法使用，或者在某些浏览器中会退化为普通的ArrayBuffer。

为什么浏览器对SharedArrayBuffer的使用有严格限制？

这其实是个关于安全和性能的权衡。SharedArrayBuffer在最初推出时，因为一些安全漏洞（比如著名的Spectre和Meltdown侧信道攻击）而被暂时禁用或限制了。这些攻击可以通过测量CPU执行时间差来推断出内存中的敏感信息，而SharedArrayBuffer能够提供高精度计时器，使得这种攻击变得更容易实现。

为了应对这些潜在的风险，浏览器厂商选择对SharedArrayBuffer的重新启用施加了严格的条件，即要求页面处于“跨域隔离”状态。这意味着你的页面不能加载任何没有明确允许的跨域资源，从而大幅降低了侧信道攻击的风险。简单来说，就是为了你的用户安全，浏览器强制你把门关严实了，才能用这个强大的工具。如果没有这些头部，浏览器会认为你的环境不够安全，也就不会暴露SharedArrayBuffer的能力。

SharedArrayBuffer与传统数据传递方式（如postMessage）有何不同？

传统上，Web Worker和主线程之间的数据传递主要依赖postMessage。当你通过postMessage发送一个对象（比如一个大的数组或JSON数据）时，浏览器会对其进行序列化（structured clone algorithm），然后在接收端进行反序列化。这个过程实际上是创建了一个数据的“副本”。对于小数据量来说，这几乎是瞬间完成的，你感觉不到延迟。

然而，当数据量变得非常庞大时，比如几十兆甚至上百兆的图像数据、视频帧或者大型数据集，序列化和反序列化的开销就会变得非常显著。这不仅会消耗大量的CPU资源，还可能导致主线程的卡顿，影响用户体验。

SharedArrayBuffer则彻底改变了这种模式。它不是传递数据的副本，而是传递对同一块内存的引用。这意味着主线程和Worker操作的都是同一块物理内存。数据不需要被复制，也不需要经过序列化和反序列化，从而避免了这些开销。想象一下，你不再需要把一大箱文件从一个办公室搬到另一个办公室，而是两个同事可以直接在同一个文件柜里翻阅文件。这对于需要高性能计算、复杂数据处理或实时协作的场景来说，是质的飞跃。

使用SharedArrayBuffer时，如何避免数据竞争（Race Condition）问题？

数据竞争是并发编程中一个非常常见且棘手的问题，当多个线程同时访问和修改共享资源（这里就是SharedArrayBuffer中的数据）时，操作的顺序不确定，可能导致不可预测的结果或数据损坏。

为了解决这个问题，JavaScript提供了Atomics对象。Atomics提供了一系列原子操作，这些操作是不可中断的。这意味着当一个线程执行一个原子操作时，其他线程不能同时对同一块内存执行任何操作，直到当前操作完成。这保证了数据的一致性。

以下是一些常用的Atomics方法及其用途：

• Atomics.load(typedArray, index): 原子地读取指定索引的值。
• Atomics.store(typedArray, index, value): 原子地写入指定索引的值。
• Atomics.add(typedArray, index, value): 原子地将指定索引的值增加value。
• Atomics.sub(typedArray, index, value): 原子地将指定索引的值减少value。
• Atomics.compareExchange(typedArray, index, expectedValue, replacementValue): 原子地比较并交换。如果typedArray[index]的值等于expectedValue，则将其替换为replacementValue。这个方法在实现锁或信号量时非常有用。
• Atomics.wait(typedArray, index, value, timeout): 让当前线程等待，直到typedArray[index]的值不再是value，或者超时。这是一个阻塞操作，通常用于实现更复杂的同步机制（如生产者-消费者模型）。
• Atomics.notify(typedArray, index, count): 唤醒在typedArray[index]上等待的线程。

举个简单的例子，假设我们有一个共享计数器：

// sharedBuffer 是 SharedArrayBuffer，counterArray 是 Int32Array 视图
const counterArray = new Int32Array(sharedBuffer);
counterArray[0] = 0; // 初始化计数器

// 在多个Worker中，如果都直接 counterArray[0]++，就会有竞争问题
// 正确做法是使用 Atomics.add
Atomics.add(counterArray, 0, 1); // 原子地增加计数器

通过Atomics.add，无论多少个Worker同时尝试增加计数器，最终的结果都会是正确的，因为每次增加都是一个不可分割的操作。

更复杂的场景，比如一个Worker需要等待另一个Worker完成某项任务才能继续：

// Worker A
// ...执行一些耗时操作...
Atomics.store(statusArray, 0, 1); // 设置状态为“完成”
Atomics.notify(statusArray, 0, Infinity); // 唤醒所有等待的Worker

// Worker B
// ...做一些准备工作...
// 等待 Worker A 完成
const status = Atomics.wait(statusArray, 0, 0); // 如果 statusArray[0] 还是 0，就等待
if (status === 'ok') {
    // Worker A 已经完成，可以继续了
} else if (status === 'timed-out') {
    console.warn('等待超时！');
}

通过Atomics.wait和Atomics.notify，你可以构建出生产者-消费者队列、锁机制等更复杂的并发模式，确保共享内存的正确使用，避免了数据不一致和程序崩溃的风险。正确地使用Atomics是发挥SharedArrayBuffer威力的关键，也是避免引入难以调试的并发bug的根本。

本篇关于《JS共享内存实现方法及SharedArrayBuffer详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！