图画的简陋,大神看看理解的对不对。
http://voidcanvas.com/setimmediate-vs-nexttick-vs-settimeout/
http://voidcanvas.com/wp-content/uploads/2017/02/event-loop.png
@jinwyp 感谢分享
我看了下这篇文章,发现对 nextTick 的执行时机理解的不正确,应该是这样样的:
还有就是 poll 阶段的“阻塞/休眠”理解的更深刻了一些:当进入 poll 阶段,而且没有 timers,也没有 setImmediate 时,会被“阻塞”,等待有 Incoming Message,比如网络请求进来。
不知我理解的对不对?
还有就是 event loop 的 check 阶段,node 对于 nextTick 的处理发生了一些变化,以下面代码为例
process.nextTick(function () { console.log('nextTick延迟执行1'); }); process.nextTick(function () { console.log('nextTick延迟执行2'); }); setImmediate(function () { console.log('setImmediate延迟执行1'); process.nextTick(function () { console.log('强势插入'); }); var t = new Date(); while ((new Date()) - t < 200) { } setTimeout(function () { console.log('timeout in immediate1'); }); }); setImmediate(function () { console.log('setImmediate延迟执行2'); }); console.log('正常执行');
Node v0.10.32 中的结果为 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 强势插入 setImmediate延迟执行2 timeout in immediate1
Node v6 的结果为: 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 setImmediate延迟执行2 强势插入 timeout in immediate1
在 check 阶段,最早是每当一个setImmediate的callback执行后检查 nextTickQueue,后来改为当前所有 setImmediate 的 callback执行后检查 nextTickQueue。
在朴灵的《深入浅出Node.js》中说的其实是早起的 Node 版本中的逻辑
CNode 社区为国内最专业的 Node.js 开源技术社区,致力于 Node.js 的技术研究。
http://voidcanvas.com/setimmediate-vs-nexttick-vs-settimeout/
http://voidcanvas.com/wp-content/uploads/2017/02/event-loop.png
@jinwyp 感谢分享
我看了下这篇文章,发现对 nextTick 的执行时机理解的不正确,应该是这样样的:
还有就是 poll 阶段的“阻塞/休眠”理解的更深刻了一些:当进入 poll 阶段,而且没有 timers,也没有 setImmediate 时,会被“阻塞”,等待有 Incoming Message,比如网络请求进来。
不知我理解的对不对?
还有就是 event loop 的 check 阶段,node 对于 nextTick 的处理发生了一些变化,以下面代码为例
Node v0.10.32 中的结果为 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 强势插入 setImmediate延迟执行2 timeout in immediate1
Node v6 的结果为: 正常执行 nextTick延迟执行1 nextTick延迟执行2 setImmediate延迟执行1 setImmediate延迟执行2 强势插入 timeout in immediate1
在 check 阶段,最早是每当一个setImmediate的callback执行后检查 nextTickQueue,后来改为当前所有 setImmediate 的 callback执行后检查 nextTickQueue。
在朴灵的《深入浅出Node.js》中说的其实是早起的 Node 版本中的逻辑