Node.js 非阻塞式I/O的理解

Node.js 作为高性能的Web服务器，得益于其 “事件驱动，非阻塞式I/O” 的特性。

Web服务器主要工作就是：应答浏览器请求，处理网络I/O。

有的Web服务器采用的是多线程应答客户端请求，即每个客户端请求都分配一个线程。

有的Web服务器采用的是单线程应答客户端请求，即一个线程处理所有客户端请求。

单线程应答机制，很容易发生大面积同步阻塞，即所有请求都被阻塞。

而多线程应答机制，虽然不会发生大面积同步阻塞，即只会发生某个请求对应的线程阻塞，而不是所有请求都被阻塞，但是每个线程都需要占用内存和CPU资源，如果服务器收到大量请求的话，会发生服务器宕机。

而传统的服务器软件都采用多线程应答机制，比如Tomcat。由于是多线程应答机制，所以Tomcat不会担心单个请求线程同步阻塞的情况，因为不会干扰到其他请求的正常工作，Tomcat更多关注的是多线程之间的协调工作，以及线程资源的精简分配。

而Node.js采用的是单线程应答机制，这个单线程就是v8引擎主线程，所以一旦发生同步阻塞，所有的请求都会被阻塞。那么Node.js为什么还要采用单线程应答机制呢？

因为单线程应答机制占用更少的内存和CPU资源，对服务器是非常友好的。

而且Node.js的作者在研究高性能的web服务器的过程中，发现服务器大部分的同步阻塞都来自于I/O操作。

什么是I/O操作？

I/O操作，通常是指文件I/O操作，即读文件和写文件，

读文件，其实就是将磁盘中的数据，输入到，内存中

写文件，其实就是将内存中的数据，输出到，磁盘中

即读文件，对应内存数据的Input，写文件，对应内存数据的Output，统称I/O操作。

I/O操作其实是硬件层面的操作，即磁盘和内存之间的数据传递，这种操作只能由操作系统内核发起的，一般不需要CPU参与，CPU只负责处理软件层面程序语言解释后操作系统指令。

即 I/O操作 和 CPU运算 可以并行。

操作系统内核的I/O操作，有两种，阻塞式和非阻塞式。

阻塞式I/O是指：应用程序需要等待操作系统内核将I/O操作结果返回才能继续执行

非阻塞式I/O是指：应用程序通知操作系统内核发起I/O操作后，不需要等待I/O操作结果，可以直接后续代码执行，但是需要I/O操作结果时，需要不断轮询I/O操作结果。

可以分析出，

当某段程序通知操作系统内核发起阻塞式I/O操作时，支持该程序运行的线程就会进入CPU空转状态，即霸占着CPU，并以等待阻塞式I/O返回结果，虽然I/O操作并不需要CPU参与。

当某段程序通知操作系统内核发起非阻塞式I/O操作时，支持该程序运行的线程不会等待I/O结果，而是继续后面程序的执行。这是CPU友好的，即非阻塞式I/O不会造成CPU空转。但是遗憾的是，非阻塞式I/O的结果需要不断去轮询，而轮询操作也是需要CPU支持的。

而经常和硬件层面的阻塞式I/O，非阻塞式I/O发生混淆的概念是，软件设计层面的 同步I/O 和 异步I/O：

同步I/O，程序运行和I/O操作跟踪只使用一个线程，导致I/O操作会阻塞程序运行。

异步I/O，程序运行和I/O操作跟踪使用两个线程，这样程序运行就避免了被I/O操作阻塞

可以发现，异步I/O 并不一定是基于非阻塞式I/O的。

因为异步I/O有两个线程支持，完全可以使用主线程处理代码运行，遇到阻塞式I/O操作时，直接开启一个分线程跟踪处理。也能实现异步I/O。

对于传统的Web服务器，大多是基于同步I/O设计的，如Apache Tomcat，由于采用了同步I/O的设计思路，所以为了避免单线程阻塞所有客户端请求，所以采用的多线程应答机制。

但是服务器每开启一个线程，都意味着要分出一部分内存和CPU执行权，所以大量线程会占用服务器有限的内存和CPU资源，对服务器的性能造成影响。

而Node.js服务器，是基于异步I/O设计的，它应答客户端请求的线程只有一个，且就是支持程序运行的线程，即JS主线程。

但是Node.js却不会因为I/O操作，发生客户端请求阻塞，因为Node.js采用了异步I/O。

Node.js实现异步I/O是基于底层libuv库，在libuv库中有一个线程池，其中的线程用于处理异步任务。

即当Node.js主线程执行JS代码过程中，遇到异步任务，如I/O操作，就会将该异步任务交给libuv线程池处理。JS主线程继续后续代码执行。

如果操作系统层面，I/O模型是阻塞式的，则线程池线程会等待I/O操作结果，

如果操作系统层面，I/O模型是非阻塞的，则线程池会不断轮询I/O操作结果。

当线程池线程获得I/O操作结果后，会将结果和回调函数一起加入异步任务队列。

当JS主线程将程序代码执行完毕后，就会进行事件循环，不断取出任务队列的结果和回调函数，并执行。