×

Node探秘之事件循环(2)--setTimeout/setImmediate/process.nextTick的差别

96
游泳的石头
2016.11.06 19:30* 字数 3415

前言


根据上一篇文章,我们可知,node对回调事件的处理完全是基于事件循环的tick的,因此具有几大特征:

1、在应用层面,JS是单线程的,业务代码中不能存在耗时过长的代码,否则可能会严重拖后续代码(包括回调)的处理。如果遇到需要复杂的业务计算时,应当想办法启用独立进程或交给其他服务进行处理。

2、回调是不精确,因为前面的原因,setTimeout并不能得到准确的超时回调。

3、不同类型的观察者,处理的优先级不同,idle观察者最先,I/O观察者其次,check观察者最后。

那么本文主要要分析的是基于tick的几个主要回调实现,setTimeout/setInterval/process.nextTick/setImmediate,这几个属于js异步回调的比较特殊的,因为他们并不是像普通I/O操作那样真的需要等待事件异步处理结束再进行回调,而是出于定时或延迟处理的原因才设计的。分析起来相对简单,因此我们就从它们入手,逐步揭开事件循环的秘密。

区别及源码分析


◇setTimeout/setInterval

setTimeout和setInterval的表现和实现其实基本相同,不同的只是setInterval会不断重复。在底层实现上他们是创建了一个Timeout的中间对象,并且放到了实现定时器的红黑树中,每一次tick开始时,都会到这个红黑树中检查是否存在超时的回调,如果存在,则一一按照超时顺序取出来进行回调。因此,我们可以得出这样一个结论:

js的定时器是不可靠的。因此单线程的原因,它是基于tick的,每次tick开始时才开始检查是否有超时,如果一个tick耗时过长,在它之后出发的定时回调都将被延迟。因此才会出现像“问题1”这样的情况。

setTimeout第二个参数设置为0或者不设置,意思不是立即执行回调,而是在下次tick时立即执行(当然,实际上,这里有点小问题,后面会讲到)!这setTimeout也解释了Promise的实现中,resolve方法里为什么有些要用setTimeout(..., 0),这是为了解决在碰到同步代码时,resolve先于then执行的问题。但是它有一个严重的问题,就是回调依然被送入定时器的红黑树,存在一定的性能问题。因此,通常大家会用process.nextTick()或setImmediate()来替代它。


lib/timers.js

这里先创建了一个Timeout对象,然后调用active函数使他生效

lib/timer.js

这里调用insert方法把当前Timeout对象插入到了一个地方

lib/timer.js

这个insert方法比较有意思,list是一个Timer对象,通过调用它的start方法可以使定时器生效,同时它又是个双向链表,这iterm就是被插入到了这个双向链表中。这是为什么?

其实,代码里面已经给出了解释

原来因为实际开发过程中,经常会出现很多的socket会被设置为相同的超时时间,如果为每一个这样的超时请求都设置一个watcher,那就太浪费系统资源了,系统负载也会变得很高,性能变差。因为,这里用了一个非常巧妙的方法,那就是把超时时间相同的Timeout对象都扔到同一个链表中,然后再把这个Timer链表作为一个独立的超时单位启动。

src/timer_wrap.cc

这里调用了uv_timer_start(不同系统实现方式不同,这里的源码是unix的)

deps/uv/src/unix/timer.cc

原来这个uv_timer_start其实主要就是把这个Timer对象插入到了一颗红黑树上。

如果还记得我上文对事件循环的代码分析的话,你一定会注意在事件循环的while中,有uv__run_timers这一行,通过上面这段代码,就能看出来这个uv__run_timers就是从红黑树上取下所有超时的Timer对象,然后依次调用他们的回调方法进行回调。

◇process.nextTick

实际上,process.nextTick()方法的操作相对较为轻量,每次调用Process.nextTick()方法,只会将回调函数放入队列中,在下一轮Tick时取出执行。定时器采用红黑树的操作时间复杂度为o(lg(n)),而nextTick()的时间复杂度为o(1)。相较之下,process.nextTick()更高效。

src/node.js

由以上代码可知,nextTick函数,会将callback封装为一个obj对象,并且插入到nextTickQueue队列(数组)中。


src/node.js

由上述代码可知,每次nextTick回调,都会nextTickQueue数组中的回调全部跑完!

◇setImmediate


lib/timers.js

setImmediate函数,首先把callback封装成了一个immediate对象,然后把它插入到了immediateQueue队列(数组)中。

注意上面的那句process._immediateCallback = processImmediate,这行代码就是把process._immediateCallback设置成了processImmediate的别名,下次tick的时候就会调用这个函数进行回调。


setImmediate()方法和process.nextTick()方法十分类似,都是将回调函数延迟在下一次立即执行。setImmediate是创建了一个叫为immediate的中间对象,并且放入到了immediateQueue队列中在Node v0.9.1之前,setImmediate()还没有实现,那时候实现类似的功能主要是通过process.nextTick()来完成。

但两者之间其实是有差别的。区别表现为两点:

1、process.nextTick中回调函数的优先级高于setImmediate,根据我前面写的那篇文章可知,原因在于事件循环对观察者的检查是有先后顺序的,process.nextTick属于idle观察者,setImmediate属于check观察者。在每一轮循环检查中,idle观察者先于I/O观察者,I/O观察者先于check观察者。

而且,这里最有意思的是下面这段代码的执行结果,大家以为会是什么样的输出?

他的实际输出是:

nextTick 1

nextTick 2

timeout

immediate

上面代码中表明,由于process.nextTick方法指定的回调函数,总是在当前"执行栈"的尾部触发,所以不仅函数A比setTimeout指定的回调函数timeout先执行,而且函数B也比timeout先执行。这说明,如果有多个process.nextTick语句(不管它们是否嵌套),将全部在当前"执行栈"执行。这里具体为什么这样,其实我现在也搞不懂,以后有机会可以慢慢在读读代码,如果有知道的朋友,可以告诉我一下,谢谢了。

我们由此得到了一个重要区别:多个process.nextTick语句总是一次执行完,多个setImmediate则需要多次才能执行完。事实上,这正是Node.js 10.0版添加setImmediate方法的原因,否则像下面这样的递归调用process.nextTick,将会没完没了,主线程根本不会去读取"事件队列"!

由于process.nextTick指定的回调函数是在本次"事件循环"触发,而setImmediate指定的是在下次"事件循环"触发,所以很显然,前者总是比后者发生得早,而且执行效率也高(因为不用检查"任务队列")。

2、在实现上,process.nextTick的回调函数保存在一个数组中,setImmediate则保存在一个链表中。顺便这里抛出一个朴灵老师在《深入浅出Node.js》中对process.nextTick和setImmediate的不够准确的描述:“在行为上,process.nextTick在每轮循环中将数组中的回调函数全部执行完,而setImmediate在每轮循环中执行链表中的一个回调函数。” 并且用了一段代码进行作证:

朴灵老师书里面说的结果是:

正常执行

nextTick延迟执行1

nextTick延迟执行2

setImmediate延迟执行1

强势插入

setImmediate延迟执行2

但我跑出来的真实结果却是:

正常执行

nextTick延迟执行1

nextTick延迟执行2

setImmediate延迟执行1

setImmediate延迟执行2

强势插入

我相信朴老师一定是验证过那段代码的,也就是说当时他测试应该是正确的。为了印证为什么我测试的结果为什么跟朴老师给的结果存在差异,我做了两件事情,一是在不同的node版本下运行这段代码(朴老师写那本书的时候,node最新版本为0.10.13,而我的版本是4.2.4),二是去翻阅node的源码实现,通过底层原理来描述这件事情。

首先,我测试了在不同版本下node运行的差异:

通过这个测试,我们可以发现,从设计逻辑出发,setImmediate每次只执行链表中的一个回调应该是早期node版本中是一个bug,这在后面的版本中修复了。所以,才出现了朴老师的书里描述的结果跟实际测试的不同的现象。

然后,我分别对比了node在这两个版本下的代码的差异:

0.10.13版本的

lib/timers.js

根据以上代码可知,在0.10.13的代码中,每次tick处理immediate时,只会取一个回调出来进行处理

4.x版本的

lib/timers.js

根据以上代码可知,在4.x版本的代码中,每次tick处理immediate时,会使用while循环,把所有的immediate回调取出来依次进行处理。

3、setImmediate可以使用clearImmediate清除(没搞懂这个到底能干吗,谁明白请告诉我一下),process.nextTick不能被清除

观察者优先级

在每次轮训检查中,各观察者的优先级分别是:

idle观察者 > I/O观察者 > check观察者。

idle观察者:process.nextTick

I/O观察者:一般性的I/O回调,如网络,文件,数据库I/O等

check观察者:setImmediate,setTimeout

上面的结果显示timeout1甚至优于immediate执行,原因应该在于距离下次tick启动至检查定时器的时间超过了10ms,因此timeout1那个时候其实已经超时了。

说到这里,顺便谈个问题。知乎上曾有人贴过一段关于setImmediate和setTimeout(xxx,0)的代码,得出了一个这样的结论:“而在执行setImmedia时,setTimeout是随机的插入在setImmediate的顺序中的”。我对这个结论是持怀疑态度的,一个像node这样稳定健壮的系统是不太可能允许这种不可控的随机性的,我们回过头去看前面的代码,发现了这样一行:

lib/timers.js

意思很明显,如果没有设置这个after,或者小于1,或者大于TIMEOUT_MAX(2^31-1),都会被强制设置为1ms。也就是说setTimeout(xxx,0)其实等同于setTimeout(xxx,1)。

那就很容易理解知乎这位作者的给出的代码为什么是这样的结果了。因此:setTimeout的优先级高于setImmediate,但是因为setTimeout的after被强制修正为1,这就可能存在下一个tick触发时,耗时尚不足1ms,setTimeout的回调依然未超时,因此setImmediate就先执行了!这可以通过在本次tick中加入一段耗时较长的代码来来保证本次tick耗时必须超过1ms来检测:

测试显示:不论运行多少次,得出的结果都一样,都是如下:

由此可知,setTimeout是优先于setImmediate被处理的。

总结


要想真正理解很多why的问题,光看大量的案例和看文字解释其实还是很难理解的,死记硬背也比较难记住。最好的方法还是通过阅读底层代码实现,并思考为什么这样设计,应该就会好很多。这些代码分析并不完整,我个人的理解也不是非常深入,很多地方地方可能都没有讲清楚。以后应该还会有更多的文章出来进行分析。

通过上面的分析,我也简单给出几个结论:

优先级顺序:process.nextTick > setTimeout/setInterval > setImmediate

setTimeout需要使用红黑树,且after设置为0,其实会被node强制转换为1,存在性能上的问题,建议替换为setImmediate

process.nextTick有一些比较难懂的问题和隐患,从0.8版本开始加入setImmediate,使用时,建议使用setImmediate

大前端
Web note ad 1