Node 定时器详解

作者: 阮一峰

日期: 2018年2月23日

JavaScript 是单线程运行,异步操作特别重要。

只要用到引擎之外的功能,就需要跟外部交互,从而形成异步操作。由于异步操作实在太多,JavaScript 不得不提供很多异步语法。这就好比,有些人老是受打击, 他的抗打击能力必须变得很强,否则他就完蛋了。

Node 的异步语法比浏览器更复杂,因为它可以跟内核对话,不得不搞了一个专门的库 libuv 做这件事。这个库负责各种回调函数的执行时间,毕竟异步任务最后还是要回到主线程,一个个排队执行。

为了协调异步任务,Node 居然提供了四个定时器,让任务可以在指定的时间运行。

  • setTimeout()
  • setInterval()
  • setImmediate()
  • process.nextTick()

前两个是语言的标准,后两个是 Node 独有的。它们的写法差不多,作用也差不多,不太容易区别。

你能说出下面代码的运行结果吗?


// test.js
setTimeout(() => console.log(1));
setImmediate(() => console.log(2));
process.nextTick(() => console.log(3));
Promise.resolve().then(() => console.log(4));
(() => console.log(5))();

运行结果如下。


$ node test.js
5
3
4
1
2

如果你能一口说对,可能就不需要再看下去了。本文详细解释,Node 怎么处理各种定时器,或者更广义地说,libuv 库怎么安排异步任务在主线程上执行。

一、同步任务和异步任务

首先,同步任务总是比异步任务更早执行。

前面的那段代码,只有最后一行是同步任务,因此最早执行。


(() => console.log(5))();

二、本轮循环和次轮循环

异步任务可以分成两种。

  • 追加在本轮循环的异步任务
  • 追加在次轮循环的异步任务

所谓"循环",指的是事件循环(event loop)。这是 JavaScript 引擎处理异步任务的方式,后文会详细解释。这里只要理解,本轮循环一定早于次轮循环执行即可。

Node 规定,process.nextTickPromise的回调函数,追加在本轮循环,即同步任务一旦执行完成,就开始执行它们。而setTimeoutsetIntervalsetImmediate的回调函数,追加在次轮循环。

这就是说,文首那段代码的第三行和第四行,一定比第一行和第二行更早执行。


// 下面两行,次轮循环执行
setTimeout(() => console.log(1));
setImmediate(() => console.log(2));
// 下面两行,本轮循环执行
process.nextTick(() => console.log(3));
Promise.resolve().then(() => console.log(4));

三、process.nextTick()

process.nextTick这个名字有点误导,它是在本轮循环执行的,而且是所有异步任务里面最快执行的。

Node 执行完所有同步任务,接下来就会执行process.nextTick的任务队列。所以,下面这行代码是第二个输出结果。


process.nextTick(() => console.log(3));

基本上,如果你希望异步任务尽可能快地执行,那就使用process.nextTick

四、微任务

根据语言规格,Promise对象的回调函数,会进入异步任务里面的"微任务"(microtask)队列。

微任务队列追加在process.nextTick队列的后面,也属于本轮循环。所以,下面的代码总是先输出3,再输出4


process.nextTick(() => console.log(3));
Promise.resolve().then(() => console.log(4));
// 3
// 4

注意,只有前一个队列全部清空以后,才会执行下一个队列。


process.nextTick(() => console.log(1));
Promise.resolve().then(() => console.log(2));
process.nextTick(() => console.log(3));
Promise.resolve().then(() => console.log(4));
// 1
// 3
// 2
// 4

上面代码中,全部process.nextTick的回调函数,执行都会早于Promise的。

至此,本轮循环的执行顺序就讲完了。

  1. 同步任务
  2. process.nextTick()
  3. 微任务

五、事件循环的概念

下面开始介绍次轮循环的执行顺序,这就必须理解什么是事件循环(event loop)了。

Node 的官方文档是这样介绍的。

"When Node.js starts, it initializes the event loop, processes the provided input script which may make async API calls, schedule timers, or call process.nextTick(), then begins processing the event loop."

这段话很重要,需要仔细读。它表达了三层意思。

首先,有些人以为,除了主线程,还存在一个单独的事件循环线程。不是这样的,只有一个主线程,事件循环是在主线程上完成的。

其次,Node 开始执行脚本时,会先进行事件循环的初始化,但是这时事件循环还没有开始,会先完成下面的事情。

  • 同步任务
  • 发出异步请求
  • 规划定时器生效的时间
  • 执行process.nextTick()等等

最后,上面这些事情都干完了,事件循环就正式开始了。

六、事件循环的六个阶段

事件循环会无限次地执行,一轮又一轮。只有异步任务的回调函数队列清空了,才会停止执行。

每一轮的事件循环,分成六个阶段。这些阶段会依次执行。

  1. timers
  2. I/O callbacks
  3. idle, prepare
  4. poll
  5. check
  6. close callbacks

每个阶段都有一个先进先出的回调函数队列。只有一个阶段的回调函数队列清空了,该执行的回调函数都执行了,事件循环才会进入下一个阶段。

下面简单介绍一下每个阶段的含义,详细介绍可以看官方文档,也可以参考 libuv 的源码解读

(1)timers

这个是定时器阶段,处理setTimeout()setInterval()的回调函数。进入这个阶段后,主线程会检查一下当前时间,是否满足定时器的条件。如果满足就执行回调函数,否则就离开这个阶段。

(2)I/O callbacks

除了以下操作的回调函数,其他的回调函数都在这个阶段执行。

  • setTimeout()setInterval()的回调函数
  • setImmediate()的回调函数
  • 用于关闭请求的回调函数,比如socket.on('close', ...)

(3)idle, prepare

该阶段只供 libuv 内部调用,这里可以忽略。

(4)Poll

这个阶段是轮询时间,用于等待还未返回的 I/O 事件,比如服务器的回应、用户移动鼠标等等。

这个阶段的时间会比较长。如果没有其他异步任务要处理(比如到期的定时器),会一直停留在这个阶段,等待 I/O 请求返回结果。

(5)check

该阶段执行setImmediate()的回调函数。

(6)close callbacks

该阶段执行关闭请求的回调函数,比如socket.on('close', ...)

七、事件循环的示例

下面是来自官方文档的一个示例。


const fs = require('fs');

const timeoutScheduled = Date.now();

// 异步任务一:100ms 后执行的定时器
setTimeout(() => {
  const delay = Date.now() - timeoutScheduled;
  console.log(`${delay}ms`);
}, 100);

// 异步任务二:文件读取后,有一个 200ms 的回调函数
fs.readFile('test.js', () => {
  const startCallback = Date.now();
  while (Date.now() - startCallback < 200) {
    // 什么也不做
  }
});

上面代码有两个异步任务,一个是 100ms 后执行的定时器,一个是文件读取,它的回调函数需要 200ms。请问运行结果是什么?

脚本进入第一轮事件循环以后,没有到期的定时器,也没有已经可以执行的 I/O 回调函数,所以会进入 Poll 阶段,等待内核返回文件读取的结果。由于读取小文件一般不会超过 100ms,所以在定时器到期之前,Poll 阶段就会得到结果,因此就会继续往下执行。

第二轮事件循环,依然没有到期的定时器,但是已经有了可以执行的 I/O 回调函数,所以会进入 I/O callbacks 阶段,执行fs.readFile的回调函数。这个回调函数需要 200ms,也就是说,在它执行到一半的时候,100ms 的定时器就会到期。但是,必须等到这个回调函数执行完,才会离开这个阶段。

第三轮事件循环,已经有了到期的定时器,所以会在 timers 阶段执行定时器。最后输出结果大概是200多毫秒。

八、setTimeout 和 setImmediate

由于setTimeout在 timers 阶段执行,而setImmediate在 check 阶段执行。所以,setTimeout会早于setImmediate完成。


setTimeout(() => console.log(1));
setImmediate(() => console.log(2));

上面代码应该先输出1,再输出2,但是实际执行的时候,结果却是不确定,有时还会先输出2,再输出1

这是因为setTimeout的第二个参数默认为0。但是实际上,Node 做不到0毫秒,最少也需要1毫秒,根据官方文档,第二个参数的取值范围在1毫秒到2147483647毫秒之间。也就是说,setTimeout(f, 0)等同于setTimeout(f, 1)

实际执行的时候,进入事件循环以后,有可能到了1毫秒,也可能还没到1毫秒,取决于系统当时的状况。如果没到1毫秒,那么 timers 阶段就会跳过,进入 check 阶段,先执行setImmediate的回调函数。

但是,下面的代码一定是先输出2,再输出1。


const fs = require('fs');

fs.readFile('test.js', () => {
  setTimeout(() => console.log(1));
  setImmediate(() => console.log(2));
});

上面代码会先进入 I/O callbacks 阶段,然后是 check 阶段,最后才是 timers 阶段。因此,setImmediate才会早于setTimeout执行。

九、参考链接

(完)

留言(59条)

一如既往的通俗易懂,赞!!!

感觉有些问题啊, 在event loop6个阶段,I/O cbs里的回调应该包含了poll及close cbs的回调用,后面两步不是重复了么

`processes the provided input script which may make async API calls, schedule timers, or call process.nextTick()`

请问这里的意义是什么呢,是仅限于这三者吗,还是举了三个例子本意是执行完所有的同步代码再开始循环呢。

引用michael的发言:

`processes the provided input script which may make async API calls, schedule timers, or call process.nextTick()`

请问这里的意义是什么呢,是仅限于这三者吗,还是举了三个例子本意是执行完所有的同步代码再开始循环呢。

setImmediate 也应该包括在内吧。

感谢分享,非常棒!

感谢分享,
话说 算法与数学(29)分类, 2018年不知道阮老师会分享几篇, 每次看都会一种奇妙的感觉, 感谢你的分享~

与JS调用堆栈的micro tasks 和 macro tasks 的概念类似

假如在I/O Poll阶段读取文件一直没有返回,那线程是不是就一直阻塞在该阶段,setTimeout到期也不能执行?

阮大,这个地方写的有问题,那个官网的例子,注释不应该是

// 异步任务二:至少需要 200ms 的文件读取

而应该是

// 异步任务二:文件读取后,执行一个用时 200ms 的回调函数

这样才能保证,readfile阻塞了事件循环,导致setTimeout没有按时执行回调函数

引用Junzi的发言:

假如在I/O Poll阶段读取文件一直没有返回,那线程是不是就一直阻塞在该阶段,setTimeout到期也不能执行?

并不是吧,读取文件实际上不是Node关心的范畴,就像ajax底层通信的内容不归js操心一样,线程会继续,只是由底层去执行,如果这时setTimeout到期,其实会添加到Timer队列里面,而Timer队列一旦有内容,其他队列没有内容,事件循环就会到Timer阶段去执行回调函数

有没有大佬赐教一下
setImmediate(function(){
console.log(1);
process.nextTick(function(){
console.log(2);
});
});
process.nextTick(function(){
console.log(3);
setImmediate(function(){
console.log(4);
})
});
按宏微任务的理论,我认为执行出来是 3 1 2 4
但是实际是 3 1 4 2。。。

@qianbi

两个 setImmediate 在同一轮循环的同一个队列里面。只有清空了这个队列,才会进入下一个阶段。

@红烧肉:

谢谢指出,已经改过来了。

引用阮一峰的发言:

@qianbi

两个 setImmediate 在同一轮循环的同一个队列里面。只有清空了这个队列,才会进入下一个阶段。

因为在第一轮循环里面的 包含console.log(4)的setImmediate 正好赶上了这轮的循环吗?是不是 3,4,1是第一轮循环,2是第二个循环的意思吗?

官方文档,好像说阻塞在poll阶段,读文件的io完成,回调函数被加到poll队列并执行。而文中写的在第二次循环的IO callback阶段执行。是不是有点问题?
When the event loop enters the poll phase, it has an empty queue (fs.readFile() has not completed), so it will wait for the number of ms remaining until the soonest timer's threshold is reached. While it is waiting 95 ms pass, fs.readFile() finishes reading the file and its callback which takes 10 ms to complete is added to the poll queue and executed. When the callback finishes, there are no more callbacks in the queue, so the event loop will see that the threshold of the soonest timer has been reached then wrap back to the timers phase to execute the timer's callback. In this example, you will see that the total delay between the timer being scheduled and its callback being executed will be 105ms.

但是,下面的代码一定是先输出2,再输出1。
const fs = require('fs');
fs.readFile('test.js', () => {
setTimeout(() => console.log(1));
setImmediate(() => console.log(2));
});
上面代码会先进入 I/O callbacks 阶段,然后是 check 阶段,最后才是 timers 阶段。因此,setImmediate才会早于setTimeout执行。
================================
这段有点没看懂,按我的理解先进入I/O callbacks 阶段,这里将两个回调函数追加到次轮循环,然后本轮循环结束,再开始次轮循环,再应该是timers 阶段,check阶段啊

引用Summer的发言:

因为在第一轮循环里面的 包含console.log(4)的setImmediate 正好赶上了这轮的循环吗?是不是 3,4,1是第一轮循环,2是第二个循环的意思吗?

3是第一轮,然后1 4 是第二轮,6个阶段结束后执行process.nextTick,得到2

引用gahing的发言:

3是第一轮,然后1 4 是第二轮,6个阶段结束后执行process.nextTick,得到2

勘误:貌似每个阶段结束后都会执行process.nextTick?

@jeremy:

fs.readFile()完成文件读取后,会将回调放入poll队列并执行。poll执行回调后,setImmediate和setTimeout被放入各自的队列。poll阶段结束后,执行check阶段,故执行了setImmediate。

文章这边讲的错误的地方有:并非在I/O callbacks,而是在poll阶段执行回调

你理解错误的地方有:回调并非都是放入次轮。是否追加到次轮是看对应的阶段是否进行过,没有进行过的会放入本轮

(当然也不知道我的理解对不对

@gahing:

https://cnodejs.org/topic/5a9108d78d6e16e56bb80882 根据这个帖子 我感觉你说的有道理

次轮循环指的就是事件循环吗?

在执行次轮循环里的某个回调时,如果在回调里执行 process.nextTick,那么 process.nextTick 的回调什么时候执行呢?

有几个问题:
1. 后边讲事件循环的六个阶段时候,没有提到 同步任务 nextTick microTask 应该放在哪个阶段,或者不在这六个阶段内。
2. Poll 中提到的 `会一直停留在这个阶段` 是指阻塞在这里,还是不会继续进行下一个阶段(即每次轮询都会停在Poll)

引用Junzi的发言:

假如在I/O Poll阶段读取文件一直没有返回,那线程是不是就一直阻塞在该阶段,setTimeout到期也不能执行?

阻塞是对的,但是如果有其他队列待执行,就会执行其他的

引用阿成的发言:

有几个问题:
1. 后边讲事件循环的六个阶段时候,没有提到 同步任务 nextTick microTask 应该放在哪个阶段,或者不在这六个阶段内。
2. Poll 中提到的 `会一直停留在这个阶段` 是指阻塞在这里,还是不会继续进行下一个阶段(即每次轮询都会停在Poll)

nextTick 在每个阶段结束后都会执行,microTask 是在6个阶段结束后执行

@yang

还有一个问题啊,文中说到 setImmediate 的回调会放到次轮循环是不是不准确,如 @gahing 所说,如果在 check 阶段之前执行 setImmediate,那么其回调应该放在本轮循环的 check 阶段。

而这也与文中的一个例子不谋而合:

const fs = require('fs');

fs.readFile('test.js', () => {
setTimeout(() => console.log(1));
setImmediate(() => console.log(2));
});

这个例子中如果 setImmediate 的回调是放在次轮循环,就不成立了,那么应该先 1 后 2 了。而按照 @gahing 所说,readFile 的回调执行之时,处在 poll 阶段,这时 timers 阶段已经过了,所以 setTimeout 会加入次轮循环,而 check 阶段还没过,setImmediate 会加入本轮循环的 check 阶段。

不知道这样理解对不对,由于本人能力有限,源码什么的暂时还看不太懂,只能跟各位探讨一下了...

Node 能不能改成多核多线程执行呢

引用yang的发言:

nextTick 在每个阶段结束后都会执行,microTask 是在6个阶段结束后执行

```
setTimeout(function () {
console.log(1)
Promise.resolve().then(() => console.log(3))
process.nextTick(() => console.log(4))
}, 0);
setImmediate(() => console.log(2))
```
这个测试例子好像与你的microTask 是在6个阶段结束后执行结论有冲突

写的很好,很受用

写的真的很棒,以前看了很久,现在完全弄明白啦

引用阮一峰的发言:

@qianbi

两个 setImmediate 在同一轮循环的同一个队列里面。只有清空了这个队列,才会进入下一个阶段。

引用qianbi的发言:

有没有大佬赐教一下
setImmediate(function(){
console.log(1);
process.nextTick(function(){
console.log(2);
});
});
process.nextTick(function(){
console.log(3);
setImmediate(function(){
console.log(4);
})
});
按宏微任务的理论,我认为执行出来是 3 1 2 4
但是实际是 3 1 4 2。。。

这里把 setImmediate 换成 setTimeout 结果又不一样哦,真的是全部都先清空队列再执行下一个吗

终于在原理上弄明白了,谢谢阮老师。

引用陈家宾的发言:

这里把 setImmediate 换成 setTimeout 结果又不一样哦,真的是全部都先清空队列再执行下一个吗

先说 setImmediate 的情况。

首先 process.nextTick 的回调要比 setImmediate 的回调更快执行,因为 process.nextTick 的回调会在 timers 阶段和I/O callbacks 阶段之间执行,所以先输出 3。
再来说 第一个 setImmediate 是在 main module(主线程的同步代码)中执行的,所以它的回调会排在第二个 setImmediate 的回调之前,但都处于同一轮事件循环中,因为第二个 setImmediate 执行的时候,check 阶段还没有过。

所以第一个 setImmediate 先执行,输出 1,紧接着第二个 setImmediate 执行,输出 4。
最后 check 阶段结束后,close 阶段结束前,process.nextTick 的回调执行,输出 2。
因此是 3 1 4 2。

再说把 setImmediate 换成 setTimeout。
同样是先输出 3。这里是因为主线程同步代码执行完之后,会立马执行 process.nextTick 的回调。
第一个 setTimeout 和 第二个 setTimeout 的回调都会在 timers 阶段检查是否到时间,如果到时间就会立刻执行
所以说,setTimeout 和 setImmediate 并不同,setTimeout 还要检查是否到时间。
因此,有可能第一个 setTimeout 到时间了,第二个没到,这样第二个 setTimeout 的回调就在 poll 阶段检测到并执行,输出结果就是 3 1 2 4。
有可能两个 setTimeout 都没到时间,这样输出就是 3 1 4 2。
也有可能两个 setTimeout 都到时间了,这样输出也是 3 1 4 2。
我实际测试的时候,确实得到了这两种结果。

以上。

var fs = require('fs')

fs.readFile('./1 .jpg', () => {
console.log(3)
})

setImmediate(() => console.log(2))


setTimeout(() => {
console.log(1)
});

有时123 有时213 求解???????

简单易懂。

事件循环那里,到了 poll 阶段,一直在等待事件的响应,如果等待时,计时器到期了呢,会去执行定时器嘛???还是到了 poll 阶段,主线程就阻塞了,一直等到 IO 事件响应才开始下面的事情

引用伟伟的发言:

var fs = require('fs')

fs.readFile('./1 .jpg', () => {
console.log(3)
})

setImmediate(() => console.log(2))


setTimeout(() => {
console.log(1)
});

有时123 有时213求解???????



这一段 阮老师已经有例子说过了,如下

setTimeout(() => console.log(1));
setImmediate(() => console.log(2));


上面这段代码是不确定执行顺序的,就像你的代码段有时 是 123 有时是 213 一样 ,理由看阮老师上面写的东西。

3 总是在最后面,因为读取文件耗时, 而setImmediate 和 setTImeout 执行很快,所以在后面

在Node REPL模式下,开头的例子结果是: 53421,不知道何解呢?

这个怎么解释?
setTimeout(function () {
console.log(1)
Promise.resolve().then(() => console.log(3))
process.nextTick(() => console.log(4))
}, 0);
setImmediate(() => console.log(2))

收获很大

引用阮一峰的发言:

@qianbi

两个 setImmediate 在同一轮循环的同一个队列里面。只有清空了这个队列,才会进入下一个阶段。

node11.0.0 开始job任务会插入到同一个队列的每一个任务之后了,阮老师应该同步更新下

Node文档中说,如果 poll 队列为空时,如果有计时器到期,则会回滚至timer阶段执行计时器回调。那我有2点疑问:
1. 如果此时计时器回调存在,但是setImmediate()也存在,谁先执行?
2. 回滚至timer阶段之后,下一阶段是又执行到pending callbacks阶段吗?

"只有异步任务的回调函数队列清空了,才会停止执行。"也就是循环最终会停止?那下次循环又是怎么触发的呢

rs.readFile的回调按官方说法是应该放在poll的队列里,这里说放在pending callback显然有问题
还是改一下吧,这篇文章看的人太多了

七、事件循环的示例,这块写的是不是有问题,事件循环第一个阶段是timers阶段,首先要监听有没有到期的定时器,没有到期的定时器就往下执行,接下来一次执行下面的事件循环阶段,不论定时器是否到期,都会往下执行,直到本次事件循环结束。所以看这块看了很多遍没有理解,走了一下代码理解了,可能表达的语无伦次。

很多人提到了,根据官方文档,文件IO或者Socket IO实在 POLL 阶段处理的,而不是Pending/Callbacks阶段,所以不会进入下一轮时间循环,而是直接执行,很容易验证:


const fs = require('fs');
fs.readFile('test.js', () => {
setImmediate(() => { console.log('Immediate') });
console.log('File callback')
});

1. 如果进入下一轮,那么首先执行Check阶段也就是先打印Immediate
2. 如果实在当前Poll阶段执行,那么首先打印File callback

引用workNothing的发言:

这个怎么解释?
setTimeout(function () {
console.log(1)
Promise.resolve().then(() => console.log(3))
process.nextTick(() => console.log(4))
}, 0);
setImmediate(() => console.log(2))

这个是因为netxtTick任务见缝插针,每个阶段完成都会查询。promise.then只会每轮查询。

真的系统全面

楼上的3124现在是对的,难道node的逻辑有更新?

poll阶段是有超时时间的,不会一直阻塞

引用海豚先生的发言:

楼上的3124现在是对的,难道node的逻辑有更新?

我现在跑出来也是3124

node10之后,nextTick由InternalCallbackScope Close后被MakeCallback调用,每个asyncWrap都是其封装。所以每一个阶段都会执行nextTick。并且nextTick是阻塞式的执行,提前于promise。

引用Liuyl的发言:

node10之后,nextTick由InternalCallbackScope Close后被MakeCallback调用,每个asyncWrap都是其封装。所以每一个阶段都会执行nextTick。并且nextTick是阻塞式的执行,提前于promise。

我这里说的还不够详细,为什么上面是3124,而不是3142.是因为每个Handle接受后都会触发makeCallback,此时会调用_tickCallback触发nextTick queue

终于完全解惑!感谢

还是阮老师的通俗易懂,看了好多,越看越懵逼

process.nextTick(() => {
console.log(8)
setTimeout(() => {
console.log(9)
})
})
setTimeout(() => {
console.log(2)
new Promise(() => {
console.log(11)
})
})
// node 8 - 2 - 11 -9
为什么会有这样的执行顺序?

从官方文档看,I/O 回调函数会放在 poll 阶段而不是 pendding 阶段,pendding 阶段处理延迟到下一轮的 I/O 回调函数(虽然我不太理解这个延迟到下一轮的回调函数)

timers 执行setTimeout setInterval的回调函数
pending callbacks 执行延迟到下一个循环的I/O回调
idle, prepare 内部调用
poll 轮询新的I/O事件;执行I/O相关的回调(除seTimeout setInterval setImmediate 及连接关闭的回调如socket.on('close'),()=>{}),node在这个阶段会阻塞
check 检查阶段,执行setImmediate的回调
close callbacks 执行连接关闭的回调如socket.on('close',()=.{})

这是看到大部分文章的描述

我的疑问是,什么条件下才会进入close callbacks 阶段?

猜测:poll 轮训io事件队列,如果有就执行没有就检查有没有check回调,有就执行执setImmediate的回调没有就继续poll,在判断有没有timers队列,有就进入下一轮,就没啥都没有是不是就会关闭event loop,在关闭前处理一下 close callbacks的回调。

@Liuyl:

非常感谢 之前一直不理解这里 明明没有跳阶段也会执行nextTick

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接