事件循环是 NodeJS 处理非阻塞 I/O 操作的和核心机制。NodeJS 的事件循环脱胎于 的事件循环，因此，要搞清楚 NodeJS 的事件循环，还需要先了解 libuv 的事件循环是如何工作的。
libuv 的事件循环我们先来了解两个基本概念：句柄（handle）和请求（request）.
句柄是指在整个事件循环活跃时间内能够执行某些操作的长期对象。比如一个 TCP 服务句柄，每当有新的联接建立时，这个句柄的 connected 回调就会被调用。
请求是通常指短期操作。比如向某个句柄中写入数据的操作。
了解了这两个概念以后，我们来看看 libuv 的事件循环是如何工作的。
下面这张图可以清楚的展示事件循环的执行过程：
结合这张图我们简单描述一下一次循环过程中各个步骤做了什么。
首先更新循环内的当前时间（now），避免在循环过程中多次发生与时间相关的系统调用。
检查当前事件循环是否还是活跃（active）的。检查的表示是当前事件循环是否还有活跃的句柄、活跃的请求操作，或者还有“关闭”回调的话，就视为是活跃的。如果判断当前循环不是活跃的，则直接退出。
执行所有的到期回调。即所有的到期时间在循环当前时间之前的回调都会被执行。
执行所有的挂起回调（pending callbacks）。所谓挂起回调，就是在上一个循环周期中设置的到下一循环周期在执行的回调。
执行空闲句柄回调（idle handle callbacks）。虽然名字中包含空闲二字，实际上每个循环周期都会执行。
执行准备句柄回调（prepare handle callbacks）。
在这一步会暂停循环，轮询等待 I/O 事件一段时间。这个时间长度是根据一个算法算出，这里不做详细说明。在轮询期间，所有 I/O 相关的回调会被执行（前提是系统通知到 libuv）。
执行检查句柄回调（check handle callbacks）。检查句柄回调往往与准备句柄回调相对应。这两个回调可以方便我们在 I/O 之前做一些准备工作，然后在 I/O 之后做相应的检查。
执行关闭回调（close callbacks）。比如通过 uv_close() 设置的回调。
整个事件循环就是 1 - 9 的循环执行。
值得说明的是，libuv 会在轮询阶段中断事件循环，等待系统通知。比如某个文件 I/O 已经完成，或者接收到一个网络连接等。在接收到系统通知后，事件循环会调用相关的回调执行操作。
不同的平台（windows\linux 等），异步 I/O 的机制不同，libuv 底层会根据不同平台，采用不同的 I/O 轮询机制，比如 epoll（linux）、kqueue（OSX）、IOCP（windows）等，上层不需要关注异步 I/O 的实现机制。
NodeJS 的事件循环现在我们来看 NodeJS 的事件循环。同样，我们放一张 NodeJS 事件循环的过程图。
在 NodeJS 中，事件循环的每一步成为一个阶段，每个阶段都有一个 FIFO 队列来执行回调。通常情况下，当事件循环进入给定的阶段时，它将执行特定于该阶段的任何操作，然后执行该阶段队列中的回调，直到队列清空或达到最大回调数限制。当队列清空或者达到最大限制，事件循环进入下一阶段。
对比两个事件循环的图，我们可以看到，具体过程基本相同。因此，NodeJS 的事件循环过程我们简述如下：
定时器阶段，执行已经被 setTimeout() 和 setInterval() 调度的回调函数。
挂起的回调，执行（在上一个循环中被设置）延迟到下一个循环迭代的 I/O 回调。
idle, prepare 阶段，仅 NodeJS 系统内部使用。
轮询阶段，检索新的 I/O 事件，执行与 I/O 相关的回调。与 libuv 一样，NodeJS 还在这个阶段暂停循环一段时间。
检测阶段，执行被 setImmediate() 调度的回调函数。
关闭的回调函数，执行一些关闭的回调函数，如：socket.on('close', ...)。
我们对轮询阶段做个详细说明。
轮询阶段有两个重要的功能：
计算应该阻塞和轮询 I/O 的时间。
处理轮询队列里的事件。
一旦事件循环进入轮询阶段并且没有到期的定时器回调时，事件循环将做如下判断：
如果轮询队列不是空的，那么事件循环将循环访问回调队列并同步执行它们，直到清空队列，或者达到了最大限制。
如果轮询队列是空的，则再做如下判断：
如果有代码是被 setImmediate() 调度的，那么事件循环将结束轮询阶段，并到检查阶段以执行那些被调度的代码。
如果没有代码被 setImmediate() 调度，那么事件循环将等待回调被添加到队列中，然后立即执行。