当前位置：首页 > 文章列表 > 文章 > 前端 > JS多线程计算实现方式详解

JS多线程计算实现方式详解

2026-03-08 22:52:35 0浏览收藏

Web Workers的基本用法与限制

当我第一次接触Web Workers时，感觉它有点像个“黑盒子”，你把任务扔进去，它处理完再把结果丢回来。最简单的用法就是创建一个Worker实例，然后用postMessage方法把数据传给它，Worker处理完后，再通过它自己的postMessage方法把结果发回来，主线程通过监听onmessage事件来接收。

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

    myWorker.postMessage({ type: 'calculate', data: 1000000000 }); // 发送数据给worker

    myWorker.onmessage = function(e) {
        console.log('主线程收到消息:', e.data);
        // 假设worker计算了斐波那契数列的第N项
        if (e.data.type === 'result') {
            document.getElementById('result').innerText = `计算结果：${e.data.value}`;
        }
    };

    myWorker.onerror = function(error) {
        console.error('Worker出错:', error);
    };

    // 偶尔我会忘记关闭worker，这其实是个小问题，尤其是在单页应用里
    // myWorker.terminate(); // 当不再需要时，记得终止worker
}

// worker.js (Worker线程)
function fibonacci(n) {
    if (n <= 1) return n;
    return fibonacci(n - 1) + fibonacci(n - 2);
}

self.onmessage = function(e) {
    console.log('Worker收到消息:', e.data);
    if (e.data.type === 'calculate') {
        const num = e.data.data;
        const result = fibonacci(num > 40 ? 40 : num); // 避免计算量过大导致浏览器卡死，这里做了限制
        self.postMessage({ type: 'result', value: result }); // 将结果发回主线程
    }
};

然而，Web Workers并不是万能的。它最大的限制就是不能直接操作DOM，也不能直接访问主线程的全局变量，比如window对象。这意味着你不能在Worker里直接更新UI。所有的数据传递都必须通过序列化和反序列化，这在处理大量数据时会带来额外的开销。另外，Worker脚本必须是同源的，这在一些复杂的部署环境下可能会有点麻烦。调试Worker也需要一些技巧，通常要在浏览器的开发者工具里单独找到Worker的上下文。

共享内存与ArrayBuffer：Web Workers的进阶应用

早些年，Web Workers虽然能并行计算，但数据传递的成本是个问题，因为每次postMessage都会复制数据。当数据量很大时，复制的开销甚至可能抵消并行计算带来的好处。后来，SharedArrayBuffer和Atomics的出现，简直是打开了新世界的大门。

SharedArrayBuffer允许你在主线程和Worker线程之间共享同一块内存区域。这就意味着，数据不再需要复制，而是可以直接读写同一份数据。但这带来了一个新的挑战：竞态条件。多个线程同时读写同一块内存，就可能出现意想不到的结果。这时候，Atomics对象就派上用场了，它提供了一系列原子操作，确保对共享内存的读写是安全的、原子的，不会被中断。比如Atomics.add、Atomics.load、Atomics.store，以及更复杂的Atomics.wait和Atomics.notify，用于线程间的同步。

// main.js (主线程)
// 记得要设置响应头：Cross-Origin-Opener-Policy: same-origin 和 Cross-Origin-Embedder-Policy: require-corp
// 否则SharedArrayBuffer是不可用的，这是出于安全考虑，为了防止Spectre/Meltdown攻击
if (window.Worker && window.SharedArrayBuffer) {
    const buffer = new SharedArrayBuffer(1024); // 创建一个1KB的共享缓冲区
    const view = new Int32Array(buffer); // 创建一个32位整数视图

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

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

    // 主线程也可以操作这块内存
    Atomics.add(view, 0, 10); // 初始值加10

    // 等待一段时间，让worker有机会执行
    setTimeout(() => {
        console.log('最终共享内存的值:', Atomics.load(view, 0));
    }, 100);
}

// worker1.js
self.onmessage = function(e) {
    const view = new Int32Array(e.data.buffer);
    const workerId = e.data.id;
    console.log(`Worker ${workerId} 初始值:`, Atomics.load(view, 0));
    Atomics.add(view, 0, 5); // 加5
    console.log(`Worker ${workerId} 修改后值:`, Atomics.load(view, 0));
};

// worker2.js
self.onmessage = function(e) {
    const view = new Int32Array(e.data.buffer);
    const workerId = e.data.id;
    console.log(`Worker ${workerId} 初始值:`, Atomics.load(view, 0));
    Atomics.add(view, 0, 7); // 加7
    console.log(`Worker ${workerId} 修改后值:`, Atomics.load(view, 0));
};

使用SharedArrayBuffer和Atomics让JS的并发能力提升了一个档次，但它也带来了更高的复杂性，你需要非常小心地管理共享状态，否则很容易引入难以调试的并发bug。这也是为什么它最初因为安全漏洞被禁用，后来才重新启用，但需要特定的HTTP头来启用跨域隔离环境。

什么时候应该考虑使用Web Workers？

这问题其实挺关键的，不是所有场景都适合用Web Workers。我个人觉得，当你遇到以下情况时，可以认真考虑一下：

CPU密集型计算：比如大型数据集的排序、复杂的图像处理（滤镜、压缩）、视频编解码、加密解密、科学计算等。这些任务如果放在主线程，会直接导致页面卡死，用户体验极差。
大数据量处理：当你需要解析或处理一个几MB甚至几十MB的JSON文件或CSV文件时，直接在主线程操作可能会阻塞UI。Web Workers可以把这些数据加载和解析的工作放到后台完成。
长时间运行的任务：有些后台任务可能需要持续运行一段时间，比如实时数据流的处理、复杂的动画计算（虽然大部分动画都在主线程，但如果计算量大到影响帧率，可以考虑拆分）。

反之，如果你的任务是频繁地操作DOM、更新UI，或者只是简单的网络请求（因为网络请求本身就是异步非阻塞的），那么使用Web Workers反而会增加不必要的复杂性。毕竟，Worker和主线程之间的通信也是有开销的，如果任务本身耗时很短，这点开销可能就抵消了并行带来的好处。所以，得权衡一下复杂性和实际的性能提升。有时候，简单的异步回调或者Promise链就足够了，没必要引入Web Workers。

到这里，我们也就讲完了《JS多线程计算实现方式详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！