> For the complete documentation index, see [llms.txt](https://1425816423.gitbook.io/my-knowledge-base/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://1425816423.gitbook.io/my-knowledge-base/fu-wu-qi-duan/nodejs/node-shi-jian-xun-huan.md).

# 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`回调执行地早。

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

## **总结**

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

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

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

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

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

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

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

```jsx
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)](https://nodejs.org/zh-cn/docs/guides/event-loop-timers-and-nexttick/)

[浏览器与Node的事件循环(Event Loop)有何区别? - CNode技术社区 (cnodejs.org)](https://cnodejs.org/topic/5c3d554fa4d44449266b1077)

[不要混淆nodejs和浏览器中的event loop - CNode技术社区 (cnodejs.org)](https://cnodejs.org/topic/5a9108d78d6e16e56bb80882)

[设计概述 — libuv 文档](http://docs.libuv.org/en/v1.x/design.html)