浏览器中的事件循环机制 Event Loop

网上一搜事件循环，很多文章标题的前面会加上 JavaScript，但是我觉得事件循环机制跟 JavaScript 没什么关系，JavaScript 只是一门解释型语言，方便开发和理解的，由V8 JIT 将 JavaScript 编译成机器语言来调用底层，至于浏览器怎么执行 JavaScript 代码，JavaScript 管不着也不关心，因此 JavaScript 事件循环机制这种说法是不合理的，事件循环机制是由运行时环境实现的，具体来说有浏览器、Node 等，这篇文章就先来说说浏览器中实现的事件循环机制。

正文

首先 JavaScript 在浏览器端运行是单线程的，这是由浏览器决定的，这是为了避免多线程执行不同任务会发生冲突的情况。也就是说我们写的 JavaScript 代码只在一个线程上运行，称之为主线程（HTML5 提供了 web worker API 可以让浏览器开一个线程运行比较复杂耗时的 JavaScript任务，但是这个线程仍受主线程的控制）。单线程的话，如果我们做一些 sleep 的操作比如说：

var now = + newDate()
while (+newDate() <= now + 1000){
//这是一个耗时的操所
}

那么在这将近一秒内，线程就会被阻塞，无法继续执行下面的任务。

还有些操作比如说获取远程数据、I/O 操作等，他们都很耗时，如果采用同步的方式，那么进程在执行这些操作时就会因为耗时而等待，就像上面那样，下面的任务也只能等待，这样效率并不高。

那浏览器是怎么做的呢?

我们找到 WHATWG 规范对 Event loop(link:https://html.spec.whatwg.org/multipage/webappapis.html#event-loops) 的介绍，为了协调事件，用户交互，脚本，渲染，网络等，用户代理必须使用事件循环。

事件循环的主要机制就是任务队列机制:

• 一个事件循环有一个或者多个 任务队列（task queues）。任务队列是 task 的有序列表，task 是调度 Events，Parsing，Callbacks，Using a resource，Reacting to DOM manipulation 这些任务的算法;
• 每个任务都来自一个特定的 任务源（task source）（比如鼠标键盘事件）。来自同一个特定任务源且属于特定事件循环的任务必须被加入到同一个任务队列中，来自不同任务源的任务可以放在不同的任务队列中;
• 浏览器调用这些队列中的任务时采取这样的做法：相同队列中的任务按照先进先出的顺序, 不同的队列按照提前设置的队列优先级来调用，例如用户代理可以有一个用于鼠标和键盘事件的任务队列（用户交互任务源），另一个用于其他任务。然后用户代理 75% 概率调用键盘和鼠标事件任务队列，25% 调用其他队列，这样的话就保持界面响应而且不会饿死其他任务队列，但是相同队列中的任务要按照先进先出的顺序。也就是说单独的任务队列中的任务总是按先进先出的顺序执行，但是不保证多个任务队列中的任务优先级，具体实现可能会交叉执行

在调用任务的过程中，会产生新的任务，浏览器就会不断执行任务，因此称为事件循环.

microtask queue 微任务队列

还有一些特殊任务，它们不会被放在 task queues 中，会放在一个叫做 microtask（微任务）queue 中，继续看标准：

Each event loop(link:https://html.spec.whatwg.org/multipage/webappapis.html#event-loop) has a microtask queue. A microtask is a task(link:https://html.spec.whatwg.org/multipage/webappapis.html#concept-task) that is originally to be queued on the microtask queue(link:https://html.spec.whatwg.org/multipage/webappapis.html#microtask-queue) rather than a task queue(link:https://html.spec.whatwg.org/multipage/webappapis.html#task-queue).

任务队列可以有多个，但是微任务队列只有一个。

那么哪些任务是放在 task queue，哪些放在 microtask queue 呢？通常对浏览器和 Node.js 来说：

• macrotask(宏任务)：script（整体代码）、 setTimeout、setInterval、setImmediate、I/O、UI rendering 等
• microtask(微任务)：process.nextTick、Promises（这里指浏览器实现的原生 Promise）、Object.observe、MutationObserver 等

请尤其注意 macrotask 中执行整体代码也是一个宏任务

事件循环处理过程

总体来说, 浏览器端事件循环的一个回合（go-around 或者叫 cycle）就是：

• 从 macrotask 队列中（task queue）取一个宏任务执行，执行完后，取出所有的 microtask 执行。
• 重复回合

无论在执行 macrotask 还是 microtask，都有可能产生新的 macrotask 或者 microtask，就这样继续执行。

用任务队列机制解释异步操作顺序

这里有一些常见异步操作：

const interval = setInterval(() => {
  console.log('setInterval')
}, 0)

setTimeout(() => {  
  console.log('setTimeout 1')
  Promise.resolve().then(() => {
    console.log('promise 3')
  }).then(() => {
    console.log('promise 4')
  }).then(() => {
    setTimeout(() => {
      console.log('setTimeout 2')
      Promise.resolve().then(() => {
        console.log('promise 5')
      }).then(() => {
        console.log('promise 6')
      }).then(() => {
      	clearInterval(interval)
      })
    }, 0)
  })
}, 0)

Promise.resolve().then(() => {
  console.log('promise 1')
}).then(() => {
  console.log('promise 2')
})

结果 Chrome 63.0.3239.84; Mac OS：

promise 1
promise 2
setInterval
setTimeout 1
promise 3
promise 4
setInterval // 大部分情况下2次, 少数情况下一次
setTimeout 2
promise 5
promise 6

这个顺序是如何得来的？

我们先讲 promise 4 后面只出现一次 setInterval 的情况。

注意：本图为了方便把各时间段（Cycle）队列的任务都画在队列中去了，实际上执行一个 task 和 microtask 后就会把这个任务从相应队列中删除。

首先主任务就是执行脚本，也就是执行上述代码，这也是一个 task，在执行代码过程中，遇到 setTimeout、setInterval 就会将回调函数添加到 task queue 中，遇到 promise 就会将 then 回调添加到 microtask 中去。

Task 执行完，接着取所有 microtask 执行，所有 microtask 执行完了，microtask queue 也就空了，接着再取 task 执行，如果 microtask queue 为空，没有任务，则继续取下一个 task 执行，就这样循环执行，图中箭头就表示执行的顺序。

那么为什么 promise 4 后面大部分情况下出现2次 setInterval，少数情况出现 1 次呢？

我猜测这是因为 setInterval 是有最短间隔时间的（chrome 下 4ms 左右），这个时间不同机子、不同浏览器都有可能不一样，代码中的参数是 0，意味着尽可能短的时间内就会产生一个 task 加入到 task queue 中，浏览器在执行 setInterval 后到执行下一个 task 前，时间间隔就可能超过这个最短时间，因此会产生一个 setInterval task。

我是这样论证的：

我把含有 promise5、promise6 回调函数的 setTimeout 的时间设置大一点，让它推迟插入 task queue 中：

...  
setTimeout(() => {
      console.log('setTimeout 2')
      Promise.resolve().then(() => {
        console.log('promise 5')
      }).then(() => {
        console.log('promise 6')
      }).then(() => {
      	clearInterval(interval)
      })
}, 10)   //这里加上10ms 
...

结果是 promise 4 后面的 setInterval 出现了5次，因此我觉得 promise 4 后面大部分情况下出现2次 setInterval、少数情况出现一次的原因就是浏览器在执行 setInterval 回调函数后、执行 setTimeout 回调函数前，时间间隔大部分情况超过了这个最短时间。

另外我试着再依次加上 1ms，直到 14ms——也就是加上 4ms 时，promise 4 后面的 setInterval 变成了6次，可以认为 setInterval 最短间隔时间在 Chrome 下约为 4ms（不考虑机子性能、设置）。

Node 中的奇怪结果

首先说明一下，在 Node 中也体现了任务队列的机制，但是这不是 Node 实现的，这是 V8 实现的，由 Node 调用了 V8 任务队列机制的 API，至于为什么是 V8 实现的，我们翻翻 ECMA 262(link:https://www.ecma-international.org/ecma-262/#sec-jobs-and-job-queues) 标准对 Job 和 Job queue 的介绍就可以得知。

但是让人摸不着头脑的是，这段代码在 node v8.5.0 下有时会出现这样的结果：

promise 1
promise 2
setInterval
setTimeout 1
promise 3
promise 4
setInterval
setTimeout 2
setInterval   // 为什么会出现setInterval???
promise 5
promise 6

按理说应该是 setTimeout 2 => promise 5 => promise 6，因为输出 setTimeout 2 的回调函数是 task，执行完这个 task 后应该调用 microtask 输出 promise 5 => promise 6 啊？很奇怪！Node 对 V8 确实有些改动，不知道是不是这方面原因。