深入理解 JavaScript 中的并行处理：Web Worker 实战指南

前言

多线程机制在现代编程中至关重要。传统上，通过派生线程可以在单一进程内划分任务。操作系统负责调度时间片，高优先级或计算密集型的任务能获取更多时间片，而低优先级或空闲线程则分配较少资源。

尽管多线程价值显著，原生 JavaScript 并不直接支持多线程。Web Worker 的普及使得在后台线程执行资源密集型计算成为可能。然而，当前标准主要局限于现有生态系统，相较于其他原生支持多线程的语言，其限制较多，并非简单实例化线程即可实现完整的多线程控制。

本文将重点介绍 Web Worker 的使用场景、具体实现方式、特殊行为，以及在 Webpack 环境下的集成方法，并探讨开发过程中可能遇到的常见问题。

Web Workers 基础与通信

一、Web Workers

Web Worker 是目前 JavaScript 中实现真正多线程的唯一途径。创建 Worker 的基本方式如下：

const worker = newWorker("worker.js");

上述代码定义了一个 Worker 实例。通过 postMessage 方法可与 Worker 进行通信，这与操作 iFrame 类似，但无需处理跨域验证问题。

worker.postMessage(num);

在 Worker 脚本中，需要监听以下事件：

onmessage = (e) => {
 // e.data will contain the value passed
};

这种通信是双向的，因此也可以从 Worker 向主程序发送 postMessage。

Worker 端代码示例：

postMessage(result);

主程序端代码示例：

worker.onmessage = (e) => {}

以上即为 Worker 的最基本用法。

异常处理与资源回收

异常处理

在 Worker 代码中处理异常有多种方式。例如，可以在 catch 块中通过 postMessage 传递错误信息。虽然这会增加代码量，但这是最有效且安全的处理方式。

另一种方式是使用 onerror 事件，该事件可捕获所有未处理的异常，并将处理权交给调用方。调用方式如下：

worker.onerror = (e) => {};

为了便于调试，异常对象包含额外字段，如 filename、lineno 和 colno。

资源回收

及时回收不再需要的 Worker 至关重要，因为它们会生成真实的操作系统线程。若同时运行过多 Worker，可能导致浏览器进程崩溃。

销毁 Worker 有两种方式：在 Worker 内部或外部。通常建议在主页面中管理 Worker 的生命周期，但具体取决于代码逻辑。

在外部销毁 Worker 实例时，可直接调用 terminate() 方法。该方法会立即终止 Worker 并释放其占用的所有资源，即使其正在运行任务也会被强制停止。

若希望 Worker 自主管理生命周期，可在 Worker 代码中直接调用 stop() 方法。

无论采用哪种方式，Worker 都会停止运行并销毁所有相关资源。

对于“一次性” Worker（如执行复杂运算后不再使用），务必在 onerror 事件中销毁它们，以避免潜在的资源泄漏或难以排查的问题。

worker.onerror = (e) => {
 worker.terminate();
 reject(e);
};
worker.onmessage = (e) => {
 worker.terminate();
 resolve(e.data);
}

行内与嵌套 Worker

二、行内 Workers

有时将 Worker 代码写入外部文件会使简单问题复杂化。幸运的是，Worker 可以通过 Blob 初始化，实现行内嵌入。

创建行内 Worker 的参考代码如下：

<!-- http://stackoverflow.com/a/6454685/2032154 -->
<script id="worker" type="javascript/worker">
 // Put your worker code here
</script>
const code = URL.createObjectURL(new Blob([
 document.getElementById("worker").textContent
]));
const worker = new Worker(code);

这样便创建了一个全局的 ObjectURL。但请注意，在不再需要时应及时销毁它：

worker.terminate();
URL.revokeObjectURL(code);

三、Workers 嵌套

理论上，可以像在主线程中定义 Worker 一样嵌套使用 Worker。虽然存在简单示例，但 Chrome 浏览器中一直存在相关 Bug，导致功能无法正常使用。尽管未来可能修复，但目前建议避免使用嵌套 Worker。

数据传递与性能优化

数据传递

Worker 间数据传递需注意一些边缘情况。可以传递数值、字符串、数组以及序列化/反序列化的对象。然而，不应依赖序列化来保持数据结构，因为 postMessage 使用了特定的数据克隆算法，可能会生成额外属性（如 RegExps 和 Blobs）或处理循环引用。

因此，应尽量减少传递的数据量。无法传递函数，即使支持传递的类型也存在限制，容易引发难以发现的 Bug。若 API 设计为仅传递字符串、数值、数组和对象，可有效规避此类问题。

循环引用

若对象存在复杂的循环引用，尝试将其序列化为 JSON 时，将会得到 TypeError: Converting circular structure to JSON.。

let a = {};
let b = {a};
a.b = b;
JSON.stringify({a,b}); // Error

然而，在 postMessage 中传递此类对象是安全的，因此可以在 Worker 中正常使用。

Transferable objects

为防止多线程同时修改同一变量，传递给 postMessage 的变量会被复制一份，确保多个线程不会修改同一数据。但若传递大型数据（如图片信息），复制操作会导致性能瓶颈。

为此，可以使用 transferable object ，通过 transfer 代替 copy。例如，ArrayBuffer 是 transferable 对象，可将任意类型数据放入 ArrayBuffer 中。

若 transfer 一个对象，原拥有线程将被锁定权限，确保在数据复制完成前不会被同时修改。

此时 postMessage 的代码段如下：

const ab = new ArrayBuffer(100);
console.log(ab.byteLength); // 100
worker.postMessage(ab, [ab]);
console.log(ab.byteLength); // 0

务必在 postMessage 中传递第二个参数，否则数据将被复制而非转移。

const ab = new ArrayBuffer(100);
console.log(ab.byteLength); // 100
worker.postMessage(ab);
console.log(ab.byteLength); // 100

Webpack 集成与注意事项

四、Webpack

在 Webpack 中使用 Web Worker 时，需使用 worker-loader。将其添加到 package.json 的 devDependencies 中，然后运行 npm install 即可。

使用 Worker 时，只需通过 require 引入。

const workerCode = require("worker!./worker.js");
...
const worker = new workerCode();

这样即可初始化 Worker，并按前述方式正常使用。

若需使用行内 Worker，需向 loader 传递 inline 参数。

const workerCode = require("worker?inline!./worker.js");
...
const worker = new workerCode();

在 Worker 中也可 import 模块。

import fibonacci from "./fibonacci.js";
...
const result = fibonacci(num);

缺点

在 Webpack 中使用 Worker 虽简单，但仍有一些需要注意的坑。

首先，无法提取共用代码。若 Worker 依赖共用代码，必须将其复制到 Worker 中，即使其他部分也使用相同代码。若多个 Worker 使用同一库，也需在每个 Worker 中单独引入。

有人可能尝试不使用 worker-loader，而是通过 CommonsChunkPlugin 指定新入口来解决此问题。但遗憾的是，Worker 并非浏览器 window，部分功能不可用，因此仍需引入特定代码。

此外，使用行内 Worker 也无法解决共用代码问题，共用代码仍会出现在多个位置。

第二点缺点是，行内 Worker 可能导致 ObjectURLs 内存泄露。这些 URL 创建后不会被自动释放。虽然通常不是大问题，但若大量使用“一次性” Worker，将影响性能。

综上所述，建议优先使用标准 Worker，并注意引入的内容。同时，注意使用缓存机制。

IFrames Web Worker 局限性

五、IFrames Web worker

IFrames Web Worker 与 IFrame 类似，印象中 IFrame 也可实现多线程。但 IFrame 存在非线程安全的 API（如 DOM 相关操作），浏览器无法为其生成新线程，参考此处。

在 IFrame 跨域场景中，许多 API 无权限，只能通过 postMessage 通信，这与 Web Worker 类似。理论上，浏览器可在不同线程中运行 IFrame，从而实现多线程。

但实际情况并非如此，IFrame 仍为单线程，浏览器不会为其分配额外线程。

总结

Web Worker 解决了 JavaScript 长期存在的多线程难题。尽管其语法奇特且限制众多，却能真正解决问题。另一方面，该技术尚不成熟，部分功能未完全稳定，尚不能完全依赖，普及仍需时日，适用场景也较为有限。因此，若需实现多线程，无需等待其他技术，掌握 Web Worker 的边缘问题并避开陷阱，即可显著提升用户体验。以上就是这篇文章的全部内容，希望对大家能有所帮助。