深入浅析Node.js 事件循环、定时器和process.nextTick()

什么是事件循环

尽管javascript是单线程的，但通过尽可能将操作放到系统内核执行，事件循环允许node.js执行非阻塞i/o操作。

由于现代大多数内核都是多线程的，因此它们可以处理在后台执行的多个操作。 当其中一个操作完成时，内核会告诉node.js，以便可以将相应的回调添加到 轮询队列 中以最终执行。 我们将在本主题后面进一步详细解释。

事件循环解释

当node.js启动时，它初始化事件循环，处理提供的输入脚本（或放入 repl ，本文档未涉及），这可能会进行异步api调用，调度计时器或调用 process.nexttick() ， 然后开始处理事件循环。

下图显示了事件循环操作顺序的简要概述。

   ┌───────────────────────────┐
┌─>│           timers          │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │     pending callbacks     │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
│  │       idle, prepare       │
│  └─────────────┬─────────────┘      ┌───────────────┐
│  ┌─────────────┴─────────────┐      │   incoming:   │
│  │           poll            │<─────┤  connections, │
│  └─────────────┬─────────────┘      │   data, etc.  │
│  ┌─────────────┴─────────────┐      └───────────────┘
│  │           check           │
│  └─────────────┬─────────────┘
│  ┌─────────────┴─────────────┐
└──┤      close callbacks      │
   └───────────────────────────┘

注意：每个框都将被称为事件循环的“阶段”。

每个阶段都要执行一个fifo的回调队列。 虽然每个阶段都有其特殊的方式，但通常，当事件循环进入给定阶段时，它将执行特定于该阶段的任何操作，然后在该阶段的队列中执行回调，直到队列耗尽或最大回调数量为止 。 当队列耗尽或达到回调限制时，事件循环将移至下一阶段，依此类推。

由于这些操作中的任何一个可以调度更多操作并且在轮询阶段中处理的新事件由内核排队，因此轮询事件可以在处理轮询事件时排队。 因此，长时间运行的回调可以允许轮询阶段运行的时间比计时器的阈值长得多。 有关详细信息，请参阅和部分。

注意：windows和unix / linux实现之间存在轻微差异，但这对于此演示并不重要。 最重要的部分在这里。 实际上有七到八个步骤，但我们关心的是 - node.js实际使用的那些 - 是上面那些。

阶段概述

• timer : 此阶段执行 settimeout() 和 setinterval() 调度的回调
• pending callbacks : 执行延迟到下一个循环迭代的i/o回调
• idle, prepare : 只用于内部
• poll : 检索新的i/o事件; 执行与i/o相关的回调（几乎所有回调都是带有异常的 close callbacks ， timers 和 setimmediate() 调度的回调）; node将在适当的时候阻塞在这里
• check : 这里调用 setimmediate() 回调函数
• close callbacks : 一些 close callbacks, 例如. socket.on(‘close', …)
  

在事件循环的每次运行之间，node.js检查它是否在等待任何异步i / o或定时器，如果没有，则关闭。

阶段细节

定时器（timer）

计时器在一个回调执行完之后指定阈值，而不是人们希望的确切时间去执行。 定时器回调将在指定的时间过去后尽早安排; 但是，操作系统调度或其他回调的运行可能会延迟它们。

注意：从技术上讲，控制何时执行定时器。

例如，假设您计划在100毫秒后执行 timeout ，然后您的脚本将异步读取一个耗时95毫秒的文件：

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() 尚未完成），因此它将等待剩余的ms数，直到达到最快的计时器阈值。 当它等待95毫秒传递时， fs.readfile() 完成读取文件，并且其完成需要10毫秒的回调被添加到轮询队列并执行。 当回调结束时，队列中不再有回调，因此事件循环将看到已达到最快定时器的阈值，然后回绕到定时器阶段以执行定时器的回调。 在此示例中，您将看到正在调度的计时器与正在执行的回调之间的总延迟将为105毫秒。

注意：为了防止轮询阶段使事件循环挨饿，libuv（实现node.js事件循环的c库和平台的所有异步行为）在停止轮询之前也为事件提供了固定的最大值（取决于系统）。

等待回调（pending callbacks）

此阶段执行某些系统操作（例如tcp错误类型）的回调。 例如，如果tcp套接字在尝试连接时收到 econnrefused ，则某些*nix系统希望等待报告错误。 这将排队等待在等待回调阶段执行。

轮询（poll）

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

1.计算它阻塞和轮询i / o的时间，然后
2.处理轮询队列中的事件。

当事件循环进入轮询阶段并且没有定时器调度时，将发生以下两种情况之一：

• 如果轮询队列不为空，则事件循环将遍历回调队列并且同步执行，直到队列已执行完或者达到系统相关的固定限制。
• 如果轮询队列为空，则会发生以下两种情况之一：

setimmediate()
setimmediate()

检查（check）

此阶段允许在轮询阶段完成后立即执行回调。 如果轮询阶段变为空闲并且脚本已使用 setimmediate() 排队，则事件循环可以继续到检查阶段而不是等待。

setimmediate() 实际上是一个特殊的计时器，它在事件循环的一个单独阶段运行。 它使用libuv api来调度在轮询阶段完成后执行的回调。

通常，在执行代码时，事件循环最终会到达轮询阶段，它将等待传入连接，请求等。但是，如果已使用 setimmediate() 调度回调并且轮询阶段变为空闲，则 将结束并继续检查阶段，而不是等待轮询事件。

关闭回调（close callbacks）

如果套接字或句柄突然关闭（ 例如socket.destroy() ），则在此阶段将发出 'close' 事件。 否则它将通过 process.nexttick() 发出。

setimmediate() vs settimeout()

setimmediate 和 settimeout() 类似，但根据它们的调用时间以不同的方式运行。

setimmediate()
settimeout()

执行定时器的顺序将根据调用它们的上下文而有所不同。 如果从主模块中调用两者，则时间将受到进程性能的限制（可能受到计算机上运行的其他应用程序的影响）。

例如，如果我们运行不在i / o周期内的以下脚本（即主模块），则执行两个定时器的顺序是不确定的，因为它受进程性能的约束：

// timeout_vs_immediate.js
settimeout(() => {
 console.log('timeout');
}, 0);
setimmediate(() => {
 console.log('immediate');
});
$ node timeout_vs_immediate.js
timeout
immediate
$ node timeout_vs_immediate.js
immediate
timeout

但是，如果在i / o周期内移动两个调用，则始终首先执行立即回调：

// timeout_vs_immediate.js
const fs = require('fs');
fs.readfile(__filename, () => {
 settimeout(() => {
 console.log('timeout');
 }, 0);
 setimmediate(() => {
 console.log('immediate');
 });
});
$ node timeout_vs_immediate.js
immediate
timeout
$ node timeout_vs_immediate.js
immediate
timeout

使用 setimmediate() 而不是 settimeout() 的主要优点是 setimmediate() 将始终在任何定时器之前执行（如果在i / o周期内调度），与存在多少定时器无关。

process.nexttick()

理解 process.nexttick()

您可能已经注意到 process.nexttick() 没有显示在图中，即使它是异步api的一部分。 这是因为 process.nexttick() 在技术上不是事件循环的一部分。 相反， nexttickqueue 将在当前操作完成后处理，而不管事件循环的当前阶段如何。

回顾一下我们的图表，无论何时在给定阶段调用 process.nexttick() ，传递给 process.nexttick() 的所有回调都将在事件循环继续之前得到解决。 这可能会产生一些不好的情况， 因为它允许您通过进行递归的 process.nexttick() 调用来“饿死”您的i / o， 这会阻止事件循环到达轮询阶段。

为什么会被允许？

为什么这样的东西会被包含在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 ：超出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() 的回调，因为 someasyncapicall() 实际上不会异步执行任何操作。 因此，回调尝试引用bar，即使它在范围内可能没有该变量，因为该脚本无法运行完成。

通过将回调放在 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' 事件在 nexttick() 中排队，以允许脚本运行完成。 这允许用户设置他们想要的任何事件处理程序。

process.nexttick() vs setimmediate()

就用户而言，我们有两个类似的调用，但它们的名称令人困惑。

process.nexttick()
setimmediate()

实质上，应该交换名称。 process.nexttick() 比 setimmediate() 更快地触发，但这是过去创造的，不太可能改变。 进行此切换会破坏npm上的大部分包。 每天都会添加更多新模块，这意味着我们每天都在等待，更多的潜在破损发生。 虽然它们令人困惑，但自身的叫法不会改变。

我们建议开发人员在所有情况下都使用 setimmediate() ，因为它更容易推理（并且它导致代码与更广泛的环境兼容，如浏览器js。）

为什么要使用 process.nexttick() ？

有两个主要原因：

• 允许用户处理错误，清除任何不需要的资源，或者在事件循环继续之前再次尝试请求。
• 有时需要允许回调在调用堆栈展开之后但在事件循环继续之前运行。
  

一个例子是匹配用户的期望。 简单的例子：

const server = net.createserver();
server.on('connection', (conn) => { });
server.listen(8080);
server.on('listening', () => { });

假设 listen() 在事件循环开始时运行，但是监听回调放在 setimmediate() 中。 除非传递主机名，否则将立即绑定到端口。 要使事件循环继续，它必须达到轮询阶段，这意味着可能已经接收到连接的非零概率允许在侦听事件之前触发连接事件。

另一个例子是运行一个函数构造函数，比如继承自 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!');
});

总结

以上所述是小编给大家介绍的深入浅析node.js 事件循环、定时器和process.nexttick() ，希望对大家有所帮助