Node.js事宜轮回事情流程&生命周期

本文，将会细致的解说 node.js 事宜轮回事变流程和生命周期

一些罕见的误会

在 js 引擎内部的事宜轮回

最罕见的误会之一，事宜轮回是 Javascript 引擎（V8,spiderMonkey等）的一部份。事实上事宜轮回主要应用 Javascript 引擎来实行代码。

有一个栈或许行列

起首没有栈，其次这个历程是庞杂的，有多个行列（像数据结构中的行列）介入。然则大多数开辟者晓得若干有的回调函数被推动一个单一的行列内里，是完整毛病的。

事宜轮回运转在一个零丁的线程内里

由于毛病的 node.js 事宜轮回图，我们中有一部份人以为u有两个线程。一个实行 Javascript，另一个实行事宜轮回。事实上都在一个线程内里运转。

在 setTimeout 中有异步的 OS 的体系介入

另一个异常大的误会是 setTimeout 的回调函数在给定的耽误完成以后被（多是 OS 或许 内核）推动一个行列。

setImmediate 将回调函数放在第一个位置

作为罕见的事宜轮回形貌只要一个行列；所以一些开辟者以为 setImmediate 将回调放在事变行列的前面。这是完整毛病的，在 Javascript 的事变行列都是先进先出的。

事宜轮回的架构

在我们最先形貌事宜轮回的事变流程时，晓得它的架构异常主要。下图为事宜轮回真正的事变流程：

图中差别的盒子代表差别的阶段，每一个阶段实行特定的事变。每一个阶段都有一个行列（这里说成行列主要是为了更好明白；实在的数据结构可以不是行列），Javascript 可以在任何一个阶段实行（除了 idle & prepare）。你在图片中也能看到 nextTickQueue 和 microTaskQueue，它们不是轮回的一部份，它们当中的回调可以在恣意阶段实行。它们有更高的优先级去实行。

如今你晓得了事宜轮回是差别阶段和差别行列的连系；下面是每一个阶段的形貌。

定时器（Timer）阶段

这个是事宜轮回最先的阶段，绑定到这个阶段的行列，保存着定时器（setTimeout, setInterval）的回调，只管它并没有将回调推入行列中，然则以最小的堆来坚持计时器而且在抵达划定的事宜后实行回调。

悬而未决的（Pending）I/O 回调阶段

这个阶段实行在事宜轮回中 pending_queue 里的回调，这些回调时被之前的操纵推入的。比方当你尝试往 tcp 中写入一些东西，这个事变完成了，然后回调被推入到行列中。毛病处置惩罚的回调也在这里。

Idle, Prepare 阶段

只管名字是余暇（idle），然则每一个 tick 都运转。Prepare 也在轮询阶段最先之前运转。不管怎样，这两个阶段是 node 主要做一些内部操纵的阶段。

轮询（Poll）阶段

可以全部事宜轮回最主要的一个阶段就是 poll phase。这个阶段接收新传入的衔接（新的 Socket 建立等）和数据（文件读取等）。我们可以将轮询阶段分红几个差别的部份。

1. 假如在 watch_queue （这个行列被绑定到轮询阶段）有东西，它们将会被一个接着一个的实行晓得行列为空或许体系到达最大的限定。
2. 一旦行列为空，node 就会守候新的衔接。守候或许就寝的事宜取决于多种要素。

搜检（Check）阶段

轮询的下一个阶段是 check pahse，这个专用于 setImmediate 的阶段。为何须要一个特地的行列来处置惩罚 setImmediate 回调？这是由于轮询阶段的行动，待会儿将在流程部份议论。如今只须要记着搜检（check）阶段主要处置惩罚 setImmediate() 的回调。

封闭（Close）回调

回调的封闭（stocket.on(&＃8216;close&＃8217;, () => {})）都在这里处置惩罚的，更像一个清算阶段。

nextTickQueue & microTaskQueue

nextTickQueue 中的使命保存在被 process.nextTick() 触发的回调。 microTaskQueue 保存着被 Promise 触发的回调。它们都不是事宜轮回地一部份（不是在 libUV 中开辟地），而是在 node 中。在 C/C++ 和 Javascript 有交织的时刻，它们都是尽量快地被挪用。因而它们应当在当前操纵运转后（不一定是当前 js 回调实行完）。

事宜轮回地事变流程

当在你的控制台运转 node my-script.js ，node 设置事宜轮回然后运转你主要的模块（my-script.js）事宜轮回的外部。一旦主要模块实行完，node 将会搜检轮回是不是还在世（事宜轮回中是不是另有事变要做）？假如没有，将会在实行退出回调后退出。process, on(&＃8216;exit&＃8217;, foo) 回调（退出回调）。然则假如轮回还在世，node 将会从计时器阶段进入轮回。

计时器阶段（Timer phase）的事变流程

事宜轮回进入计时器阶段而且搜检在计时器行列中是不是有须要实行的。好吧，这句话听起来异常简朴，然则事宜轮回实际上要实行一些步骤发明适宜的回调。实际上计时器剧本以升序储存在堆内存中。它起首猎取到一个实行计时器，计算下是不是 now-registeredTime == delta？假如是，他会实行这个计时器的回调而且搜检下一个计时器。直到找到一个还没有商定时候的计时器，它会住手搜检其他的定时器（由于定时器都以升序排好了）而且移到下一个阶段了。
假定你挪用了 setTimeout 4次创建了4个定时器，离别相对于时候 t 来讲 100，200，300，400 的差值。

假定事宜轮回在 t+250 进入到了计时器阶段。它会起首看下计时器 A，A 的逾期时候是 t+100。然则如今时候是 t+250。因而它将实行绑定在计时器 A 上的回调。然后去搜检计时器 B，发明它的逾期时候是 t+200，因而也会实行 B 的回调。如今它会搜检 C，发明它的逾期时候是 t+300，因而将会脱离它。时候轮回不会去搜检 D，由于计时器是按升序拍好的；因而 D 的阈值比 C 大。但是这个阶段有一个体系相干的硬限定，假如到达体系依靠最大限定数目，纵然有未实行的计时器，它也会移到下一个阶段。

悬而未决（Pengding phase）的 I/O 阶段事变流程

计时器阶段后，事宜轮回将会进入到了悬而未决的 I/O 阶段，然后搜检一下 pengding_queue 中是不是有来自于之前的悬而未决的使命的回调。假如有，一个接一个的实行，直到行列为空，或许到达体系的最大限定。以后，事宜轮回将会移到 idle handler 阶段，其次是预备阶段做一些内部的操纵。然后终究可以进入到最主要的阶段 poll phase。

轮询阶段（Poll phase）事变流程

像名字说的那样，这是一个视察的阶段。视察是不是有新的要求或许衔接传入。当事宜轮回进入轮询阶段，它会在 watcher_queue 中实行剧本，包括文件读相应，新的 socket 或许 http 衔接要求，直到事宜耗尽或许像其他阶段那样到达体系依靠上限。假定没有要实行的回调，轮询在某些特定的条件下将会守候一会儿。假如在搜检行列（check queue），悬而未决行列（pending queue），或许封闭行列（closing callbacks queue 或许 idle handler queue）内里有任何使命守候，它将守候 0 毫秒。然后它会依据定时器堆来决议守候时候实行第一个定时器（假如可猎取）。假如第一个定时器阈值经过了，毫无疑问它不须要守候（就会实行第一个定时器）。

搜检阶段（Check phase）事变流程

轮询阶段完毕以后，立时来到搜检阶段。这个阶段的行列中有被 api setImmediate 触发的回调。它将会像其他阶段那样一个接着一个的实行，直到行列为空或许到达依靠体系的最大限定。

封闭回调（Close callback）的事变流程

完成在搜检阶段的使命以后，事宜轮回的下一个目的地是处置惩罚封闭或许烧毁范例的回调 close callback。事宜轮回实行完这个阶段的行列中的回调后，它会搜检轮回（loop）是不是还在世，假如没有，退出。然则假如另有事变要做，它会进入下一个轮回；因而在计时器阶段。假如你以为之前例子中的定时器（A & B）逾期，那末如今定时器阶段将会从定时器 C 最先搜检是不是逾期。

nextTickQueue & microTaskQueue

因而，这两个行列的回调函数什么时刻运转？它们固然在从当前阶段到下一个阶段之前尽量快的运转。不像其他阶段，它们两个没有体系依靠的醉倒限定，node 运转它们直到两个行列是空的。但是，nextTickQueue 会比 microTaskQueue 有着更高的使命优先级。

历程池（Thread-pool）

我从 Javascript 开辟者那里听到广泛的一个词就是 ThreadPool。一个广泛的误会是，nodejs 有一个处置惩罚一切异步操纵的历程池。然则实际上历程池是 libUV （nodejs用来处置惩罚异步的第三方库）库中的。之所以没有在图中画出来，是由于它不是轮回机制的一部份。现在，并非每一个异步使命都会被历程池处置惩罚的。libUV 可以天真运用操纵体系的异步 api 来坚持环境为事宜驱动。但是操纵体系的 api 不能做文件读取，dns 查询等，这些由历程池来处置惩罚，默许只要 4 个历程。你可以经由过程设置 uv_threadpool_size 的环境变量增添历程数直到 128.

带有示例的事变流程

愿望你能明白事宜轮回是怎样事变的。C 言语 中同步的 while 协助 Javascript 成为异步的。每次只处置惩罚一件事然则很呐壅塞。固然，不管我们假如形貌理论，最好的明白照样示例，因而，让我们经由过程一些代码片断来明白这个剧本。

片断1—基本明白

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

你可以猜到上面的输出吗？好吧，你可以以为 setTimeout 会先被打印出来，然则不能保证，为何呢？实行完主模块以后进入计时器阶段，他可以不会或许会发明你的计时器耗尽了。为何呢？一个计时器剧本是依据体系时候和你供应的增量时候注册的。setTimeout 挪用的同时，计时器剧本被写入到了内存中，依据你的机械机能和其他运转在它上面的操纵（不是node）的差别，可以会有一个很小的耽误。另一点时，node仅仅在进入计时器阶段（每一轮遍历）之前设置一个变量 now，将 now 作为当前时候。因而你可以说相当于准确的时候有点题目。这就是不确定性的缘由。假如你在一个计时器代码的回调内里指向雷同的代码会获得雷同的效果。

但是，假如你挪动这段代码到 i/o 周期里，保证 setImmediate 回调会先于 setTimeout 运转。

fs.readFile('my-file-path.txt', () => {
setTimeout(() => {console.log('setTimeout');}, 0);
setImmediate(() => {console.log('setImmediate');}); });

片断2 — 更好的明白计时器

var i = 0;
var start = new Date();
function foo () {
i++;
if (i <1000) {
setImmediate(foo);
} else {
var end = new Date();
console.log("Execution time: ", (end - start));
}
}
foo();

上面的例子异常简朴。挪用函数 foo 函数内部再经由过程 setImmediate 递归挪用 foo 直到 1000。在我的电脑上面，也许消费了 6 到 8 毫秒。仙子啊修改下上面的代码，把 setImmedaite(foo) 换成 setTimeout(foo, o)。

var i = 0;
var start = new Date();
function foo () {
i++;
if (i <1000) {
setTimeout(foo, 0);
} else {
var end = new Date();
console.log("Execution time: ", (end - start));
}
}
foo();

如今在我的电脑上面运转这段代码消费了 1400+ms。为何会如许？它们都没有 i/o 事宜，应当一样才对。上面两个例子守候事宜是 0.为何消费这么长时候？经由过程事宜比较找到了误差，CPU 密集型使命，消费更多的时候。注册计时器剧本也消费事宜。定时器的每一个阶段都须要做一些操纵来决议一个定时器是不是应当实行。长时候的实行也会致使更多的 ticks。但是，在 setImmediate 中，只要搜检这一个阶段，就好像在一个行列内里然后实行就好了。

片断3 — 明白 nextTick() & 计时器(timer)实行

var i = 0;
function foo(){
i++;
if (i>20) return;
console.log("foo");
setTimeout(()=>console.log("setTimeout"), 0);
process.nextTick(foo);
}
setTimeout(foo, 2000);

你以为上面输出是什么？是的，它会输出 foo 然后输出 setTimeout。2秒后被 nextTickQueue 递归挪用 foo() 打印出第一个 foo。当一切的 nextTickQueue 实行完了，最先实行其他（比方 setTimeout 回调）的。

所以是每一个回调实行完以后，最先搜检 nextTickQueue 的吗？ 我们改下代码看下。

var i = 0;
function foo(){
i++;
if (i>20) return;
console.log("foo");
setTimeout(()=>console.log("setTimeout"), 0);
process.nextTick(foo);
}
setTimeout(foo, 2000);
setTimeout(()=>{console.log("Other setTimeout"); }, 2000);

在 setTimeout 以后，我仅仅用一样的耽误时候添加了另一个输出 Other setTimeout 的 setTimeout。只管不能保证，然则有可以会在输出第一个 foo 以后输出 Other setTimeout 。雷同的定时器分为一个组，nextTickQueue 会在正在进行中的回调组实行完以后实行。

一些广泛的题目

Javascript 代码在那里实行的？

就像我们大多数人都以为事宜轮回是在一个零丁的线程内里，将回调推入一个行列，然后一个接着一个实行。第一次读到这篇文章的读者可以会觉得迷惑，Javascript 在那里实行的？正如我早些时刻说的，只要一个线程，来自于自身运用 V8 或许其他引擎的事宜轮回的 Javascript 代码也是在这里运转的。实行是同步的，假如当前的 Javascript 实行还没有完成，事宜轮回不会流传。

我们有了 setTimeout(fn, 0)，为何还须要 setImmediate？

起首不是0，而是1.当你设置一个计时器，时候为小于 1，或许大于 2147483647ms 的时刻，它会自动设置为 1.因而你假如设置 setTimeout 的耽误时候为 0，它会自动设置为1.

另外，setImmediate 会削减分外的搜检。因而 setImmediate 会实行的更快一些。它也安排在轮询阶段以后，因而来自于任何一个到来的要求 setImmediate 回调将会立时被实行。

为何 setImmediate 会被明白挪用？

setImmediate 和 process.nextTick() 都定名错了。所以功能上，setImmediate 鄙人一个 tick 实行，nextTick 是立时实行的。

Javascript 代码会被壅塞吗？

由于 nextTickQueue 没有回调实行的限定。因而假如你递归地实行 process.nextTick()，你地顺序可以永久在事宜轮回中出不来，不管你在其他阶段有什么。

假如我在 exit callback 阶段挪用 setTimeout 会怎样？

它可以会初始化计时器，但回调可以永久不会被挪用。由于假如 node 在 exit callback 阶段，它已跳出事宜轮回了。因而没有归去实行。

一些短地结论

事宜轮回没有事变栈

事宜轮回不在一个零丁地线程内里，Javascript 的实行也不是像从行列中弹出一个回调实行那末简朴。

setImmediate 没有将回调推入到事变行列地头部，有一个特地的阶段和行列。

setImmediate 鄙人一个轮回实行，nextTick 实际上是立时实行。

小心，假如递归挪用的话，nextTickQueue 可以会壅塞你的 node 代码。