JS如何实现SharedArrayBuffer？共享内存

· 日常编程 · 180517

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  {
    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？共享内存的详细内容，更多请关注骃骐网【www.myinqi.com】。

相关推荐：

如何实现Python中线程安全的单例模式_使用元类metaclass或Lock加锁

因为__new__不是原子操作：线程A判断_instance为None后，未执行super().__new__前，线程B也判为None，导致重复创建；GIL不保护跨语句逻辑，需用双重检查锁定（DCL）加threading.Lock确保线程安全。 为什么直接用 __new__ 实现单例在多线程下会失效 因为 __new__ 本身不是原子操作：线程 A 判断 _instance 为 None 后，还没...

Python如何实现图的深度优先遍历_基于栈结构或递归函数实现

递归DFS栈溢出风险高因CPython默认递归深度仅1000，长链或环易触发RecursionError；隐式栈不可控，闭包和帧对象加剧内存开销；图应优先用显式栈实现。 递归实现DFS时，为什么栈溢出风险比预期高？ Python默认递归深度限制是1000层，图中存在长链或环状结构时极易触发RecursionError。这不是算法错，而是CPython解释器对递归调用的硬性约束。 用sys.setr...

为什么Python程序占用内存持续升高不释放_使用memory_profiler进行环境监控

memory_profiler仅统计每行新分配内存，不追踪对象生命周期或引用链，适合定位单次执行的内存尖峰，而非长周期泄漏；真正卡住内存的是强引用未释放，需用gc.get_referrers()或objgraph分析。 内存持续升高不释放，大概率不是“没回收”，而是对象还在被强引用着——memory_profiler能帮你看到哪行代码在吃内存，但不能告诉你谁在死死拽着它不放。 为什么memory_...

Python开发FastAPI怎么实现WebSocket在线人数统计_基于内存字典或Redis维护连接池

FastAPI中需用可哈希标识（如id(websocket)或user_id）增减在线人数，内存方案须加锁防竞态，多进程必须用Redis原子指令incr/decr维护共享计数，并配合心跳键实现高可用。 WebSocket连接建立时怎么安全地增减在线人数 FastAPI的WebSocket实例没有唯一ID，直接用websocket对象做字典键会报TypeError: unhashable type:...

Python如何实现一致性哈希算法_解决分布式缓存数据分配不均

一致性哈希通过固定哈希空间（如2^32）构建环形结构，节点和数据映射其上并顺时针就近分配；增删节点仅影响邻近区间，大幅减少数据迁移；引入虚拟节点可缓解物理节点分布不均问题，提升负载均衡性。 直接用 hash_ring 库最省事，但真要自己写、调参或排查分布不均问题，必须理解虚拟节点数量、哈希函数输出范围、环结构更新时机这三个关键点。 为什么简单取模（hash(key) % N）在节点变动时会崩 节...

Python怎么避免Flask应用遭遇内存溢出_控制大文件内存载入与及时显式del释放

应避免大文件读取时调用.read()等一次性加载方法，改用分块读取、流式处理、临时文件磁盘存储及作用域隔离，并通过MAX_CONTENT_LENGTH限制上传大小、禁用全局缓存、谨慎记录日志来防止内存溢出。 大文件读取时直接用 open().read() 会爆内存 Flask 默认没有请求体大小限制，用户上传一个 500MB 的文件，如果你写 request.files['file'].read(...

如何在Raspberry Pi上配置Python 3开发环境_优化内存占用与库安装

树莓派pip安装常卡在“Building wheel”阶段，因ARM架构编译资源有限、默认swap仅100MB，编译大库易OOM导致假死；需增大swap、换清华源（含apt主源、raspi.list和pip.conf）、优先用apt装预编译包（如sudo apt install python3-opencv），或强制二进制安装。 树莓派上直接用系统自带的 Python 3 就能跑基础脚本，但想稳定...

Python Django中如何实现点赞收藏的计数功能_使用F表达式避免竞争条件

直接obj.likes += 1在并发下丢数据，是因为该操作分“读-改-写”三步：先查出旧值（如99），Python内存中加1得100，再保存；若两个请求同时执行，均基于99计算并写入100，最终结果为100而非102，造成更新丢失。 为什么直接 obj.likes += 1 在并发下会丢数据 多个用户几乎同时点赞时，Django 默认先查出当前 likes 值（比如 99），各自加 1 得到 1...

Python中Scikit-learn如何实现半监督学习_利用LabelPropagation

LabelPropagation要求数据具备局部平滑性，特征须标准化，未标记样本标签必须为-1，且需至少两个已标记类别；拟合用transduction_获取全部预测，不提供置信度，对噪声敏感。 LabelPropagation 在 scikit-learn 中的适用前提 LabelPropagation 不是万能半监督工具，它要求数据天然具备“局部平滑性”——即相似样本大概率共享标签。如果特征空间...