了解一下 EventLoop

• 浏览器中的 EventLoop
  • Micro-Task 与 Macro-Task
  • EventLoop 过程解析
• Node 中的 Event Loop
  • Node 简介
  • 六个阶段
  • timer 阶段
  • poll 阶段
  • check 阶段
  • setTimeout 和 setImmediate
  • process.nextTick
• Node 与浏览器的 Event Loop 差异
• 总结
• 参考

浏览器中的 EventLoop

Micro-Task 与 Macro-Task

事件循环中的异步队列有两种：macro（宏任务）队列和 micro（微任务）队列，宏任务队列可以有多个，微任务队列只有一个

• 常见的 macro-task 比如：setTimout，setInterval，setImmediate，script（整体代码），I/O 操作，UI 渲染等
• 常见的 micro-task 比如：process.nextTick，new Promise().then(callback)，MutationObserver(html5 新特性)等

每个“线程”都有自己的事件循环，因此每个 Web Worker 都有自己的事件循环，因此它可以独立执行，而同一源上的所有窗口都共享一个事件循环，因为它们可以同步通信。

事件循环持续运行，执行任何排队的任务。

一个事件循环有多个任务源来保证该源中的执行顺序（IndexedDB 等 (opens new window)规范定义了它们自己的），但是浏览器可以在循环的每一轮中选择从哪个源中获取任务。 这允许浏览器优先处理性能敏感的任务，例如用户输入。

任务是经过调度的，因此浏览器可以从其内部进入 JavaScript/DOM 领域，并确保这些操作按顺序发生。 在任务之间，浏览器可能会呈现更新。 从鼠标点击到事件回调需要安排一个任务，解析 HTML 也是如此

来看一个例子

console.log('script start')

setTimeout(function() {
  console.log('setTimeout')
}, 0)

Promise.resolve()
  .then(function() {
    console.log('promise1')
  })
  .then(function() {
    console.log('promise2')
  })

console.log('script end')
//script start
//script end
//promise1
//promise2
//setTimeout

setTimeout 等待给定的延迟，然后为其回调安排一个新任务。 这就是为什么在script end后输出 setTimeout 的原因，因为输出script end是第一个任务的一部分，而 setTimeout 输出在一个单独的任务中。

微任务通常被安排在当前执行的脚本之后应该立即发生的事情上，例如对一批操作做出反应，或者在不承担全新任务损失的情况下使某些事情异步。 只要没有其他 JavaScript 在执行中，并且在每个任务结束时，微任务队列就会在回调之后处理。 在微任务期间排队的任何其他微任务都会添加到队列的末尾并进行处理。 微任务包括变异观察者回调，如上例所示，Promise 回调。

一旦 promise 成立，或者如果它已经成立，它就会将一个微任务排队等待它的反馈回调。 这确保了promise回调是异步的，即使promise已经完成。 因此，针对已完成的promise调用 .then(yey, nay) 会立即将微任务排入队列。 这就是为什么在script end后输出 promise1 和 promise2 的原因，因为当前运行的脚本必须在处理微任务之前完成。 promise1 和 promise2 在 setTimeout 之前输出，因为微任务总是在下一个任务之前发生

一些浏览器打印script start, script end, setTimeout, promise1, promise2.这可能是因为浏览器在执行 promise 回调的时候将其作为一项新任务的一部分，而不是一项微任务

EventLoop 过程解析

• 一开始执行栈空,我们可以把执行栈认为是一个存储函数调用的栈结构，遵循先进后出的原则。micro 队列空，macro 队列里有且只有一个 script 脚本（整体代码）。
• 全局上下文（script 标签）被推入执行栈，同步代码执行。在执行的过程中，会判断是同步任务还是异步任务，通过对一些接口的调用，可以产生新的 macro-task 与 micro-task，它们会分别被推入各自的任务队列里。同步代码执行完了，script 脚本会被移出 macro 队列，这个过程本质上是队列的 macro-task 的执行和出队的过程。
• 上一步我们出队的是一个 macro-task，这一步我们处理的是 micro-task。但需要注意的是：当 macro-task 出队时，任务是一个一个执行的；而 micro-task 出队时，任务是一队一队执行的。因此，我们处理 micro 队列这一步，会逐个执行队列中的任务并把它出队（期间可能也会有新的微任务加入队列中，也得出队执行），直到队列被清空。
• 执行渲染操作，更新界面
• 检查是否存在 Web worker 任务，如果有，则对其进行处理
• 上述过程循环往复，直到两个队列都清空

我们总结一下，每一次循环都是一个这样的过程：

当某个宏任务执行完后,会查看是否有微任务队列。如果有，先执行微任务队列中的所有任务，如果没有，会读取宏任务队列中排在最前的任务，执行宏任务的过程中，遇到微任务，依次加入微任务队列。栈空后，再次读取微任务队列里的任务，依次类推。

接下来我们看道例子来介绍上面流程：

Promise.resolve().then(() => {
  console.log('Promise1')
  setTimeout(() => {
    console.log('setTimeout2')
  }, 0)
})
setTimeout(() => {
  console.log('setTimeout1')
  Promise.resolve().then(() => {
    console.log('Promise2')
  })
}, 0)

最后输出结果是 Promise1，setTimeout1，Promise2，setTimeout2

• 一开始执行栈的同步任务（这属于宏任务）执行完毕，会去查看是否有微任务队列，上题中存在(有且只有一个)，然后执行微任务队列中的所有任务输出 Promise1，同时会生成一个宏任务 setTimeout2
• 然后去查看宏任务队列，宏任务 setTimeout1 在 setTimeout2 之前，先执行宏任务 setTimeout1，输出 setTimeout1
• 在执行宏任务 setTimeout1 时会生成微任务 Promise2 ，放入微任务队列中，接着先去清空微任务队列中的所有任务，输出 Promise2
• 清空完微任务队列中的所有任务后，就又会去宏任务队列取一个，这回执行的是 setTimeout2

Node 中的 Event Loop

Node 简介

Node 中的 Event Loop 和浏览器中的是完全不相同的东西。Node.js 采用 V8 作为 js 的解析引擎，而 I/O 处理方面使用了自己设计的 libuv，libuv 是一个基于事件驱动的跨平台抽象层，封装了不同操作系统一些底层特性，对外提供统一的 API，事件循环机制也是它里面的实现（下文会详细介绍）。

Node.js 的运行机制如下:

• V8 引擎解析 JavaScript 脚本。
• 解析后的代码，调用 Node API。
• libuv 库负责 Node API 的执行。它将不同的任务分配给不同的线程，形成一个 Event Loop（事件循环），以异步的方式将任务的执行结果返回给 V8 引擎。
• V8 引擎再将结果返回给用户。

六个阶段

其中 libuv 引擎中的事件循环分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。

从上图中，大致看出 node 中的事件循环的顺序：

外部输入数据–>轮询阶段(poll)–>检查阶段(check)–>关闭事件回调阶段(close callback)–>定时器检测阶段(timer)–>I/O 事件回调阶段(I/O callbacks)–>闲置阶段(idle, prepare)–>轮询阶段（按照该顺序反复运行）…

• timers 阶段：这个阶段执行 timer（setTimeout、setInterval）的回调
• I/O callbacks 阶段：处理一些上一轮循环中的少数未执行的 I/O 回调
• idle, prepare 阶段：仅 node 内部使用
• poll 阶段：获取新的 I/O 事件, 适当的条件下 node 将阻塞在这里
• check 阶段：执行 setImmediate() 的回调
• close callbacks 阶段：执行 socket 的 close 事件回调

注意：上面六个阶段都不包括 process.nextTick()(下文会介绍)

接下去我们详细介绍timers、poll、check这 3 个阶段，因为日常开发中的绝大部分异步任务都是在这 3 个阶段处理的。

timer 阶段

timers 阶段会执行 setTimeout 和 setInterval 回调，并且是由 poll 阶段控制的。同样，在 Node 中定时器指定的时间也不是准确时间，只能是尽快执行。

poll 阶段

poll 是一个至关重要的阶段，这一阶段中，系统会做两件事情

• 回到 timer 阶段执行回调
• 执行 I/O 回调

并且在进入该阶段时如果没有设定了 timer 的话，会发生以下两件事情

• 如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者达到系统限制

• 如果 poll 队列为空时，会有两件事发生

• • 如果有 setImmediate 回调需要执行，poll 阶段会停止并且进入到 check 阶段执行回调
  • 如果没有 setImmediate 回调需要执行，会等待回调被加入到队列中并立即执行回调，这里同样会有个超时时间设置防止一直等待下去

当然设定了 timer 的话且 poll 队列为空，则会判断是否有 timer 超时，如果有的话会回到 timer 阶段执行回调。

check 阶段

setImmediate()的回调会被加入 check 队列中，从 event loop 的阶段图可以知道，check 阶段的执行顺序在 poll 阶段之后。

我们先来看个例子:

console.log('start')
setTimeout(() => {
  console.log('timer1')
  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)
setTimeout(() => {
  console.log('timer2')
  Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0)
Promise.resolve().then(function() {
  console.log('promise3')
})
console.log('end')
//start=>end=>promise3=>timer1=>timer2=>promise1=>promise2

• 一开始执行栈的同步任务（这属于宏任务）执行完毕后（依次打印出 start end，并将 2 个 timer 依次放入 timer 队列）,会先去执行微任务（这点跟浏览器端的一样），所以打印出 promise3
• 然后进入 timers 阶段，执行 timer1 的回调函数，打印 timer1，并将 promise.then 回调放入 microtask 队列，同样的步骤执行 timer2，打印 timer2；这点跟浏览器端相差比较大，timers 阶段有几个 setTimeout/setInterval 都会依次执行，并不像浏览器端，每执行一个宏任务后就去执行一个微任务（关于 Node 与浏览器的 Event Loop 差异，下文还会详细介绍）。

setTimeout 和 setImmediate

二者非常相似，区别主要在于调用时机不同。

• setImmediate 设计在 poll 阶段完成时执行，即 check 阶段；
• setTimeout 设计在 poll 阶段为空闲时，且设定时间到达后执行，但它在 timer 阶段执行

setTimeout(function timeout() {
  console.log('timeout')
}, 0)
setImmediate(function immediate() {
  console.log('immediate')
})

• 对于以上代码来说，setTimeout 可能执行在前，也可能执行在后。
• 首先 setTimeout(fn, 0) === setTimeout(fn, 1)，这是由源码决定的进入事件循环也是需要成本的，如果在准备时候花费了大于 1ms 的时间，那么在 timer 阶段就会直接执行 setTimeout 回调
• 如果准备时间花费小于 1ms，那么就是 setImmediate 回调先执行了

但当二者在异步 i/o callback 内部调用时，总是先执行 setImmediate，再执行 setTimeout

const fs = require('fs')
fs.readFile(__filename, () => {
  setTimeout(() => {
    console.log('timeout')
  }, 0)
  setImmediate(() => {
    console.log('immediate')
  })
})
// immediate
// timeout

在上述代码中，setImmediate 永远先执行。因为两个代码写在 IO 回调中，IO 回调是在 poll 阶段执行，当回调执行完毕后队列为空，发现存在 setImmediate 回调，所以就直接跳转到 check 阶段去执行回调了。

process.nextTick

这个函数其实是独立于 Event Loop 之外的，它有一个自己的队列，当每个阶段完成后，如果存在 nextTick 队列，就会清空队列中的所有回调函数，并且优先于其他 microtask 执行。

setTimeout(() => {
  console.log('timer1')
  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)
process.nextTick(() => {
  console.log('nextTick')
  process.nextTick(() => {
    console.log('nextTick')
    process.nextTick(() => {
      console.log('nextTick')
      process.nextTick(() => {
        console.log('nextTick')
      })
    })
  })
})
// nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1

Node 与浏览器的 Event Loop 差异

浏览器环境下，microtask 的任务队列是每个 macrotask 执行完之后执行。而在 Node.js 中，microtask 会在事件循环的各个阶段之间执行，也就是一个阶段执行完毕，就会去执行 microtask 队列的任务。

接下我们通过一个例子来说明两者区别：

setTimeout(() => {
  console.log('timer1')
  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)
setTimeout(() => {
  console.log('timer2')
  Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0)

浏览器端运行结果：timer1=>promise1=>timer2=>promise2

浏览器端的处理过程如下：

Node 端运行结果：timer1=>timer2=>promise1=>promise2

• 全局脚本（main()）执行，将 2 个 timer 依次放入 timer 队列，main()执行完毕，调用栈空闲，任务队列开始执行；
• 首先进入 timers 阶段，执行 timer1 的回调函数，打印 timer1，并将 promise1.then 回调放入 microtask 队列，同样的步骤执行 timer2，打印 timer2；
• 至此，timer 阶段执行结束，event loop 进入下一个阶段之前，执行 microtask 队列的所有任务，依次打印 promise1、promise2

Node 端的处理过程如下：

总结

浏览器和 Node 环境下，microtask 任务队列的执行时机不同

• Node 端，microtask 在事件循环的各个阶段之间执行
• 浏览器端，microtask 在事件循环的 macrotask 执行完之后执行

微任务和宏任务在 Node 的执行顺序

• Node 10 以前：

  1. 执行完一个阶段的所有任务
  2. 执行完 nextTick 队列里面的内容
  3. 然后执行完微任务队列的内容

• Node 11 以后： 和浏览器的行为统一了，都是每执行一个宏任务就执行完微任务队列。

参考

详解 JavaScript 中的 Event Loop（事件循环）机制 (opens new window)

浏览器与 Node 的事件循环(Event Loop)有何区别? (opens new window)

从 Chrome 源码看事件循环 (opens new window)

Tasks, microtasks, queues and schedules (opens new window)