JS多线程实现方法详解

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《JS如何实现多线程？》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

JavaScript是单线程的，但可通过Web Workers、Service Workers和SharedArrayBuffer配合Atomics实现类似多线程的并发效果，1. Web Workers用于在后台线程执行耗时任务，通过postMessage与主线程通信，避免阻塞UI；2. Service Workers主要用于网络代理、离线缓存等，运行在独立线程中；3. SharedArrayBuffer允许多个线程共享内存，配合Atomics的原子操作实现线程安全的数据同步，适用于高性能计算场景，但需注意其使用受跨域隔离策略限制。

JavaScript 本身是单线程的，这确实是它的一个核心特性，意味着同一时间只能执行一个任务。但要说它完全不能实现“多线程”或者并发操作，那也不尽然。我们通常会通过一些机制来模拟或实现类似多线程的效果，比如 Web Workers、Service Workers，以及更底层的 SharedArrayBuffer 配合 Atomics，这些都能让一些耗时任务在后台运行，不阻塞主线程，从而提升用户体验和应用性能。

解决方案

当我们需要在 JavaScript 中处理大量计算、数据处理或者其他可能导致 UI 卡顿的任务时，将这些工作从主线程中剥离出去是关键。最直接且广泛使用的方案就是利用 Web Workers。它们提供了一个在后台运行脚本的方式，与主线程完全隔离，拥有独立的全局环境，但无法直接访问 DOM。数据通过 postMessage 传递，这种序列化和反序列化的过程虽然有开销，但对于复杂的、CPU 密集型任务来说，收益远大于成本。

举个例子，假设你正在处理一个大型图片的像素级操作，或者进行复杂的加密解密：

主线程 (main.js):

// 创建一个 Worker
const myWorker = new Worker('worker.js');

// 向 Worker 发送数据
const imageData = new Uint8ClArray(1000000); // 假设这是图片数据
myWorker.postMessage(imageData, [imageData.buffer]); // 转移所有权，提高效率

// 监听 Worker 的消息
myWorker.onmessage = function(e) {
    console.log('主线程收到 Worker 消息:', e.data);
    // 更新 UI 或进行后续操作
};

// 监听 Worker 错误
myWorker.onerror = function(error) {
    console.error('Worker 发生错误:', error);
};

// 偶尔也可以给 Worker 发送指令
// myWorker.postMessage({ command: 'stop' });

Worker 线程 (worker.js):

// 监听主线程发送的消息
self.onmessage = function(e) {
    console.log('Worker 收到主线程消息:', e.data);
    const receivedData = e.data;

    // 假设这里进行大量计算
    let result = 0;
    for (let i = 0; i < receivedData.length; i++) {
        result += receivedData[i];
    }

    // 将结果发送回主线程
    self.postMessage('计算完成，结果是: ' + result);
};

// 可以在 Worker 中处理错误
// throw new Error('Worker 内部错误');

除了 Web Workers，Service Workers 也是在后台运行的，它们主要用于实现离线缓存、网络请求拦截和推送通知等功能。虽然它们也运行在独立的线程中，但其设计目的和应用场景与 Web Workers 有所不同，更侧重于网络代理和持久化能力。

而如果你需要多个线程（Workers）之间共享内存并进行高效的同步，那就得用到 SharedArrayBuffer 和 Atomics。这是一种更接近传统多线程共享内存模型的方式，它允许不同的 Worker 访问同一个内存区域，并通过 Atomics 对象提供的原子操作来确保数据的一致性和线程安全。这玩意儿在性能敏感的场景下，比如 WebAssembly 模块的多线程执行，或者需要大量数据共享的并行计算中，表现得尤为出色。

Web Workers 的实际应用场景和注意事项

Web Workers 真的很适合那些“我需要计算，但不想让浏览器卡住”的场景。想象一下，你正在开发一个复杂的在线数据可视化工具，用户上传了一个巨大的 CSV 文件，你需要解析它、进行复杂的统计分析，然后才能渲染图表。如果这些操作都在主线程进行，用户会看到页面直接“死掉”几秒甚至几十秒，这体验简直灾难。这时候，把文件解析和数据处理扔给一个 Web Worker 去干，主线程只负责显示一个加载动画，等 Worker 处理完了再把结果传回来，页面始终是响应的。

再比如，一些基于 WebGL 的复杂 3D 渲染应用，或者在线视频编辑工具，它们需要处理大量的像素数据、帧数据，这些计算量都非常庞大。将这些计算密集型任务卸载到 Web Worker，能显著提升应用的流畅度。我甚至见过有人用 Web Workers 来实现客户端的区块链挖矿模拟，虽然实用性存疑，但确实展示了其强大的计算卸载能力。

不过，使用 Web Workers 也有一些限制和注意事项。最明显的就是它们无法直接操作 DOM。这意味着如果你想让 Worker 计算完数据后直接更新页面上的某个元素，那是不可能的。Worker 只能把计算结果通过 postMessage 传回主线程，然后由主线程来负责 DOM 的更新。另外，Worker 之间的通信以及 Worker 与主线程之间的通信都是通过消息传递机制进行的，传递的数据会被序列化和反序列化。对于小数据量，这开销几乎可以忽略不计，但如果频繁传递大量数据，这个过程本身也会成为性能瓶颈。这时，transferable objects（可转移对象，如 ArrayBuffer）就显得尤为重要，它允许你将数据的所有权从一个线程转移到另一个线程，避免了复制，大幅提升了传输效率。还有一点，Worker 的调试相对来说会稍微麻烦一点，因为它们运行在独立的上下文里。

SharedArrayBuffer 和 Atomics 如何实现高效数据共享与同步？

SharedArrayBuffer 和 Atomics 的组合，可以说是在 JavaScript 中实现“真·多线程”共享内存的关键。它不像 postMessage 那样复制数据，而是直接提供了一块内存区域，这块区域可以被多个 Worker 线程同时访问。这有点像 C/C++ 里的共享内存段，多个进程可以映射同一块物理内存。

具体来说，SharedArrayBuffer 创建的缓冲区，其内容可以在多个 Worker 之间共享。但仅仅共享内存还不够，因为多个线程同时读写同一块内存区域时，很容易出现数据竞争（race condition）的问题，导致数据不一致。这时，Atomics 对象就登场了，它提供了一系列原子操作（atomic operations）。所谓原子操作，就是指这些操作是不可中断的，要么全部完成，要么全部不完成，不会出现执行到一半被其他线程打断的情况。这确保了在多线程环境下对共享内存的读写操作是安全的。

Atomics 提供了像 Atomics.add()、Atomics.sub()、Atomics.load()、Atomics.store() 等方法，用于对共享内存中的数值进行原子性的增减、读取和写入。更重要的是，它还提供了 Atomics.wait() 和 Atomics.notify() 这两个方法，用于实现线程间的同步和协作。Atomics.wait() 可以让一个 Worker 线程阻塞，直到另一个 Worker 线程通过 Atomics.notify() 发出通知。这对于实现生产者-消费者模型或者复杂的并发算法非常有用。

举个例子，假设我们有多个 Worker 需要共同处理一个共享的计数器：

// 主线程
const sab = new SharedArrayBuffer(4); // 创建一个 4 字节的共享缓冲区
const int32 = new Int32Array(sab); // 在共享缓冲区上创建一个 Int32Array 视图

// 启动两个 Worker
const worker1 = new Worker('worker-shared.js');
const worker2 = new Worker('worker-shared.js');

// 将共享缓冲区发送给 Worker
worker1.postMessage({ buffer: sab, id: 1 });
worker2.postMessage({ buffer: sab, id: 2 });

// 监听 Worker 消息（可选）
worker1.onmessage = e => console.log(`Worker 1 完成: ${e.data}`);
worker2.onmessage = e => console.log(`Worker 2 完成: ${e.data}`);

// 主线程也可以操作共享数据
setTimeout(() => {
    console.log('主线程当前计数:', Atomics.load(int32, 0));
}, 1000);

// worker-shared.js
self.onmessage = function(e) {
    const { buffer, id } = e.data;
    const int32 = new Int32Array(buffer);

    console.log(`Worker ${id} 启动，初始计数:`, Atomics.load(int32, 0));

    // 每个 Worker 对计数器进行 1000 次原子性递增
    for (let i = 0; i < 1000; i++) {
        Atomics.add(int32, 0, 1); // 原子性地将索引 0 处的数值加 1
    }

    console.log(`Worker ${id} 完成，最终计数:`, Atomics.load(int32, 0));
    self.postMessage(`Worker ${id} 递增完成`);
};

这段代码展示了两个 Worker 如何安全地共享和更新同一个计数器，避免了数据竞争。需要注意的是，SharedArrayBuffer 在历史上因为 Spectre/Meltdown 漏洞而一度被禁用，后来在采取了更严格的跨域隔离策略（COOP/COEP HTTP 头）后才重新启用。所以，如果你想在生产环境中使用它，需要确保你的服务器配置了正确的响应头。

什么时候不应该使用 Web Workers？

虽然 Web Workers 听起来很美妙，但它并非万能药，也不是所有场景都适合。

一个很常见的误区是，认为只要是异步操作就应该扔给 Worker。其实不然。如果你的任务本身非常轻量，执行时间极短，那么创建 Worker、初始化、以及消息传递的开销，可能反而比直接在主线程执行还要大。这就像为了拧一个螺丝，你却开来了挖掘机一样，大材小用，效率反而下降。对于简单的异步操作，Promise、setTimeout、requestAnimationFrame 甚至 async/await 已经足够应对，它们在主线程的事件循环中表现得很好。

另一个不适合使用 Worker 的情况是，你的任务需要频繁地直接操作 DOM。就像前面提到的，Worker 无法直接访问 DOM。如果你需要做的事情是频繁地读取元素属性、修改样式或者添加/删除元素，那么 Worker 帮不了你。你必须把这些操作放在主线程。当然，Worker 可以计算出所有需要更新的数据和指令，然后一次性传回主线程，由主线程来执行批量的 DOM 更新，但这依然是主线程在操作 DOM。

再有就是，调试多线程应用本身就比单线程复杂。虽然现代浏览器开发者工具对 Worker 的支持已经很不错了，但相比于直接在主线程上一步步调试，切换上下文、跟踪消息传递依然会增加一些心智负担。如果你的项目对调试效率要求很高，或者团队对多线程开发经验不足，那么在非必要的情况下引入 Worker 可能会带来额外的开发和维护成本。

总的来说，使用 Web Workers 的核心考量是：你的任务是否是 CPU 密集型的？它是否会长时间阻塞主线程导致 UI 卡顿？如果答案是肯定的，那么 Web Worker 绝对是你的利器。如果只是简单的 I/O 操作（比如网络请求），或者轻量级的计算，那么主线程的异步机制往往更简单高效。

以上就是《JS多线程实现方法详解》的详细内容，更多关于的资料请关注golang学习网公众号！