node事件循环

tags: Nodejs Created time: June 25, 2022 11:50 AM emoji: https://nodejs.org/static/images/favicons/favicon.png

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

nodejs中的事件循环有6个阶段，每个阶段都有一个FIFO队列来执行回调，直到队列为空或达到最大回调限制，则进入下一阶段。

每个阶段作用

• 定时器：执行已经被 setTimeout() 和 setInterval() 的调度回调函数。

• 待定回调：执行上个事件循环未执行都回调

• idle,prepare：系统内部使用

• 轮询：检索新的I/O事件，执行I/O事件，nodejs会在此阶段适当地停留(阻塞)。

• 检查： 执行setImmediate回调

• 关闭的回调函数：一些关闭的回调函数，如：socket.on('close', ...)。

重要阶段

定时器

定时器阶段nodej会给定时器设定一个阀值，当指定一段时间间隔之后，定时器回调会尽快执行，但是这也可能会被其他回调阻塞，也就是说定时器回调真正的执行时间可能晚于用户所设置的时间。

定时器何时执行取决于轮询阶段。轮询阶段存在一个队列，当队列为空时，轮询机制会检查是否有定时器到达阀值，并回到定时器阶段来执行到达阀值的定时器回调。当定时器到达阀值时，假如轮询队列中仍有回调，那么定时器回调将会被延迟执行，直到队列为空。

轮询

轮询 阶段有两个重要的功能：

1. 计算应该阻塞和轮询 I/O 的时间。

2. 然后，处理 轮询 队列里的事件。

当事件循环到达轮询阶段时有这几种情况：

• 轮询队列不为空：事件循环将循环访问回调队列并同步执行它们，直到队列已用尽，或者达到了与系统相关的硬性限制。

• 轮询接口为空

  • setImmediate被调度，则事件循环进入下一阶段-检查阶段来执行回调。

  • 检查到达阀值的定时器，并回到定时器阶段来执行这些定时器（详情见定时器阶段）

  • 等待回调被加入到队列中执行。为了避免长时间阻塞事件循环，nodejs会有一个最大值，当到达最大值时则进入下一阶段。

检查阶段

轮询队列为空并回调已使用 setImmediate()调度过或者轮询达到最大值，则事件循环会从轮询阶段进入到检查阶段。setImmediate()回调都将在此阶段执行。

关闭的回调函数

执行 socket 的 close 事件回调

setImmediate vs process.nextTick

任何时候在给定的阶段中调用 process.nextTick()，那么 process.nextTick() 的回调将在事件循环进入下一阶段之前执行，而setImmediate则会固定在检查阶段执行。

process.nextTick回调执行比setImmediate更快，不要被名字误导了。

process.nextTick VS 微任务

Promise对象的回调函数，会进入异步任务里面的"微任务队列"（microtaskQueue），process.nextTick回调会进入nextTickQueue 中，并且微任务队列追加在process.nextTick队列的后面，也就是说process.nextTick回调总是比Promise回调执行地早。

Promise.resolve().then(() => console.log(1));
process.nextTick(() => console.log(2));
// 2 1

总结

综上所述，一般情况下nodejs中异步API执行的先后顺序。

process.nextTick() > microtask > setImmediate() > setTimeout()

事实上以上顺序并不一定准确，例如setTimeout和setImmediate。

如果在主模块中直接执行，那么两者的执行顺序并不确定

setTimeout(() => {
  console.log("setTimeout");
});
setImmediate(() => {
  console.log("setImmediate1");
});

// setImmediate1
// setTimeout
// 也可能是
// setTimeout
// setImmediate1

但是如果你在一个I/O周期内执行，那么就肯定是setImmediate先执行

const fs = require("fs");
fs.stat("./xxx", () => {
  setTimeout(() => {
    console.log("setTimeout");
  }, 0);
  setImmediate(() => {
    console.log("setImmediate1");
  });
});
// setImmediate1
// setTimeout

这是因为在主模块执行到代码时，并不能确定事件循环执行到哪个阶段了，加入定时器阶段那么就是setTimeout先执行，如果是在检查阶段就是setImmediate先执行，而当他们都同一I/O周期中时，那么就能确保他们都在轮询阶段，当轮询队列为空时则会直接进入检查阶段，而不会处理达到阀值的定时器。

参考

Node.js 事件循环，定时器和 process.nextTick() | Node.js (nodejs.org)

浏览器与Node的事件循环(Event Loop)有何区别? - CNode技术社区 (cnodejs.org)

不要混淆nodejs和浏览器中的event loop - CNode技术社区 (cnodejs.org)

设计概述 — libuv 文档