JavaScript通过Web Workers实现类似多线程计算的效果，利用后台线程执行耗时任务而不阻塞主线程，结合SharedArrayBuffer与Atomics可实现高效数据共享与同步，适用于CPU密集型或大数据量处理场景。
JavaScript本身在主线程是单线程运行的，这意味着它一次只能执行一个任务。但要实现类似“多线程计算”的效果，我们通常会利用Web Workers。它们允许你在后台线程中运行脚本，而不会阻塞主线程，从而保持用户界面的响应性。这并不是传统意义上的共享内存多线程，更像是一种并发机制，通过消息传递来协作。
JS要实现多线程计算，核心在于使用Web Workers。这东西就像是给你的浏览器页面开了几个“小助手”，每个助手都能独立地处理一些计算任务，而不会让你的主界面卡住。它不是那种c++或Java里线程共享内存的模式，而是每个Worker都有自己独立的环境，它们之间通过发送消息来沟通。
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。
