一起聊聊Node中的事件循环

// index.js

function A() {
  console.log("A");
}

function B() {
  console.log("B");
}

A()
B()

// Logs A and then B

// index.js
console.log("First");
console.log("Second");
console.log("Third");

以下是 Node 运行时执行同步代码的可视化展示。

执行的主线程始终从全局作用域开始。全局函数（如果我们可以这样称呼它）被推入堆栈中。然后，在第 1 行，我们有一个控制台日志语句。这个函数被推入堆栈中。假设这个发生在 1 毫秒时，“First” 被记录在控制台上。然后，这个函数从堆栈中弹出。

执行到第 2 行时。假设到第 2 毫秒了，log 函数再次被推入堆栈中。“Second”被记录在控制台上，并弹出该函数。

最后，执行到第 3 行了。第 3 毫秒时，log 函数被推入堆栈，“Third”将记录在控制台上，并弹出该函数。此时已经没有代码要执行，全局也被弹出。

异步代码执行

接下来，让我们看一下异步代码执行。有以下代码片段：包含三个日志语句，但这次第二个日志语句传递给了fs.readFile() 作为回调函数。

执行的主线程始终从全局作用域开始。全局函数被推入堆栈。然后执行到第 1 行，在第 1 毫秒时，“First”被记录在控制台中，并弹出该函数。然后执行移动到第 2 行，在第 2毫秒时，readFile 方法被推入堆栈。由于 readFile 是异步操作，因此它会转移（off-loaded）到 libuv。

JavaScript 从调用堆栈中弹出了 readFile 方法，因为就第 2 行的执行而言，它的工作已经完成了。在后台，libuv 开始在单独的线程上读取文件内容。在第 3 毫秒时，JavaScript 继续进行到第 5 行，将 log 函数推入堆栈，“Third”被记录到控制台中，并将该函数弹出堆栈。

大约在第 4 毫秒左右，假设文件读取任务已经完成，则相关回调函数现在会在调用栈上执行， 在回调函数内部遇到 log 函数。

log 函数推入到到调用栈，“Second”被记录到控制台并弹出 log 函数 。由于回调函数中没有更多要执行的语句，因此也被弹出 。没有更多代码可运行了 ，所以全局函数也从堆栈中删除 。

控制台输出“First”，“Third”，然后是“Second”。

Libuv 和异步操作

很明显，libuv 用于处理 Node.js 中的异步操作。对于像处理网络请求这样的异步操作，libuv 依赖于操作系统原生机制。对于没有本地 OS 支持的异步读取文件的操作，libuv 则依赖其线程池以确保主线程不被阻塞。然而，这也引发了一些问题。

• 当一个异步任务在 libuv 中完成时，什么时候 Node 会在调用栈上运行相关联的回调函数？
• Node 是否会等待调用栈为空后再运行回调函数？还是打断正常执行流来运行回调函数？
• 像 setTimeout 和 setInterval 这类延迟执行回调函数的方法又是何时执行回调函数呢？
• 如果 setTimeout 和 readFile 这类异步任务同时完成，Node 如何决定哪个回调函数先在调用栈上运行？其中一个会有更多的优先级吗？

所有这些问题都可以通过理解 libuv 核心部分——事件循环来得到答案。

什么是事件循环？

从技术上讲，事件循环只是一个 C 语言程序。但是在 Node.js 中，你可以将其视为一种设计模式，用于协调同步和异步代码的执行。

可视化事件循环

事件循环是一个循环，只要你的 Node.js 应用程序在运行，它就一直运行。每个循环中有六个不同的队列，每个队列都包含一个或多个需要最终在调用堆栈上执行的回调函数。

• 首先，有一个计时器队列（timer queue。技术上叫最小堆（min-heap）），它保存与 setTimeout 和 setInterval 相关的回调函数。
• 其次，有一个 I/O 队列（I/O queue），其中包含与所有异步方法相关的回调函数，例如 fs 和 http 模块中提供的相关方法。
• 第三个是检查队列（check queue），它保存与 setImmediate 函数相关的回调函数，这是特定于Node 的功能。
• 第四个是关闭队列（close queue），它保存与异步任务关闭事件相关联的回调函数。

最后，有两个不同队列组成微任务队列（microtask queue）。

• nextTick 队列保存了与 process.nextTick 函数关联的回调函数。
• Promise 队列则保存了JavaScript 中本地 Promise 相关联的回调函数。

需要注意的是计时器、I/O、检查和关闭队列都属于 libuv。然而，两个微任务队列并不属于 libuv。尽管如此，它们仍然是 Node 运行时环境中扮演着重要角色，并且在执行回调顺序方面发挥着重要作用。说到这里, 让我们来理解一下事件循环是如何工作的。

事件循环是如何工作的？

图中箭头是一个提示，但可能还不太容易理解。让我来解释一下队列的优先级顺序。首先要知道，所有用户编写的同步 JavaScript 代码都比异步代码优先级更高。这表示只有在调用堆栈为空时，事件循环才会发挥作用。

在事件循环中，执行顺序遵循某些规则。需要掌握的规则还是有一些的，我们逐个的了解一下：

1. 执行微任务队列（microtask queue）中的所有回调函数。首先是 nextTick 队列中的任务，然后是 Promise 队列中的任务。
2. 执行计时器队列（timer queue）内的所有回调函数。
3. 如果微任务队列中存在回调函数，则在计时器队列内每执行完一次回调函数之后执行微任务队列中的所有回调函数。首先是 nextTick 队列中的任务，然后是 Promise 队列中的任务。
4. 执行 I/O 队列（I/O queue）内的所有回调函数。
5. 如果微任务队列中存在回调函数，按照先 nextTick 队列后 Promise 队列的顺序依次执行微任务队列中的所有回调函数。
6. 执行检查队列（check queue）内的所有回调函数。
7. 如果微任务队列中存在回调函数，则在检查队列内每个回调之后执行微任务队列中的所有回调函数 。首先是 nextTick 队列中的任务，然后是 Promise 队列中的任务。
8. 执行关闭队列（close queue）内的所有回调函数。
9. 在同一循环的最后，再执行一次微任务队列。首先是 nextTick 队列中的任务，然后是 Promise 队列中的任务。

此时，如果还有更多的回调需要处理，那么事件循环再运行一次（译注：事件循环在程序运行期间一直在运行，在当前没有可供处理的任务情况下，会处于等待状态，一旦有新任务就会执行），并重复相同的步骤。另一方面，如果所有回调都已执行并且没有更多代码要处理（译注：也就是程序执行结束），则事件循环退出。

这就是 libuv 事件循环在 Node.js 中执行异步代码的作用。有了这些规则，我们可以重新审视之前提出的问题。

当一个异步任务在 libuv 中完成时，什么时候 Node 会在调用栈上运行相关联的回调函数？

答案：只有当调用栈为空时才执行回调函数。

Node 是否会等待调用栈为空后再运行回调函数？还是打断正常执行流来运行回调函数？

答案：运行回调函数时不会打断正常执行流。

像 setTimeout 和 setInterval 这类延迟执行回调函数的方法又是何时执行回调函数呢？

答案：setTimeout 和 setInterval 的所有回调函数中第一优先级执行的（不考虑微任务队列）。

如果两个异步任务（例如 setTimeout 和 readFile）同时完成，Node 如何决定那个回调函数先在调用栈中执行？其中一个会比另一个有更高优先权吗？

答案：在同时完成的情况下，计时器回调会先于 I/O 回调执行。

到此为止我们学了很多，但我希望大家可以把下面这张图片展现的执行顺序铭记于心，因为它完整的表现了 Node.js 在幕后是如何执行异步代码的。

但是，你可能会问：“验证这个可视化的代码在哪里？”。好吧，事件循环中的每个队列都有执行上的细微差别，因此我们最好一个个来讲比较好。本文是 Node.js 事件循环系列文章中的第一篇。请务必查看文末链接，以便了解每个队列中的运行细节，即便你现在在脑海中印象很深了，到具体场景的时候可能还进到一些陷阱。

结论

这个视觉指南涵盖了 JavaScript 中异步编程、Node.js 运行时和负责处理异步操作的 libuv 的基础知识。有了这些知识，你可以建立一个强大的事件循环模型，在编写利用 Node.js 异步特性的代码时受益。

更多node相关知识，请访问：nodejs 教程！

以上就是一起聊聊Node中的事件循环的详细内容，转载自php中文网