Node.js事件循环6大阶段解析

小伙伴们有没有觉得学习文章很有意思？有意思就对了！今天就给大家带来《Node.js事件循环的6个阶段详解》，以下内容将会涉及到，若是在学习中对其中部分知识点有疑问，或许看了本文就能帮到你！

Node.js事件循环的六个阶段分别是timers、pending callbacks、idle/prepare、poll、check和close callbacks。1.timers阶段执行setTimeout()和setInterval()回调；2.pending callbacks处理系统操作回调如TCP错误；3.idle/prepare为内部阶段，用于准备下一轮循环；4.poll阶段为核心，负责检查I/O事件并等待新事件；5.check阶段执行setImmediate()回调；6.close callbacks执行关闭句柄的回调。此外，process.nextTick()和Promise微任务不属于任何阶段，但优先级高于各阶段任务，在每个阶段切换前清空微任务队列。理解事件循环有助于优化异步代码执行顺序，避免性能瓶颈和死锁问题，是编写高性能Node.js应用的关键。

Node.js事件循环的六个阶段主要指的是：timers（定时器）、pending callbacks（待定回调）、idle, prepare（空闲/准备）、poll（轮询）、check（检查）和 close callbacks（关闭回调）。这些阶段共同构成了Node.js处理异步操作的核心机制，确保了其非阻塞I/O的特性。

解决方案

Node.js的事件循环，在我看来，是理解其高性能和非阻塞特性的关键。它并不是一个简单的循环，而更像一个精密的管家，负责调度不同类型的异步任务。当你执行一个Node.js应用时，它会不断地在这些预设的阶段中循环，每次循环都尝试执行队列中待处理的回调函数。这个过程确保了即使有大量I/O操作，主线程也能保持响应，不会被长时间阻塞。

简单来说，事件循环的工作就是不断检查是否有任务可以执行。它会从一个阶段进入下一个阶段，每个阶段都有自己负责处理的任务队列。当一个阶段的任务队列清空后，或者达到特定条件（比如达到poll阶段的超时时间），它就会进入下一个阶段。这种设计，让Node.js在单线程模型下依然能高效处理并发。

为什么理解Node.js事件循环如此重要？

说实话，这玩意儿刚开始看确实有点绕，但一旦你真正搞清楚了，会发现它对你写出的Node.js代码质量有着决定性的影响。我个人觉得，理解事件循环不仅仅是理论知识，更是编写高性能、无死锁、易于调试的Node.js应用的基础。

想想看，如果你的代码中充斥着大量的异步操作，比如数据库查询、文件读写、网络请求，而你不清楚这些回调函数会在什么时候被执行，那么你的程序很可能会出现一些难以捉摸的bug，比如回调地狱的执行顺序混乱，或者CPU密集型任务不小心阻塞了事件循环导致整个应用卡顿。很多时候，我们遇到的性能瓶颈或者奇怪的异步行为，追根溯源，往往都能归结到对事件循环机制理解的不足。

比如，你可能会好奇为什么setTimeout(fn, 0)有时候比setImmediate(fn)执行得晚，有时候又执行得早。这背后就是事件循环不同阶段的执行顺序在起作用。搞明白这些，你就能更精准地控制代码的执行时机，避免一些意想不到的副作用。对我来说，这就像是拿到了Node.js内部运作的“说明书”，能让我写代码时更有底气，也更能预判程序的行为。

Node.js事件循环的各个阶段具体都在做什么？

Node.js的事件循环主要由以下六个阶段构成，它们按照特定的顺序循环执行：

1. timers (定时器阶段): 这个阶段主要执行setTimeout()和setInterval()设定的回调函数。当这些定时器到期时，它们的任务就会被放入这个阶段的队列中等待执行。

   • 我的理解: 它是事件循环的第一个“检查站”，看看有没有到点该执行的定时任务。

2. pending callbacks (待定回调阶段): 负责执行一些系统操作的回调，比如TCP连接错误的回调。这部分回调通常是操作系统层面的，不常见于普通的应用逻辑。

   • 我的理解: 这是一个比较“幕后”的阶段，通常我们开发者不太直接打交道，但它确保了底层系统事件能被及时处理。

3. idle, prepare (空闲/准备阶段): 这两个是内部阶段，Node.js内部使用，用于准备下一次循环或执行一些内部清理工作。对我们开发者来说，通常不需要关心它们。

   • 我的理解: 可以把它看作是事件循环内部的“休息室”或者“准备区”，对外部透明。

4. poll (轮询阶段): 这是事件循环中非常核心的一个阶段。它有两个主要功能：

   • 检查I/O事件: 如果有新的I/O事件（如文件读取完成、网络请求响应到达），它们的回调函数会被立即执行。
   • 处理定时器: 如果timers队列为空，并且没有setImmediate的回调待处理，poll阶段会计算何时有最接近的定时器到期，然后等待I/O事件或达到定时器超时时间。如果I/O队列为空，它可能会阻塞在这里，直到有新的I/O事件发生或者某个定时器到期。
   • 我的理解: poll阶段就像是事件循环的“调度中心”和“等待区”。它既处理已完成的I/O，又负责等待新的I/O或定时器。有时候，当它没有I/O任务时，它会“坐下来”等待，直到有东西进来。

5. check (检查阶段): 这个阶段专门用于执行setImmediate()设置的回调函数。

   • 我的理解: setImmediate的回调总是在poll阶段之后，close callbacks之前执行。这使得它非常适合在I/O操作完成后立即执行一些非I/O相关的逻辑。一个常见的例子就是，setImmediate比setTimeout(fn, 0)更早执行，如果它们都在一个I/O回调内部被调用的话。

6. close callbacks (关闭回调阶段): 这个阶段执行一些关闭句柄的回调，比如socket.on('close', ...)这类事件。

   • 我的理解: 顾名思义，就是处理资源关闭后的清理工作。

nextTick和Promise微任务在哪里？它们如何影响事件循环？

这是一个经常让人混淆，但也至关重要的问题。process.nextTick()和Promise的回调（也称作微任务，microtasks）并不属于事件循环的任何一个阶段。它们有自己独立的队列，优先级比事件循环的任何一个阶段都要高。

简单来说，每次事件循环从一个阶段切换到下一个阶段之前，或者说，在当前阶段的任务执行完毕后，Node.js会立即清空微任务队列。这意味着，process.nextTick()的回调会在当前代码执行完毕后、进入下一个事件循环阶段之前，优先得到执行。Promise的回调也是类似，但nextTick的优先级甚至比Promise微任务还要高一点点。

这有什么实际意义呢？举个例子：

console.log('Start');

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

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

Promise.resolve().then(() => {
  console.log('Promise callback');
});

process.nextTick(() => {
  console.log('nextTick callback');
});

console.log('End');

这段代码的输出通常会是：

Start
End
nextTick callback
Promise callback
setTimeout callback  // 或者 setImmediate callback，取决于I/O和系统负载
setImmediate callback // 或者 setTimeout callback

（注意：setTimeout(0)和setImmediate的顺序在没有I/O时是不确定的，但在I/O回调内部，setImmediate会优先于setTimeout(0)执行）。

从输出可以看出，nextTick和Promise的回调在同步代码执行完毕后，但在任何宏任务（如setTimeout或setImmediate）开始之前就已经执行了。它们像是插队者，总是在当前任务和下一个宏任务之间寻找机会执行。理解这一点，对于处理需要“立即”执行但又不能阻塞当前同步代码的逻辑，或者需要确保在下一个事件循环周期前完成某些操作的场景，至关重要。我个人就经常利用nextTick来确保某些清理或初始化操作在当前栈清空后、但又在任何异步I/O之前执行，这能有效避免一些竞态条件。

今天关于《Node.js事件循环6大阶段解析》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！