在前端开发领域,JavaScript 的单线程限制一直是一个难以忽视的挑战。当谈到解决JavaScript的单线程限制时,HTML5引入的Web Worker被普遍认为是一剂解药。同时,业界中大量的文章也是聚焦于讨论web worker的神奇力量。然而,本文将另辟蹊径,和您一同探索Web Worker神秘的另一面。
js的一大特点就是单线程。对于单线程,一句最经典的概述就是“同一时间只能执行一个任务”。
在JavaScript设计之初,其单线程模型是由其主要用途和初衷所决定的。JavaScript作为一门浏览器端的脚本语言,最初的主要任务是处理用户交互。设想一下,如果JavaScript被设计为多线程,那么在用户交互中进行多线程同步操作DOM,为了保证准确性必然会引发竞态分配等复杂问题。另外,对于客户端来说也可能引发性能和资源消耗等多种复杂问题,这时的多线程在这个背景下反而显得过于臃肿。
随着Web技术的不断演进,JavaScript的单线程模型已经无法满足日益复杂的业务需求和以及带来的性能要求。为了解决这些问题,JavaScript引入了一些如ajax
、setTimeout
、requestAnimationFrame
等机制,但需要明确的是,这些机制不过是通过EventLoop
来制造的多线程假象,其并没有改变JavaScript单线程的本质。
至今,现代Web应用中用户交互变得越来越复杂,以及数据处理需求的增加,JavaScript应用需要更强的计算能力和更快的响应性,单线程模型面临着着挑战愈发严重。这就引出了一个关键问题:如何在保持JavaScript的单线程特性的同时,充分利用多核处理器来提高性能以满足用户的需求?在这样的背景下,Web Worker技术应运而生。
或许在您的项目中尚未使用过Web Worker,但实际上它已经存在了很长时间。早在2009年
,W3C便提出了 Web Worker 草案,2011年
正式称为HTML5标准的一部分。
W3C对Web Worker的定义如下:
an API for running scripts in the background independently of any user interface scripts.
// 主线程代码
const worker = new Worker('worker.js');
worker.postMessage('Hello from the main thread!');
worker.onmessage = (event) => {
console.log('Message from Web Worker:', event.data);
};
// worker.js
self.onmessage = (event) => {
console.log('Message from main thread:', event.data);
self.postMessage('Hello from the Web Worker!');
};
除了专用worker类型(Dedicated Web Worker),还有两种特殊的 Web Worker:SharedWorer和ServiceWorker。
sharedWorker兼容性:
Web Worker与主线程相互独立,可以在不影响主线程性能的情况下执行一些耗时操作而不会阻塞主线程,特别是在处理复杂任务和长时间运行的操作时非常有用。它的主要优势如下:
在实际项目中,Web Worker更适合处理以下场景:
兼容性问题:尽管HTML5已经普及,但Web Worker在大多数厂商的浏览器中仅在最新的大版本中支持,在旧版本中支持并不好。这导致开发者在实际项目中可能会放弃使用Web Worker。
资源限制:无法直接访问DOM、同源策略、无法读取本地文件等等。
编程复杂性:使用Web Worker需要处理线程间的通信,这增加了编程的复杂性。对于简单的任务使用Web Worker可能并不划算。
安全性问题:因Web Worker是在后台运行的多线程,所以更隐蔽,由此也带来了新的安全问题:如恶意脚本的注入以利用Web Worker大规模执行多线程攻击来放大攻击效果、恶意创建大量web worker并让它们执行高负载的任务而导致浏览器崩溃、importScripts没有跨域限制可能会加载不受信任的脚本从而导致安全漏洞等等。
除了以上局限性,Web Worker的通信效率问题也是值得注意的一点。
无法共享内存: 与传统多线程编程不同,Web Worker不能直接共享内存,主页面与worker之间的数据传递的是通过拷贝
而不是共享来完成的。因此在如大文件传输场景下可能会消耗大量内存和处理时间。
数据序列化问题: 当主线程与Web Worker之间在数据交换时需要对数据进行序列化和反序列化,序列化会阻塞发送方,而反序列化会阻塞接收方
。因此即使是小型数据,也需要经过这一过程。这可能在频繁通信的情况下积累成为性能瓶颈。
postMessage:postMessage
方法本身并不是导致通信效率低下的主要原因,而是由于如Worker线程需要频繁地向主线程发送大量消息,或者消息体积较大等其他因素造成。这可能会导致主线程处理消息的速度跟不上Worker线程发送消息的速度,从而引起通信拥塞和性能问题。
主线程Web Worker数据传输数据传输postMessage(data)onmessage(event)序列化数据发送序列化数据反序列化数据postMessage(replyData)序列化回复数据发送序列化回复数据反序列化回复数据主线程Web Worker
由于通信效率的限制,Web Worker不适用于实时任务
。由于消息传递的开销和可能的网络延迟,Web Worker无法保证实时性。因此,对于在线游戏、视频会议等一些需要实时响应场景,使用Web Worker可能不是最佳选择。
在 MDN 的web worker的”线程安全“一节中提到:
“The Worker interface spawns real OS-level threads”
。
从底层技术角度来看,Web Worker确实具备多线程的特性。然而这与传统多线程编程语言(如Java或C++)有所不同。如,JavaScript中的主线程与Web Worker之间采用的是消息传递来通信,而不是直接共享内存。这意味着Web Worker之间无法直接共享数据,而传统多线程语言则可以直接共享内存,从而实现更直接和高效的线程间通信。
尽管Web Worker从底层技术上看具备多线程的特性,但如今JavaScript的主要应用领域仍然是处理用户界面和用户交互,Web Worker的引入主要是为了改善前端应用的响应性,使其能够更好地处理一些计算密集型任务,而不是将JavaScript彻底转变为多线程编程语言。
总结而言,尽管Web Worker API为JavaScript提供了一定程度的多线程支持,但JavaScript仍然是一门主要依赖于单线程执行的编程语言,Web Worker并没有改变JavaScript的单线程本质。
未来的js多线程应该具有更好的性能、更好的响应性以及更多的并行计算能力,随着Web技术不断发展,多线程前景越发广阔。如:
综上所述,Web Worker作为一种在前端开发中多线程的工具,的确有其独特的优势。然而,我们必须明白,尽管它被广泛视为解决JavaScript单线程问题的一种方式,但它并没有从根本上改变JavaScript的单线程本质。在使用Web Worker时,我们仍然需要面对资源限制、通信开销以及安全性等问题。因此,可以说Web Worker是一种”伪解药“。它有助于缓解JavaScript单线程的限制,但并非银弹。在未来,我们期待JavaScript多线程领域的进一步发展,以实现Web能力的持续提升!
原文链接:https://juejin.cn/post/7274146202496565306