5.1. 定时器

定时器规定了回调被执行的时间间隔的临界值，而不是准确的值。定时器回到会在一定时间过去之后执行，当然，操作系统调度 或者 其他的回调可能会使得他们被延迟。

注意：技术上来说，轮询阶段控制着 什么时候定时器会被执行。

举例来说，你安排了一个在100ms以后的定时器，之后你的脚本启动了并且异步的读取一个文件内容，消耗95ms。

const fs = require('fs');

function someAsyncOperation(callback) {
  // Assume this takes 95ms to complete
  fs.readFile('/path/to/file', callback);
}

const timeoutScheduled = Date.now();

setTimeout(() => {
  const delay = Date.now() - timeoutScheduled;

  console.log(`${delay}ms have passed since I was scheduled`);
}, 100);


// do someAsyncOperation which takes 95 ms to complete
someAsyncOperation(() => {
  const startCallback = Date.now();

  // do something that will take 10ms...
  while (Date.now() - startCallback < 10) {
      // do nothing
  }
});

当事件循环进入到轮询 阶段后，有一个空队列（ fs.readFile() 还没完成），所以会等待一段时间直到最近的定时器临界值到达。当它等待了95ms之后。fs.readFile() 结束了读取数据，他的回调需要消耗10ms去完成，这个回调会被添加到 轮询队列并且被执行。完成后，没有更多在队列中的回调了，所以事件循环会去查看最近的定时器，并且重新循环到 定时器 阶段 去执行定时器回调。

在这个例子中，你可以看到定时器被执行实际上是在 105ms。

注意：为了阻止轮询阶段一直占用事件循环，libuv 有一个硬编码的最大的值（系统相关），来限定轮询阶段获取更多的事件。

5.2. 等待的回调

这个阶段会去执行一些系统操作相关的回调，比方说 TCP 错误。举例来说， 如果TCP socket 在尝试连接的时候接收到了 ECONNREFUSED ，一些*nix 系统会等待汇报这个错误。他们会在等待的回调阶段 被执行

5.3. 轮询

轮询阶段主要有两个功能：

1. 计算他应该阻塞多长时间 并且 轮询 I/O， 然后
2. 处理在轮询队列中的事件。

当事件循环进入到 轮询阶段 并且没有定时器时，会发生两件事情：

• 如果 轮询队列不为空，时间循环会一次执行回调队列中的回调 直到队列为空， 或者依赖系统的 硬编码的时间限制。
• 如果队列为空，那么会有更多的两件事情发生：
  • 如果脚本设定了 setImmediate() ，那么事件循环会结束 轮询阶段 并且进入到 检查阶段 去执行这些设定的脚本
  • 如果脚本没有安排 setImmediate() ，事件循环会去等待回调被加入到队列中，然后立即去执行。

一旦轮询队列为空，事件循环就会去检查哪些定时器到达了临界值， 如果有一个或者多个定时器准备好了， 那么事件循环就循环回去执行 定时器阶段的回调。

5.4. 检查

这一阶段允许我们在 轮询阶段 结束之后立马执行回调。如果 轮询阶段为空 并且脚本 设定了 setImmediate() ，那么事件循环会继续执行检查阶段 而不是等待。

setImmediate() 实际上是一种运行在事件循环 不同阶段的特殊定时器。它使用 libuv 的API 来设定在 轮询阶段完成后的回调。

总体来说，当代码运行后，事件循环最终会到达 轮询阶段，这个阶段回去等待接入的连接、请求等等。当然，如果使用 ·setImmediate() 安排了一个回调，并且 轮询阶段为空，那么 轮询阶段就会结束并且进入到检查阶段，而不是在轮询阶段等待。

5.5. 关闭的回调

如果一个socket 或者处理函数 被强制关闭 （比方说 socket.destroy() ）, 'close' 事件会在这个阶段被触发。否则的话他们会在 process.nextTick() 阶段触发。

7.1. 理解 process.nextTick()

你可能已经注意到了， process.nextTick() 并不在图中， 虽然他是 异步 API 的一部分。这是因为 process.nextTick() 并不是 事件循环中的一部分。 实际上，无论处在那一个事件循环阶段， nextTickQueue 会在当前的操作完成后，立马被执行。

重新看一下之前的图，任何时候你调用 process.nextTick() ，他都会被立马执行。这会造成一些很坏的情况 因为这样会允许你用循环的 process.nextTick() 去阻塞 I/O 。这意味着 事件循环不会到达轮询阶段。

7.2. 为什么这样被允许？

为什么这样的事情在 Node.js 中会被允许？部分的原因是因为 这样的一种设计思路：API 应当总是被异步执行，即使并不需要。 我们通过下面的代码片段来查看：

function apiCall(arg, callback) {
  if (typeof arg !== 'string')
    return process.nextTick(callback,
                            new TypeError('argument should be string'));
}

此处的代码片段会做一个简单的参数检测，如果不对的话，会给回调抛出一个异常。这个 API 最近进行了更新，可以传递参数给 process.nextTick() 来传给回调，这样就不需要函数嵌套了。

我们所做的就是 传递一个错误 给用户，但是需要在我们允许其他代码被执行的情况下。 利用 process.nextTick() 我们保证了 apiCall() 在其他代码被执行之后、事件循环继续之前 总是会运行回调。为达到这个效果，JS 调用栈 被允许 展开 然后 立马执行 提供的回调，这样就能够递归调用 process.nextTick() 而不会产生 RangeError: Maximum call stack size exceeded from v8 的错误。

这种哲学可能会产生一些潜在的问题，以下面的代码片段为例：

let bar;

// this has an asynchronous signature, but calls callback synchronously
function someAsyncApiCall(callback) { callback(); }

// the callback is called before `someAsyncApiCall` completes.
someAsyncApiCall(() => {
  // since someAsyncApiCall has completed, bar hasn't been assigned any value
  console.log('bar', bar); // undefined
});

bar = 1;

用户定义的 someAsyncApiCall() 包含了一些异步的标志，但实际上是一个同步的操作。当它被调用时，提供的回调 会在同一个事件循环阶段被调用 因为 someAsyncApiCall() 实际上并不是异步操作。结果是，回调读取 bar 的值，然后他并不在当前作用域，因为脚本还没有完成。

在回调中 加入 process.nextTick() ，脚本仍然能被执行完，使得所有的变量 函数 等等 被优先初始化。这样做的另一个好处是，不允许事件循环 继续。 这对某些 需要警告错误的用户来说很有用。 这边是之前的例子 process.nextTick() 。（因为需要完成当前的操作才会切换到 process.nextTick() ）

let bar;

function someAsyncApiCall(callback) {
  process.nextTick(callback);
}

someAsyncApiCall(() => {
  console.log('bar', bar); // 1
});

bar = 1;

这是另一个例子：

const server = net.createServer(() => {}).listen(8080);

server.on('listening', () => {});

只有当一个端口被传递之后，才会立马绑定。 所以 listening 能够被立马调用。 问题是， .on('listening') 回调还没有被设定。

为了解决这个问题， listening 会被放在 netxTick() 中 以允许当前的代码运行完毕。这使得用户能够随意的设定事件处理函数。

7.3. process.nextTick() 与 setImmediate()

用户可能会很疑虑，因为我们 有两个调用很相似，但他们的名字却很混乱：

• process.nextTick() 会在相同的阶段 立马被执行
• setImmediate() 会在事件循环的下一个阶段 或者 时钟 执行

实际上，这两个名字应当替换的，因为 process.nextTick() 比起 setImmediate() 会更快的执行，但这是以前的产物，不大可能被改变。 如果要做改变的话 可能会使得大部分的 NPM 包跟着修改。 每天都有更多的新模块被添加，这意味着 每过一天，更多可能的损坏会发生。 所以 即使他们令人困惑，名字本身不会改变。

我们推荐开发者使用 setImmediate() ， 因为者更容易理解 (这使得代码的兼容性也更好，比方说浏览器 JS)。

7.4. 为什么我们使用 process.nextTick()

主要有两个原因：

1. 使得用户能够处理错误，清理不需要的资源， 或者 在事件循环继续之前重新的 请求资源。
2. 有些时候 需要使得回调能够在 事件循环继续之前 在 调用栈上被展开。

一个例子 就是符合用户的预期。简单的例子：

const server = net.createServer();
server.on('connection', (conn) => { });

server.listen(8080);
server.on('listening', () => { });

listen() 在事件循环的一开始就被执行了， 但是事件循环的回调被安排在了 setImmediate() 中，除非一个 主机名 被传递，否则端口绑定会立马执行。当 事件循环继续时，最终会到达 轮询阶段，这就意味着，有非0的概率发生这样的情况：已经接收到了连接 但是 连接事件却仍然没有被触发。

另一个例子就是 运行一个构造函数，继承自 EventEmitter ，他想在构造函数中调用事件。

const EventEmitter = require('events');
const util = require('util');

function MyEmitter() {
  EventEmitter.call(this);
  this.emit('event');
}
util.inherits(MyEmitter, EventEmitter);

const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
  console.log('an event occurred!');
});

你不能立马在构造函数中发出事件，因为脚本不会到达 用户指定回调事件的点。所以，在一个构造函数内部，你可以使用 process.nextTick() 去设定一个回调函数，并且在构造函数结束时发出事件，这样就能取得期望的结果。

const EventEmitter = require('events');
const util = require('util');

function MyEmitter() {
  EventEmitter.call(this);

  // use nextTick to emit the event once a handler is assigned
  process.nextTick(() => {
    this.emit('event');
  });
}
util.inherits(MyEmitter, EventEmitter);

const myEmitter = new MyEmitter();
myEmitter.on('event', () => {
  console.log('an event occurred!');
});