`setimMediate（）`and`settimeout（）的时间如何受过程的性能约束？

Question

我对node.js文档的以下段落感到困惑。

vs 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

我不明白是什么使结果非确定性。由于计时器阶段发生在检查阶段之前，因此不应在 settimeout 安排的回调在由 setimmediate <计划之前始终执行。 /代码>？我认为事件循环中的阶段顺序不会因上下文开关而改变。

该文件还指出

但是，如果您在I/O周期内将两个呼叫移动，则立即回调始终首先执行：

好的，但是什么使所谓的“ I/O周期”与主模块不同？

---

我知道有很多相关的问题，但是所有答案都仅通过引用文档来说明这一事实，而没有解释非确定性的发挥作用，所以我认为这不是重复的。

Answer 1

实际的窍门在 settimeout ，它将时间增加到1到1以下。因此 settimeout（fn，0）实际上等于 settimeout（fn，1）。

---

另一个有趣的观察结果是，在setimmeadepeare之后，多个计时器也可能在和之前运行：

setTimeout(() => console.log('timer'), 1);
setTimeout(() => console.log('timer'), 1);
setImmediate(() => console.log('immediate'));
// can produce:
// timer
// immediate
// timer

这是因为 settimeout 呼叫 getlibuvnow 内部，它将调用 envy> envy> enk - ＆gt; getNow（），它不仅可以获得Libuv的当前时间，而且还可以href =“ https://github.com/nodejs/node/node/blob/5fad0b93667ffc6e4def529996b95299b26319/src/env.cc#l945因此，可能会在不同的到期时间将计时器放入计时器队列中，因此计时器阶段只会接收其中一些。

好的，但是是什么使所谓的“ I/O周期”与主模块不同？

主模块在初始化libuv之前运行，而大多数其他代码将在 poll 阶段运行， design.html“ rel =“ noreferrer”> libuv loop 。因此，主模块初始化之后是计时器阶段，而轮询阶段之后是“检查手柄”阶段，其中包括 setimMediate 回调。因此，通常在主模块中，计时器将在立即立即运行（如果到期），如果安排在回调中，则立即在计时器之前运行。

Answer 2

我也会为可见性写一个Aswer，因为这是一个很好的问题，节点文档确实具有误导性，我也必须挖掘一些资源……

这个问题回答了 here （接受的答案）很好性能基准测试。

但是，可以在另一个答案中找到实际的解释，该答案指向本文更好地解释了事件循环。

另外，阅读这个答案并解释了哪个部分取决于平台和耗时CPU并产生非确定性，以及0已转换为0的事实在settimeout上内部为1），以提出在nodejs上提出的问题，提出了同样的问题，似乎可以进一步解释它。

一个更重要的事情要注意的是，将内部转换为1。

时Settimeout。

这个呼吁UV__hrtime是平台依赖的，并且是CPU时间耗费的工作，因为它使系统制造系统
致电clock_getTime。它受到机器上运行的其他应用程序的影响。

如果第一个循环之前的准备工作花费超过1ms，则计时器阶段调用与之关联的回调。如果小于1ms的事件循环继续下一阶段，并在循环的检查阶段和SettieMout的检查阶段运行setimediate回调。
循环的下一个刻度。