事件循环和消息队列（二）

前言

上篇文章中介绍了多进程的浏览器基本架构，现在，我们来谈谈单线程的 JS 代码、消息队列、事件循环、微任务和宏任务。

单线程的 JavaScript

JS 代码运行在哪里？

如果你已经仔细阅读过上一篇文章，那么答案是显而易见的：由于浏览器是由渲染进程的主线程来执行 js 代码的，换句话说，js的运行位置是渲染进程的主线程，所以 js 自然而然就是单线程的。

js 为什么设计成单线程的？

这个问题的答案同样在上一篇文章中有所体现。浏览器中的js执行和页面渲染是在同一个线程中发生的，主线程在解析HTML生成DOM树的过程中，如果遇到<script>标签会先执行js代码而阻塞对HTML的解析，因为 js 能够修改DOM进而影响渲染结果。但如果 js 可以拥有多个线程来执行，那么会出现一边解析HTML进行渲染，一边执行的 js 代码操作 DOM ，这样会影响到页面最终渲染效果的一致性（可预见性）。

同步任务和异步任务

同步任务：按顺序执行的js代码，上一个任务结束才能执行下一个任务，主线程中只执行同步任务。
异步任务：不进入主线程执行，而是由宿主环境提供的线程执行。当异步任务完成时，会在消息队列中添加异步任务的回调函数。

消息队列

此时，你可能会有疑问：既然 JS 是单线程的，而异步任务又不是在主线程中执行的，这不是矛盾了吗？实际上，JS的确是单线程，但他的宿主环境（浏览器，Node.js）可不是单线程的，js中一些耗时的任务，可以交由宿主环境的其他线程来执行，但这与多线程语言可以开启多个线程并行执行任务并不相同。

让我们来看看异步任务执行时发生了什么。假设js代码发出了一个异步 http 请求，此时由IO线程来接管执行http请求的代码，主线程将异步任务挂起，并继续执行接下来的同步代码，当IO线程接收到了服务器发来的响应，便将异步任务的回调加入到消息队列的队尾。

消息队列（任务队列）是在主线程之外的数据结构，每当有异步任务完成，那么他的回调函数（callback）就会被push到消息队列的队尾。主线程中所有同步任务执行完之后，由事件循环来通知主线程开始执行消息队列中的任务。

事件循环（Event Loop）

简单的说，事件循环起到通知主线程该执行异步任务回调的作用。

在浏览器源码中，可以看到在最开始的时候，渲染主线程会进入一个无限循环
每一次循环会检查消息队列中是否有任务存在。如果有，就取出第一个任务执行，执行完一个后进入下一次循环；如果没有，则进入休眠状态。
其他所有线程（包括其他进程的线程）可以随时向消息队列添加任务。新任务会加到消息队列的末尾。在添加新任务时，如果主线程是休眠状态，则会将其唤醒以继续循环拿取任务

这样一来，就可以让每个异步任务有条不紊的、持续的进行下去了。

整个过程，被称之为事件循环（在chrome源码中称为消息循环）

任务的优先级

任务没有优先级，在消息队列中先进先出

但消息队列是有优先级的

根据 W3C 的最新解释:

每个任务都有一个任务类型，同一个类型的任务必须在一个队列，不同类型的任务可以分属于不同的队列。
在一次事件循环中，浏览器可以根据实际情况从不同的队列中取出任务执行。
浏览器必须准备好一个微队列，微队列中的任务优先所有其他任务执行
https://html.spec.whatwg.org/multipage/webappapis.html#perform-a-microtask-checkpoint

随着浏览器的复杂度急剧提升，W3C 不再使用宏队列的说法

在目前 chrome 的实现中，至少包含了下面的队列：