深い理解nodejsイベント・ループ・メカニズム

Nodejsブラウザ環境や環境イベント・ループ・メカニズムは、デモでは同じ、初見ではありません。

次のようにブラウザ環境での結果は以下のとおりです。

次のようにnodejs環境での結果は以下のとおりです。

上記の例は、サイクル時間を示し、nodejsブラウザが異なっています。

nodejsイベント処理

nodejsのI / O独自の設計libuvを用いた処理、libuvはイベント駆動型クロスプラットフォーム抽象化層は、統一されたAPIを提供する外部の異なるオペレーティングシステムの基本特性の一部をカプセル化に基づいている間、エンジンを解析JSとしてV8を使用して、イベントループ機構は、その中に実装されているコアコード参照：

Nodejs公式の説明、すべての時間は、イベントループは、以下のチャートでlibuvソースを達成するために対応する、6つのステージが含まれています。

$\bullet$ タイマー段階：この段階コールバックタイマー（のsetTimeout、のsetInterval）の

$\bullet$ I / Oコールバック段階は：そのようなネットワーク通信エラーコールバックのようないくつかのシステムコールエラーを実行します

$\bullet$ アイドルステージを準備する：のみ内部ノードを使用

$\bullet$ 世論調査の段階は：新しいI / Oイベントを取得し、適切な条件下でのノードは、ここにブロックします。

$\bullet$ チェックの段階：コールバック実行setImmediate（）の

$\bullet$ クローズコールバックステージ：近いソケットイベントコールバックの実行を

ほとんどが3つの段階で非同期日々の開発プロセスであるため、これらの三つの段階を確認し、フォーカスタイマー、世論調査を見てください。

タイマー段階

タイマーレギュレータが実行されるのを待っているタイマーのタスクキューに戻ってそれを入れている場合、ノードは、タイマーが満了したかどうかをチェックし、イベントサイクルの最初の段階で、実際には、ノードは、タイマー設定時間を保証するものではありません。期限切れのタイマーのためのノードをチェックしているため、すぐに実行する意志が、それは、マシン上の他の実行中のプログラムによって影響を受ける可能性がある、またはその時点時点で、メインスレッドがアイドルではないが、必ずしもトリッキーではありません。次のコード例、のsetTimeout（）およびsetImmediate（）順序は実行されません。

ステージの裏にはチェックフェーズの世論調査であるので、しかし、I / Oコールバックの内側に入れて、setImmediate（）を実行するためにでなければなりません。

投票相

poll阶段主要有2个功能：

$\bullet$ 处理poll队列的事件

$\bullet$ 当有已超时的timer，执行它的回调函数

event loop将同步执行poll队列里的回调，直到队列为空或执行的回调达到系统上限(上限具体多少未详)，接下来event loop会去检查有无预设的setImmediate()，分两种情况：

1. 若有预设的setImmediate()，event loop将结束poll阶段进入check阶段，并执行check阶段的任务队列。

2. 若没有预设的setImmediate()，event loop将阻塞在该阶段等待。

如果没有setImmediate()将会导致event loop阻塞在poll阶段，这样之前设置的timer岂不是执行不了了？因此在poll阶段event loop会有一个检查机制，检查timer队列是否为空，如果timer队列非空，event loop就开始下一轮事件循环，即重新进入到timer阶段。

check阶段

setImmediate()的回调会被加入到check队列中，从event loop的阶段图可以知道，check阶段的执行顺序会在poll阶段之后。

小结

1. event loop的每个阶段都有一个任务队列。

2. event loop到达某个阶段时，将执行该阶段的任务队列，直到队列清空或执行的回调达到系统上限后，才会转入下一个阶段。

3. 当所有阶段被顺序执行一次后，称event loop完成了一个tick。

通过下面的demo来直观感受：

输出结果如下：

nodejs与浏览器的event loop差异

在浏览器环境下，microtask的任务队列是每个macrotask执行之后执行。

而在nodejs中，microtask会在事件循环的各个阶段之间执行，也就是一个阶段执行完毕，就会去执行microtask队列的任务。

回顾文章最开始的demo，全局脚本（main()）执行，将2个timer依次放入timer队列，main()执行完毕，调用栈空闲，任务队列开始执行。

首先进入timers阶段，执行timer1的回调函数，打印timer1，并将promise1.then回调放入microtask队列，同样的步骤执行timer2，打印timer2。至此timer阶段执行结束，event loop进入下一个阶段之前，执行microtask队列的所有任务，依次打印promise1、promise2。

对比浏览器环境的处理过程：

process.nextTick() VS setImmediate()

In essence, the names should be swapped. process.nextTick() fires more immediately than setImmediate()

上面是来自官网文档的一句话，从语义角度看，setImmediate()应该比process.nextTick()先执行才对，而事实相反，命名是历史原因很难再变。

process.nextTick()会在各个事件阶段之间执行，一旦执行，要直到nextTick队列被清空，才会进入到下一个事件阶段，所有如果递归调用process.nextTick()，会导致出现I/O starving(饥饿)的问题，比如下面例子的readFile已经完成，但它的回调一直无法执行：

process.nextTick()的运行结果：

替换成setImmediate()，运行结果：

这是因为嵌套调用setImmediate()回调，被排到了下一次event loop才执行，所有不会出现阻塞。

总结

1. nodejs的事件循环分为6个阶段

2. 浏览器和node环境下，microtask任务队列的执行时机不同

$\bullet$ nodejs中，microtask在事件循环的各个阶段之间执行

$\bullet$ 浏览器中，microtask在事件循环的macrotask执行之后执行

3. 递归的调用process.nextTick()会导致I/O starving，官方推荐使用setImmediate()

来源：简书，原链接：https://www.jianshu.com/p/2b34a257108d，原作者：ZGC_JO