前言

---

根据上一篇文章，我们可知，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