首页 >web前端 >js教程 >关于Node中事件循环的解析

关于Node中事件循环的解析

不言原创: 2018-07-20 10:30:001338浏览

这篇文章给大家介绍的内容是关于Node中事件循环的解析，有着一定的参考价值，有需要的朋友可以参考一下。

事件循环中的各阶段

Node.js 的事件循环流程大致如下：

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

每个阶段都有自己的任务队列，当本阶段的任务队列都执行完毕，或者达到了执行的最大任务数，就会进入到下一个阶段。

timers 阶段

这个阶段会执行被 setTimeout 和 setInterval 设置的定时任务。
当然，这个定时并不是准确的，而是在超过了定时时间后，一旦得到执行机会，就立刻执行。

pending callbacks 阶段

这个阶段会执行一些和底层系统有关的操作，例如TCP连接返回的错误等。这些错误发生时，会被Node 推迟到下一个循环中执行。

轮询阶段

这个阶段是用来执行和 IO 操作有关的回调的，Node会向操作系统询问是否有新的 IO 事件已经触发，然后会执行响应的事件回调。几乎所有除了定时器事件、 setImmediate() 和 close callbacks 之外操作都会在这个阶段执行。

check 阶段

这个阶段会执行 setImmediate() 设置的任务。

close callbacks 阶段

如果一个 socket 或 handle(句柄) 突然被关闭了，例如通过 socket.destroy() 关闭了，close 事件将会在这个阶段发出。

事件循环的具体执行

事件循环初始化之后，会按照上图所示的流程进行：

首先会依次执行定时器中的任务、 pending callback 回调；
然后进入到 idle 、 prepare 阶段，这里会执行 Node 内部的一些逻辑；
然后进入到 poll 轮询阶段。在这个阶段会执行所有的 IO 回调，如读取文件，网络操作等。 poll 阶段有一个 poll queue 任务队列。这个阶段的执行过程相对较长，具体如下：

进入到本阶段，会先检查 timeout 定时队列是否有可执行的任务，如果有，会跳转到 定时器阶段 执行。
如果没有 定时器任务 ，就会检查 poll queue 任务队列，如果不为空，会遍历执行所有任务直到都执行完毕或者达到能执行的最大的任务数量。
poll queue 任务队列执行完成后，会检查 setImmediate 任务队列是否有任务，如果有的话，事件循环会转移到下一个 check 阶段。
如果没有 setImmediate 任务，那么，Node 将会在此等待，等待新的 IO 回调的到来，并立刻执行他们。

注意 :这个等待不会一直等待下去，而是达到一个限定条件之后，继续转到下一个阶段去执行。

`setTimeout()` 和 `setImmediate()`

一个小秘密

其实也不算秘密，只是我是在刚刚查阅资料才知道的。
那就是：在 Node 中，setTimeout(callback, 0) 会被转换为 setTimeout(callback, 1) 。
详情请参考这里。

`setTimeout()` 和 `setImmediate()` 的执行顺序

下面这两个定时任务执行的顺序在不同情况下，表现不一致。

setTimeout(function() {
    console.log(&#39;timeout&#39;);
}, 0);

setImmediate(function() {
    console.log(&#39;immediate&#39;);
});

普通代码中设置定时器

如果在普通的代码执行阶段(例如在最外层代码块中)，设置这两个定时任务，他们的执行顺序是不固定的。

首先，我们设置的 setTimeout(callback, 0) 已经被转换成为 setTimeout(callback, 1) ，所以进入 定时器 阶段时，会根据当前时间判断定时是否超过了 1ms 。
事件循环在进入定时器阶段之前会由系统调用方法来更新当前时间，由于系统中同时运行着其他的程序，系统需要等待其他程序的进程运行结束才能获取准确时间，所以更新得到的时间可能会有一定的延迟。
更新时间时，若没有延迟，定时不到 1ms ,immediate 任务会先执行；如果存在延迟，并且这个时间达到了 1ms 的界限， timeout 任务就会首先执行。

在IO回调中设置定时器

如果我们在 IO 回调中设置了这两个定时器，那么 setImmediate 任务会首先执行，原因如下：

进入 poll phase 轮询阶段之前会先检查是否有 timer 定时任务。
如果没有 timer 定时任务，才会执行后面的 IO 回调。
我们在 IO 回调中设置 setTimeout 定时任务，这时已经过了 timer 检查阶段，所以 timer 定时任务会被推迟到下一个循环中执行。

`process.nextTick()`

无论在事件循环的哪个阶段，只要使用 process.nextTick() 添加了回调任务，Node 都会在进入下一阶段之前把 nextTickQueue 队列中的任务执行完。

setTimeout(function() {
    setImmediate(() => {
        console.log('immediate');
    });
    process.nextTick(() => {
        console.log('nextTick');
    });
}, 0);
// nextTick
// immediate

上述代码中,总是先执行 nextTick 任务，就是因为在循环在进入下一个阶段之前会先执行 nextTickQueue 中的任务。下面代码的执行结果也符合预期。

setImmediate(() => {
    setTimeout(() => {
        console.log('timeout');
    }, 0);
    process.nextTick(() => {
        console.log('nextTick');
    });
});
// nextTick
// timeout