The Node.js Event Loop, Timers, and process.nextTick()

[maodouchen]

概念：

nodeJs 是非阻塞IO，尽管JS是单线程，这都归功于event loop 当某个操作完成了，内核将会通知node，node就会将回调函数放到poll队列中，最终这个回调函数将会被执行。

解释：

当node启动的时候，将会初始化eventloop（我们写的node里可能有timers, nexttick ,async api calls）, 开始处理事件循环。 下面试一个简单的event loop的操作顺序的概览

每一个框(timers, pending, callbacks, idle prepare, poll ,check ,close cb)都是event loop的一个阶段

每个阶段都有一个先进先出的队列，当event loop进入某个阶段你的时候，event loop将完成这个阶段所指定的任何操作，然后在执行这个阶段队列的callback.直到这个队列空了再进入下一个阶段

当轮询事件在进程中的时候， poll events可以被排队，因此长时间的回调允许轮训阶段运行的事件超过timers的阈值？？？ 这个poll阶段是干啥的？？ 不懂

各个阶段概览

timers 这个阶段执行settimeout setinterval的回调 pending callbacks 将IO的回调移交给下一次循环 idle prepare 仅仅内部使用 poll 检索新的IO事件，执行IO相关的回调，（几乎是所有的回调除了close cb, 包括timers 和setimmediate） node将会阻塞在这里 适当的时候。 check setImmediate 的回调在这里执行 close callback 一些close的cb比如socket.on('close', xxx) 真的是一脸懵逼，setimmediate的回调到底在哪里？ poll check? 各个阶段是干了啥 还是不懂， 是我翻译的问题 还是智商问题

每一次event loop之间他都会检测是否有等待的异步IO timers

各个阶段的解释

timers timer指定了一个阈值，这个阈值意味着这段时间之后这个回调函数将会被执行，但并不意味着这段事件过后这个回调函数将马上被执行，他会被操作系统和正在运行的其他callback影响，会有些延迟。 poll阶段控制什么死后timers被执行