HTML5 Web Worker 中的 JavaScript多线程讲解

JavaScript单线程

JavaScript这门语言运行在浏览器中，是以单线程的方式运行的。说到单线程，就得从操作系统进程开始说起。进程和线程都是操作系统的概念。进程是应用程序的执行实例，每一个进程都是由私有的虚拟地址空间、代码、数据和其它系统资源所组成;进程在运行过程中能够申请创建和使用系统资源(如独立的内存区域等)，这些资源也会随着进程的终止而被销毁。而线程则是进程内的一个独立执行单元，在不同的线程之间是可以共享进程资源的，所以在多线程的情况下，需要特别注意对临界资源的访问控制。在系统创建进程之后就开始启动执行进程的主线程，而进程的生命周期和这个主线程的生命周期一致，主线程的退出也就意味着进程的终止和销毁。主线程是由系统进程所创建的，同时用户也可以自主创建其它线程，这一系列的线程都会并发地运行于同一个进程中。

在多线程操作的情况下可以实现应用的并行处理，而提高整个应用程序的性能和吞吐量，更大粒度的榨取本机的CPU利用率，特别是现代很多语言都支持了多核并行处理技术。然后JavaScript居然还是单线程执行，为什么呢?

这是因为JavaScript这门脚本语言诞生的使命所致：JavaScript为处理页面中用户的交互，以及操作DOM树、CSS样式树来给用户呈现一份动态而丰富的交互体验和服务器逻辑的交互处理。如果JavaScript是多线程的方式来操作这些UI DOM，则可能出现UI操作的冲突;在多线程的交互下，处于UI中的DOM节点就可能成为一个临界资源，假设存在两个线程同时操作一个DOM，而线程1要求浏览器删除DOM节点，线程2却希望修改这个节点的某些样式风格。这个时候浏览器就无法裁决采用哪一种策略了。当然我们可以为浏览器引入“排它锁”或者是“乐观锁”来解决这些冲突，但为了避免引入了更大的复杂性，所以JavaScript从诞生开始就选择了单线程执行。

因为单线程执行，所以对于JavaScript的任务而言，在同一时间内只能执行一个特定的任务，并且它会阻塞其他的任务执行。那么 JavaScript的执行不会很慢吗?特别是对于长时间任务执行的时候，那么其他的任务就得不到执行。然而在软件开发中，特别是应用软件开发中，对于 I/O设备的访问都是一些及其耗时的操作。在这些耗时任务执行的时候，其实并没必要等待它的完成，在I/O任务完成之前JavaScript完全可以继续执行其他的任务，直到I/O任务完成后再继续执行该任务的处理就行。JavaScript在设计之初，就意识这一点。所以在JavaScript中将这些耗时的I/O等操作封装为了异步的方法，等到这些任务完成后就将后续的处理操作封装为JavaScript任务放入执行任务队列中，等待 JavaScript线程空闲的时候被执行。因此这里形成了另一个话题“浏览器的事件循环”机制，将在后续中详细阐述。

因为在JavaScript语言中，和其他大多数语言不一样之处：JavaScript中耗时的I/O操作都被处理为异步操作，以及回调注册机制。异步和回调仿佛和JavaScript就是“与生俱来”的一样。如Nodejs创始人Ryan Dahl所言，JavaScript语言的非阻塞的异步I/O事件驱动模型，以及JavaScript在Chrome推进下的多次性能优化、具有函数式等高级语言特性，因此最终Nodejs选择JavaScript。由于Nodejs最终选择了JavaScript，从此也大大的推动了 JavaScript在非浏览器领域的急速扩展。

下面的文字是来自Nodejs官网：

javascript-简介" src="https://img.111com.net/get_pic/php/upload/image/20151120/1447948999336465.png" />

当然对于非I/O的操作耗时操作如上篇博文《Promise的前世今生和妙用技巧》所说，在HTML5中也提出了新的解决方案，它就是Web Worker。Web Worker就是在当前JavaScript的执行主线程中利用Worker类新开辟一个额外的线程来加载和运行特定的JavaScript文件，这个新的线程和JavaScript的主线程之间并不会互相影响和阻塞执行的;并且在Web Worker中提供这个新线程和JavaScript主线程之间数据交换的接口：postMessage和onMessage事件。但在HTML5 Web Worker中是不能操作DOM的，任何需要操作DOM的任务都需要委托给JavaScript主线程来执行，所以虽然引入HTML5 WebWorker但仍然没有改线JavaScript单线程的本质。对于HTML5的Web Worker和在C# WinForm设计中的BackgroundWorker很类似，对于这类GUI(图形化界面)操作的应用程序中，对于UI界面的操作都需要委托给UI主线程来执行，避免多线程情况下UI操作的安全性和避免不必要的多线程访问控制的复杂度。

浏览器事件循环

在上面已经提到JavaScript中为了不阻塞UI的渲染，很多JavaScript任务都是异步的，它们包括键盘、鼠标I/O输入输出事件、窗口大小的resize事件、定时器(setTimeout、setInterval)事件、Ajax请求网络I/O回调等。当这些异步任务发生的时候，它们将会被放入浏览器的事件任务队列中去。在浏览器内部中存在一个消息循环池，也叫Event Loop(事件循环)，JavaScript引擎在运行时后单线程的处理这些事件任务。例如用户在网页中点击了button事件，则它们会被放入在这个事件循环池中，需要等到JavaScript运行时执行线程空闲时候才会按照队列先进先出的原则被一一执行。对于setTimeout这类定时任务也是一样的，只有当定时时刻达到的时候，它们才会被放入浏览器的事件队列中等待被执行;由于此时的JavaScript主线程也许并不空闲，所以它将并不会被 JavaScript引擎所立即执行，因为在JavaScript语言设计中setTimeout这类定时任务的执行时间并不是精确的。在前端开发中经常会发现setTimeout(func, 0)很有用，因为这并不是立即执行，而是将当前执行回调函数放入浏览器的事件队列中，等待当前其他任务的完成，然后在执行它;所以 setTimeout(func, 0)具有改变当前代码执行顺序的作用，让浏览器有机会完成UI界面渲染等任务后在执行这段回调函数。当然对于老式浏览器这里具有16ms的差距，HTML5规定为4ms，以及关于动画操作中的requestAnimationFrame，请读者参见MDN资料https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame。

浏览器事件循环如下图所示：

虽然JavaScript是单线程执行的，但是浏览器并不是单线程执行的，它们有JavaScript的执行线程、UI节点的渲染线程，图片等资源的加载线程，以及Ajax请求线程等。在Chrome设计中，为了防止因一个Tab window的奔溃而影响整个浏览器，它的每一个Tab被设计为一个进程;在Chrome设计中存在很多的进程，并利用进程间通讯来完成它们之间的同步，因此这也是Chrome快速的法宝之一。对于Ajax的请求也需要特殊线程来执行，当需要发送一个Ajax请求的时候，浏览器会开辟一个新的线程来执行 HTTP的请求，它并不会阻塞JavaScript线程的执行，HTTP请求状态变更事件会被作为回调放入到浏览器的事件队列中等待被执行。

JavaScript多线程之HTML5 Web Worker

在JavaScript中尝试计算像fibonacci这类计算密集型的操作，就会导致整个页面体验被blocked。HTML5 Web Worker的出现让我们在不阻塞当前JavaScript线程的情况下，在当前的JavaScript执行线程中可利用Worker这个类新开辟一个额外的线程来加载和运行特定的JavaScript文件，这个新的线程和JavaScript的主线程之间并不会互相影响和阻塞执行的；并且在Web Worker中提供这个新线程和JavaScript主线程之间数据交换的接口：postMessage和onmessage事件。它和C# WinForm中的BackgroundWorker很类似。

Web Worker实现fibonacci计算

利用HTML5 Web Worker实现fibonacci可像如下所示（plnkr在线demo）：

fibonacci.js Worker JavaScript文件：

(function() {
  var fibonacci = function(n) {
    return n < 2 ? 1 : (fibonacci(n - 1) + fibonacci(n - 2));
  };

  onmessage = function(event) {
    postMessage({
      input: event.data,
      result: fibonacci(event.data)
    });
  };

})();

在fibonacci.js中利用onmessage方法来监听主线程发送的fibonacci计算请求，和利用postMessage返回计算的结果到请求线程。

script.js 主线程JavaScript文件：

$(function() {
  var $input = $('#input'),
    $btn = $('#btn'),
    $result = $('#result'),
    worker = new Worker('fibonacci.js'),
    timeKey = function(val) {
      return 'fibonacci(' + val + ')';
    };

  worker.onmessage = function(event) {
    console.timeEnd(timeKey(event.data.input));
    $result.text(event.data.result);
  };

  $btn.on('click', function() {
    var val = parseInt($input.val(), 10);
    if (val) {
      console.time(timeKey(val));
      $result.text('?')
      worker.postMessage(val);
    }
  });
});

在这个JavaScript文件中，利用new Worker('fibonacci.js')方式来创建Web Worker对象，并利用Worker对象上的postMessage方法发送请求计算请求，以及利用Worker对象的onmessage的方法接受Worker线程的返回结果，并显示在UI界面上。同时我们也利用了console最新的time API来统计计算所花费的时间。

其显示效果如下：

在console中打印的时间信息为：

fibonacci(10): 1.022ms
fibonacci(20): 1.384ms
fibonacci(30): 22.065ms
fibonacci(40): 1744.352ms
fibonacci(50): 202140.027ms

从这里时间输出可以看出，在计算n为40的fibonacci 开始时间开始急速的加长，在UI中返回结果的时间也逐渐变长；但是在Web Worker后台计算的时候，它并不会阻塞我们的UI界面的其他交互。

Web Worker总结

Web Worker在这类耗时计算密集型操作中，显得特别实用。在Web Worker中我们可以实现：

    可以加载一个JS进行大量的复杂计算而不挂起主进程，并通过postMessage，onmessage进行通信；
    可以在worker中通过importScripts(url)加载另外的脚本文件；
    可以使用 setTimeout()，clearTimeout()，setInterval()，clearInterval()；
    可以使用XMLHttpRequest来发送请求，以及访问navigator的部分属性。

但是它也存在一些来自浏览器安全沙盒的限制：

    不能加载跨域的JavaScript文件；
    如文件开始所说，考虑到JavaScript操作DOM的安全性问题，在Web Worker中不能访问界面中的DOM信息，对于DOM的访问操作都必须委托给JavaScript主线程来操作；因此HTML5 Web Worker的出现的出现，并没有改变JavaScript单线程执行的这个事实；
    还有就是Web Worker的浏览器兼容性问题。它的浏览器兼容性图如下：