浏览器中的事件循环和nodejs中的事件循环

首先 setTimeout 并没有特殊，也是一个 task。另外每次的执行过 task 和 大量的 microtask（不一定在一次循环全执行完）后，会进行 renderUi 阶段，虽然不是每次事件循环都进行 renderUi ，但每次间隔，也就是传说中 60hz 的一帧 16ms。

浏览器中的事件循环

宏任务和微任务

同步代码的执行也属于宏任务

浏览器先执行同步代码，遇到宏任务就放到 macro task 的任务队列中，遇到微任务就放入 micro task 的队列中。在执行完同步任务之后就会先执行微任务队列中的所有微任务，然后从宏任务队列中取出第一个宏任务执行，执行完毕之后再去执行所有的微任务...这个过程是循环不断的所以被称为事件循环。但是需要注意的是浏览器会在每 16ms 进行一次的 UI 渲染，可能会中断事件循环的执行

常见的宏任务

setTimeout、setInterval、 setImmediate、script（整体代码）、 I/O 操作、UI 渲染

常见的微任务

MutationObserver Promise

nodejs 中的事件循环

外部输入数据–>轮询阶段(poll)–>检查阶段(check) setImmediate–>关闭事件回调阶段(close callback)–>定时器检测阶段(timer) setTimeout/setInterval–>I/O 事件回调阶段(I/O callbacks) 文件操作的回调函数等等–>闲置阶段(idle, prepare)–>轮询阶段（按照该顺序反复运行）

我们可以接触到的比较常用的就是 poll,check,timer 这几个阶段

nodejs中时间循环和浏览器中的区别

在 node11 版本之后，对于 macro task 和 micro task 的执行时机和浏览器中相同。

在 node11 之前，nodejs 和浏览器中的事件循环的区别就是 micro task 的执行时机；nodejs中 timers 阶段有几个 setTimeout/setInterval 都会依次执行，执行完毕所有的 timers 代码之后才会去执行 micro task，并不像浏览器端，每执行一个宏任务后就去执行所有微任务。

所以下面的代码，在 node11 之前的执行结果是和浏览器中不相同的

console.log('start')
setTimeout(() => {
  console.log('timer1')
  Promise.resolve().then(function() {
    console.log('promise1')
  })
}, 0)
setTimeout(() => {
  console.log('timer2')
  Promise.resolve().then(function() {
    console.log('promise2')
  })
}, 0)
Promise.resolve().then(function() {
  console.log('promise3')
})
console.log('end')
//start=>end=>promise3=>timer1=>timer2=>promise1=>promise2
// 浏览器和新版本node start=>end=>promise3=>timer1=>promise1=>timer2=>promise2

poll阶段 该阶段会执行所有的回调

poll 是一个至关重要的阶段，这一阶段中，系统会做两件事情

1. 回到 timer 阶段执行回调

2. 执行 I/O 回调

没有设置timer或者是设置的timer没有到时间

会发生以下两件事情

1. 如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者达到系统限制

2. 如果 poll 队列为空时，会有两件事发生

如果有 setImmediate 回调需要执行，poll 阶段会停止并且进入到 check 阶段执行回调

如果没有 setImmediate 回调需要执行，会等待回调被加入到队列中并立即执行回调，这里同样会有个超时时间设置防止一直等待下去

设置了timer且timer时间已经到了

当然设定了 timer 的话且 poll 队列为空，则会判断是否有 timer 超时，如果有的话会回到 timer 阶段执行回调。

注意点

(1) setTimeout 和 setImmediate

二者非常相似，区别主要在于调用时机不同。

setImmediate 设计在 poll 阶段完成时执行，即 check 阶段；

setTimeout 设计在 poll 阶段为空闲时，且设定时间到达后执行，但它在 timer 阶段执行

setTimeout(function timeout () {
  console.log('timeout');
},0);
setImmediate(function immediate () {
  console.log('immediate');
});

对于以上代码来说，setTimeout 可能执行在前，也可能执行在后。

首先 setTimeout(fn, 0) === setTimeout(fn, 1)，这是由源码决定的

我们发现虽然我们传的超时时间是 0，但是 0 不是合法值，nodejs 会把超时时间变成 1。

进入事件循环也是需要成本的，如果在准备时候花费了大于 1ms 的时间，那么在 timer 阶段就会直接执行 setTimeout 回调

如果准备时间花费小于 1ms，那么就是 setImmediate 回调先执行了

但当二者在异步 i/o callback 内部调用时，总是先执行 setImmediate，再执行 setTimeout

const fs = require('fs')
fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log('timeout');
    }, 0)
    setImmediate(() => {
        console.log('immediate')
    })
})
// immediate
// timeout

在上述代码中，setImmediate 永远先执行。因为两个代码写在 IO 回调中，IO 回调是在 poll 阶段执行，当回调执行完毕后队列为空，发现存在 setImmediate 回调，所以就直接跳转到 check 阶段去执行回调了。

(2) process.nextTick

这个函数其实是独立于 Event Loop 之外的，它有一个自己的队列，当每个阶段完成后，如果存在 nextTick 队列，就会清空队列中的所有回调函数，并且优先于其他 microtask 执行。

setTimeout(() => {
 console.log('timer1')
 Promise.resolve().then(function() {
   console.log('promise1')
 })
}, 0)
process.nextTick(() => {
 console.log('nextTick')
 process.nextTick(() => {
   console.log('nextTick')
   process.nextTick(() => {
     console.log('nextTick')
     process.nextTick(() => {
       console.log('nextTick')
     })
   })
 })
})
// nextTick=>nextTick=>nextTick=>nextTick=>timer1=>promise1