node中的事件循环

异步I/O

node最大的特性就是基于事件驱动的非阻塞I/O模型，非阻塞使得CPU和I/O不相互依赖等待，在实现中，分为两步
1、请求对象
在js代码中调用异步I/O，分解步骤可以理解为js调用node的核心模块，核心模块调用C++内建模块，内建模块通过libuv层调用系统。在libuv层进行了请求对象的封装（传入的参数，当前的方法，回调函数），最后将这个对象推入线程池中等待。
2、执行回调
事件循环每次询问是否有事件需要执行，是询问了了观察者，观察者调用IOCP检查线程池中是否有执行完的请求，有则将请求对象加入到事件队列中当做事件处理。回调行为就是取出请求对象的result属性和回调函数调用执行。

所以在node中回调函数并不是由开发者来调用的，而是由事件循环来调用。
单线程和线程池：node本身其实是多线程的，除了js是单线程的外，node所有的I/O（磁盘和网络）都是可以并行的。

非I/O的异步API

1、定时器setTimeout和setInterval创建的定时器会被插入到定时器观察者内部的一个红黑树中，内次Tick执行时会将该红黑树中取出定时器对象，检查是否超过形成事件作为回调函数执行。由于定时器需要红黑树，创建定时器和迭代等操作，对比起来，process.nextTick()方法直接将回调函数放到事件队列中，更轻量。时间复杂度为O(lgn) 和O(1)。
2、setImmediate()属于check观察者，不需要红黑树，在每一个轮的循环检查中，idle观察者 > I/O观察者 > check观察者
3、proces.nextTick()属于idle观察者，每次会追加在当前事件循环的队尾（类似微任务）

相比于同步式、每进程每请求、每线程每请求，事件驱动的方式不会阻塞CPU，也无需为每个请求创建额外对应的线程，在响应和处理业务上拥有独特的高性能。

node中处理异步I/O（与浏览器不同）

图解： https://www.jianshu.com/p/deedcbf68880

不同于浏览器中明晰的js执行栈、微任务和宏任务三种任务队列，node中自有一套执行的方案。首先执行同步任务，发出异步请求，发出定时器，执行nextTick+promise，然后进入事件循环。由于process.nextTick方法指定的回调函数，总是在当前"执行栈"的尾部触发，所以如果有多个process.nextTick语句（不管它们是否嵌套），将全部在当前"执行栈"执行。setImmediate总是将事件注册到下一轮Event Loop，多个setImmediate可能则需要多次loop才能执行完。

事件循环中有六个阶段，分析三个，其他三个由于是内部调用或不常见可以忽略

阶段	事件	执行
timers	setTimeout setInterval	事件循环开始，执行所有的宏任务，后执行所有的微任务
=>	pending callbacks(内部调用)=>	idle, prepare(内部调用) =>
poll	其他 MacroTask（基于事件订阅完成的API 网络请求或IO操作）	执行所有的宏任务，后执行所有的微任务，完成后，if(check){check}，else if(timers){则将绕回timers阶段}else if(timers和check都为空)，则阻塞在poll阶段等待，大部分的IO callback在此执行而pending callbacks执行的是上次延迟的一些回调
check	setImmidate	执行所有的宏任务，后执行所有的微任务
close callbacks	socket关闭	执行所有的宏任务，后执行所有的微任务，到此执行完一个tick，返回timers

process.nextTick 本质上属于 MicroTask，但是它先于所有其他 MicroTask（promise）执行；
所有 MicroTask 的执行时机，是不同类型 MacroTask 切换的时候。

注：setImmediate()具有最高优先级，只要poll队列为空，代码被setImmediate()，无论是否有timers达到下限时间，setImmediate()的代码都先执行。

更多：https://segmentfault.com/a/1190000013102056

举个栗子：

setTimeout(() => {
  console.log('timeout')
}, 0)
// 下限的时间有一个范围：[1, 2147483647]，如果设定的时间不在这个范围，将被设置为1。
setImmediate(() => {
  console.log('immediate')
})

在node中这段代码的输出是不确定先后顺序的，首先进入timer阶段，这跟机器性能有关

情况一：如果机器性能一般，在进入timers之前已经过去了1ms，那么将直接把回调函数推入timer队列，进入timers时则会直接执行timers的回调函数；
情况二：如果在进入timers之前还没有过去1ms，timers可执行回调队列为空，则进入poll阶段，poll队列为空，此时检查是否有代码被setImmediate()，于是执行check回调，此次Tick结束，在下一个事件循环timer中执行setTimeout回调。

首先进入的是timers阶段，如果我们的机器性能一般，那么进入timers阶段，一毫秒已经过去了（setTimeout(fn, 0)等价于setTimeout(fn, 1)），那么setTimeout的回调会首先执行。

如果没有到一毫秒，那么在timers阶段的时候，下限时间没到，setTimeout回调不执行，事件循环来到了poll阶段，这个时候队列为空，此时有代码被setImmediate()，于是先执行了setImmediate()的回调函数，之后在下一个事件循环再执行setTimemout的回调函数。

栗子2：

var fs = require('fs')

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

这里我们就会发现，setImmediate永远先于setTimeout执行。

原因如下：

fs.readFile的回调是在poll阶段执行的，当其回调执行完毕之后，poll队列为空，而setTimeout入了timers的队列，此时有代码被setImmediate()，于是事件循环先进入check阶段执行回调，之后在下一个事件循环再在timers阶段中执行有效回调。

所以只要不是在事件循环开始之前，有timer被推入的操作，只要已经进入了事件循环，进入了poll阶段，setImmediate将会先执行。

如果两者都在主模块中调用，那么执行先后取决于进程性能，也就是随机。
如果两者都不在主模块调用，那么setImmediate的回调永远先执行。

同样的

setTimeout(() => {
    setImmediate(() => {
        console.log('setImmediate');
    });
    setTimeout(() => {
        console.log('setTimeout');
    }, 0);
}, 0);

以上的代码在timers阶段执行外部的setTimeout回调后，内层的setTimeout和setImmediate入队，之后事件循环继续往后面的阶段走，走到poll阶段的时候发现队列为空，此时有代码被setImmedate()，所以直接进入check阶段执行响应回调（注意这里没有去检测timers队列中是否有成员到达下限事件，因为setImmediate()优先）。之后在第二个事件循环的timers阶段中再去执行相应的回调。

另外的

setImmediate(() => {
    setImmediate(() => {
        console.log('setImmediate');
    });
    setTimeout(() => {
        console.log('setTimeout');
    }, 0);
}, 0);

setImmediate()实际上是一个特殊的timer，跑在事件循环中的一个独立的阶段。它使用libuv的API来设定在poll阶段结束后立即执行回调。