nodejs为什么可以处理高并发而不阻塞？

NodeJs是一个平台，构建在v8上（js语言解释器），采用事件驱动、
总所周知，NodeJs是用javascript语言开发的，javascript是一个单线程语言。当Node服务器收到成千上万计的并发请求的时候，却不会造成阻塞。原因就是nodeJs的事件驱动。

1. 每个NodeJs进程只有一个主线程在执行程序代码，形成一个执行栈。
2. 主线程之外，还维护了一个事件队列。当用户的网络请求或者其他的异步操作到来的时候，node都会把它放在Event Queue中，此时并不会立即执行它，代码也不会被阻塞，继续走下去，直到主线程代码执行完毕。
3. 主线程的代码执行完毕之后，通过Event Loop，也就是事件循环机制，开始到Event Queue的开头取出第一个事件，从线程池中分配一个线程去执行这个事件，接下来取出第二个事件，再从线程池中分配一个线程去执行，然后第三个、第四个。主线程不断检查事件队列中是否有未执行的事件，直到事件队列中所有事件都执行完毕了。此后每当有新的事件加入到事件队列中，都会通知主线程按顺序去取出交给Event Loop处理。当所有的事件执行完毕之后，会通知主线程，主线程执行回调，线程归还线程池。
4. 主线程不断重复以上三步。

总结

我们看到的NodeJs单线程只是一个js主线程，本质上的异步操作还是由线程池完成的，node将所有的阻塞操作都交给了内部的线程池去实现，本身只负责不断的往返调度，并没有进行真正的I/O操作，从而实现异步非阻塞I/O，这便是node单线程的事件驱动的精髓了。

NodeJs中的事件循环的实现

NodeJs采用V8作为js的引擎，而I/O处理使用了自己设计的libuv，libuv是一个基于事件驱动的跨平台抽象层，封装了不同操作系统一些底层特性，对外提供统一的API，事件循环机制也是它里面的实现。

Event Loop的执行顺序

根据NodeJs的官方介绍，每次事件循环都包含了6个阶段：

• timers阶段：这个阶段执行timer（setTimeout、setInterval）的回调
• I/O callbacks阶段：执行一些系统调用错误，比如网络通信的错误回调
• idle，prepare阶段，仅node内部调用
• poll阶段：获取新的I/O事件，适当的条件下node将阻塞在这里
• check阶段：执行setImmediate()的回调
• close callbacks阶段：执行socket的close事件回调

setImmediate和setTimeout执行顺序的随机性

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

在浏览器中的setImmediate优先。因为浏览器中setTimeout有时间误差，即使setTimeout(fn， 0)，实际上相当于setTimeout（fn, 4);
在node中的执行结果确是随机的。

node中的事件循环阶段

NodeJs中事件循环模型与浏览器相比大致相同，但是node中事件循环是分阶段的。

每个阶段都有一个先进先出的对调队列要执行。而每个阶段都有自己的特殊之处。简单的说，就是当事件循环进入到某个阶段之后，会执行该阶段特定的任意操作，然后才会执行这个阶段里面的回调。当队列被执行完，或者执行的回调达到上限之后，事件循环才会到下一个阶段。

timers

一个timer指定一个下限时间而不是准确时间，在达到这个下线时间后执行回调。在指定时间过后，timers会尽早执行回调，但是系统调度或者其他的回调的执行会延迟它。

从技术上讲，poll阶段控制timers什么时候执行，而执行的具体位置在timers。

I/O callbacks

这个阶段执行一些系统操作的回调，比如说TCP连接错误

idle，prepare

系统内部的一些调用

poll

这是最复杂的阶段
poll阶段有两个功能：一个是执行下限时间已经达到timers的回调，一是处理poll队列里面的事件
注：Node很多Api都是基于事件订阅完成的，这些api的回调应该都在poll阶段完成。

check阶段

执行setImmediate的回调

close callback阶段
执行socket的close事件回调