此篇文章旨在帮助理解浏览器和Node.js的事件循环机制，如有不足或错误之处，望指出。

大家好鸭，博主是一个飞向前端开发的小泡泡！

作为一个前端的开发人员，经常会与浏览器以及Node.js打交道，那么，对于事件循环机制，相信大家都不会太过陌生，但是一旦遇到了这方面的问题，有些也只是一知半解，甚至无从下手。博主看过了许多相关的公众号和博客，发现有些讲的并不是那么完善，就将这些总结在一起吧，更有利于系统性的学习。

我们知道，javascript是单线程的，在同一个时间内只能执行一个任务，那他是如何做到异步回调的呢？我会在后面给出答案，首先我们从进程和线程这两方面入手，循序渐进。

CPU？进程？线程？

我们经常会听到CPU、线程、进程等名词，以下做一个比较形象的比喻吧。

CPU

计算机的核心是CPU，就像是一个工厂，所有的任务执行都在这里，并且是时刻运行的。

进程

进程，代表CPU所能处理的单个任务，类似工厂里的车间，由于资源有限，工厂只能将其分配给一个车间，其他车间就必须停止工作，也就是说单个CPU只能运行一个进程（任务），通过时间片轮转调度算法，可以实现CPU运行多个进程。

线程

线程，类似车间里的每一个工人，属于同一个车间的工人共享同一个资源，完成同一个任务。一个进程可以包含多个线程，多个线程共享同一个资源。

总结

• 进程是CPU资源分配的最小单位。
• 线程是CPU资源调度的最小单位，是建立在进程的基础上的一次程序运行单位。
• 一个进程可以包含多个线程，多个线程共享进程资源。
• 单线程和多线程都是在同一个进程之内。

浏览器是多进程还是单进程？

对于每一个计算机，一个应用程序就代表了一个进程，每个应用程序的功能模块又是由不同子进程实现的，那么这个应用程序就是“多进程”的。那么，浏览器究竟属于单进程还是多进程呢？其实很简单，只需要打开任务管理器，在浏览器打开多个tab页，便会在任务管理器显示出多个子进程，所以浏览器是多进程的。

任务管理器-Chrome进程

浏览器包含了哪些进程？

• 主进程
• 第三方插件进程
• GPU进程（3D绘制）
• 渲染进程（浏览器内核）
  其中，我们前端经常接触到的是渲染进程，也就是浏览器内核。它负责页面的渲染，脚本执行，事件处理等，上面的每个tab页就包含一个渲染进程。

渲染进程（浏览器内核）

前面提起过，一个进程可以包含多个线程，那么渲染进程也不例外，它包含了以下几个线程。

• GUI渲染线程

  1.负责页面的布局，绘制以及渲染。
  2.在页面发生回流（重排）以及重绘时就会执行该线程。
  3.与JS引擎线程互斥，避免影响绘制效果。

• JS引擎线程

  1.负责解析并执行相关的js脚本。
  2.只存在一个JS引擎线程（单线程）。
  3.与GUI渲染线程互斥,避免影响绘制效果。

• 事件触发线程

  1.用于控制事件循环。
  2.当满足相应的触发条件时，会执行相应的事件，也可能会产生新的线程。
  3.将回调放入任务队列，管理任务队列。

• 定时器触发线程

  1.setTimeout、setInterval所在线程。
  2.执行相应的定时任务。
  3.计时完毕后将相关的回调函数交由事件触发线程处理。

• 异步HTTP请求线程

  1.用于处理Ajax请求。
  2.请求完毕后若有回调任务，将相关的回调函数交由事件触发线程处理。

结合图一起来理解下吧~

渲染进程

Tip:为什么GUI渲染线程会和JS引擎线程互斥呢？
由于JS也是可以对DOM进行操作的，若同时对页面元素进行修改，重新渲染页面后可能会出现不可预期的结果，所以两者不可同时运行。

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

在对浏览器的进程、线程有了基本的了解之后，我们开始讲述下关于浏览器里的事件循环。

我们知道，JS任务分为同步任务以及异步任务，同步任务会在执行栈中顺序执行，而异步任务则会放到任务队列里，等待JS引擎线程空闲之后才会将这些异步任务依次推入到执行栈中，供JS引擎线程执行。如下图：

添加执行栈

如此执行就是我们常常听到的事件循环，也就是javascript实现异步的核心所在。

事件循环如何处理定时任务以及网络请求？

• 对于定时任务：当JS引擎线程执行到定时任务代码，例如setTimeout、setInterval，JS引擎线程会通知定时器触发线程，间隔一段时间触发一个回调函数，定时器触发线程接收消息后，进行计时，计时结束后，会将相应的回调函数交由事件触发线程，再将其放入任务队列中。

• 对于网络请求：当JS引擎线程执行到网络请求代码，例如ajax、fetch，JS引擎线程会通知异步HTTP请求线程，向服务器发送请求，请求结束后，若有回调函数，则会将相应的回调函数交由事件触发线程，再将其放入任务队列中。

用段代码解释一下~

// 同步任务
console.log(1)
// 同步任务
// 通知定时器线程 1s 后将回调交由事件触发线程处理
// 1s 后事件触发线程将回调加入到任务队列中
setTimeout(() => {
  console.log(2)
}, 0)
// 同步任务
// 通知异步HTTP请求线程发送网络请求，请求完成后将回调交由事件触发线程处理
// 请求完成后事件触发线程将回调加入到任务队列中
$.get('www.xxxxxxxxx.com', () => {
  console.log(3)
})
// 同步任务
console.log(4)
// 所有同步任务执行完后
// 询问事件触发线程在任务队列中是否有需要执行的回调函数
// 如果没有，一直询问，直到有为止
// 如果有，将回调事件加入执行栈中，开始执行回调代码

打印出的顺序应为1-4-2-3

关于宏任务和微任务

我们了解了执行栈、任务队列之后，再来认识下什么是事件循环中的宏任务（macrotask）和微任务（microtask）。

• 宏任务：我们可以把每次在执行栈里执行的一系列代码看成一个宏任务（包括每次从事件队列里将一个回调函数放入执行栈执行）。宏任务可以包含执行整体的script、事件回调、XHR回调、定时器（setTimeout、setInterval、setImmediate）、IO操作、UI render。

Tip:由于JS引擎线程和GUI渲染线程是互斥的，所以为了保证有效的进行渲染，在每次宏任务执行之后，下一次宏任务执行之前，GUI渲染线程都会执行一次，渲染页面。

• 微任务：微任务可以看做宏任务执行完毕后立刻执行的一系列任务，它在GUI渲染线程执行之前执行，在每一次宏任务执行完毕后，必须执行完所有微任务才能进入下一阶段。微任务可以包含Promise回调、MutationObserver、process.nextTick、Object.observe等。

Tip:setImmediate和process.nextTick是Node.js的实现，后面讲到了会做出详解。

• 整体流程为： 宏任务 => 微任务 => 渲染 => 宏任务 => .......

图解如下：

宏任务与微任务

来段代码感受一下吧，举一个小栗子！

console.log('start')

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

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

console.log('end')

以上输出结果会是什么呢？我们来一步一步分析

1. 首先，系统将主代码块（整体的script）放入执行栈中，开始执行第一次宏任务。
2. JS引擎线程顺序执行同步代码，先输出start。
3. 遇到setTimeout，通知定时器触发线程，经过一段时间将回调交由事件触发线程，事件触发线程将回调函数放入任务队列的宏任务队列中。
4. 遇到Promise回调，执行同步代码，然后将回调函数通过事件触发线程放入任务队列的微任务队列中。
5. 输出end，第一次宏任务结束。
6. 紧接着执行微任务，推出微任务列表中的任务放入执行栈中执行，输出promise1，由于后面又接着一个Promise回调，再继续将该回调放入微任务队列，再次推出微任务列表中的任务放入执行栈中执行输出promise2（因为必须执行完该次宏任务生成的所有微任务才能继续向下执行）。
7. 渲染页面（GUI渲染线程接管，不一定执行）。
8. 此时执行栈为空，系统从任务队列的宏任务队列中推出一个宏任务到执行栈中执行，执行第二次宏任务，输出setTimeout。

因此执行顺序为：start => end => promise1 => promise2 => setTimeout

我们利用一张动图来展现一下~

事件循环中的宏任务和微任务

完整的渲染进程如下

渲染进程

总结：浏览器的事件循环

• 执行一个宏任务（执行栈为空则从任务队列的宏任务队列中获取）。
• 执行过程中如果遇到微任务，就将它添加到任务队列的微任务队列中。
• 宏任务执行完毕后，立即依次执行当前微任务队列中的所有微任务。
• 当前宏任务执行完毕，GUI线程接管渲染。
• 渲染完毕后，JS线程继续接管，开始下一个宏任务。

微任务在每次宏任务之后执行

Node.js的事件循环机制（Event Loop）

在浏览器存在着事件循环，Node.js也同样存在事件循环，那么两个事件循环有什么区别呢？我们先看一下下面的代码输出了些什么吧。

setTimeout(()=>{
    console.log(1)
    Promise.resolve().then(function() {
        console.log(2)
    })
}, 0)

setTimeout(()=>{
    console.log(3)
    Promise.resolve().then(function() {
        console.log(4)
    })
}, 0)

在浏览器上，我们输出的结果为1 => 2 => 3 => 4

浏览器输出结果

而在Node.js中，我们输出的结果为1 => 3 => 2 => 4

Node输出结果

诶？我们发现，两者的输出结果不尽相同，可见还是存在差异的。

Node.js的事件循环机制的六个阶段

与浏览器不同的是，浏览器的Event Loop是HTML5中定义的规范，而Node.js采用V8引擎，其中的Event Loop是依赖libuv库实现的，libuv是一个基于事件驱动的跨平台抽象层，封装了许多实用的API，事件循环的六个阶段就是在这里面编写的。
Node.js每次事件循环机制分为以下六个阶段：

• timers 阶段：这个阶段检查是否有到期的timer（setTimeout、setInterval），并执行相应的回调函数。
• I/O callbacks 阶段：执行延迟到下一个循环迭代的 I/O 回调，即普通的回调。
• idle, prepare 阶段：仅系统内部使用。
• poll 阶段：检索新的 I/O 事件;执行与 I/O 相关的回调（几乎所有情况下，除了关闭的回调函数，它们由计时器和 setImmediate() 排定的之外），其余情况 node 将在此处阻塞。
• check 阶段：执行setImmediate的回调函数。
• close callbacks 阶段：一些准备关闭的回调函数，如：socket.on('close', ...)

对于我们理解事件循环，只需要关注timers、poll、check这3个阶段即可，在我们进行开发的过程中大部分的异步任务都在这些阶段进行的。

timers 阶段

timers是事件循环的第一个阶段，这个阶段会检查是否有到期的timer（setTimeout、setInterval），有则将回调函数放入timers的任务队列里等待执行。Node对时间的到期检查并不是十分精确，并不能保证timer在预设时间到了就会立即执行。例如以下代码：

setTimeout(() => {
  console.log('timeout');
}, 0);

setImmediate(() => {
  console.log('immediate');
});

在不同环境下和情况下结果可能是不同的，有些是timeout => immediate，有些是immediate => timeout，这是因为计时会受进程性能的约束（受到计算机上运行的其它应用程序的影响），从而造成setTimeout做不到0毫秒，最少也需要1毫秒，根据官方文档，第二个参数的取值范围在1毫秒到2147483647毫秒之间。也就是说，setTimeout(f, 0)等同于setTimeout(f, 1)。

但是，如果将以上代码放在一个I/O操作的回调函数中，则一定先输出immediate，因为poll阶段后面就是check阶段。

const fs = require('fs');

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

poll 阶段

poll阶段是事件循环的轮询阶段，主要做两件事：

1. 执行poll队列中的回调任务。
2. poll队列为空时，若有已超时的timer，则执行它的回调函数。

到了该阶段，会执行poll队列里的回调任务，当任务执行完毕，队列为空或上限时，回去检查脚本中是否有预设的setImmediate。若有则进入check阶段，执行check的任务队列；若没有则阻塞在该阶段。但是事件循环并不会一直保持这种阻塞状态，它会去检查是否有已过期的timer。如果有，则事件循环将绕回timers阶段以执行这些计时器的回调。

check阶段

这个阶段会执行check队列中的setImmediate的回调任务。

Tip: Node.js事件循环的每个阶段都有一个任务队列。

就之前的代码来一步一步解析下吧！

setTimeout(()=>{
    console.log(1)
    Promise.resolve().then(function() {
        console.log(2)
    })
}, 0)

setTimeout(()=>{
    console.log(3)
    Promise.resolve().then(function() {
        console.log(4)
    })
}, 0)

1. 首先，系统将主代码块压入执行栈中执行，将两个timer放入timers阶段的任务队列中。
2. 此时执行栈为空，任务队列开始执行。
3. 先进入timers阶段，执行第一个回调函数输出1，然后将Promise回调放入到微任务队列（microtask queue）中。
4. 执行timers阶段的下一个回调函数输出3，然后将Promise回调放入到微任务队列（microtask queue）中，timers阶段结束。
5. 在事件循环的每一个阶段结束后，新的阶段开始前都会执行microtask queue中的所有微任务，所以依次执行输出2,4。
6. 最后结果为1 => 3 => 2 => 4。

我们利用一张动图来展现一下~

Node事件循环实例

Tip:除了microtask队列之外，还存在着nextTick队列，会在microtask执行之前执行。

总结：Node.js的事件循环

• Node.js的事件循环分为六个阶段。
• 浏览器和Node.js的事件循环的微任务（microtask）队列执行的时机不同。浏览器中是在每一次宏任务执行结束之后立即执行；Node中是在事件循环的每一个阶段结束后执行。
• 递归的调用process.nextTick()会导致I/O starving，官方推荐使用setImmediate()。
• 在每个阶段执行完毕后都会执行microtask queue以及nextTick queue。即同步任务一旦执行完成，就开始执行它们。
• 如果在 timers 阶段执行时创建了setImmediate 则会在此轮循环的 check 阶段执行，如果在 timers 阶段创建了setTimeout，由于 timers 已取出完毕，则会进入下轮循环，check 阶段创建 timers 任务同理。
• 在执行事件循环之前，会做以下几件事:
  1.同步任务
  2.发出异步请求
  3.规划定时器生效的时间
  4.执行process.nextTick()和promise回调

微任务每个各阶段结束后执行

————————————————
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Sivak_/article/details/102068644