串起同步/异步、阻塞/非阻塞 IO模型

我们需要明确一点，我们在聊IO的时候,主要是聊用户进程和系统内核进程之间的read\white操作。

关键词：

1.阻塞：是指用户进程向内核进程提交请求，之后等待内核准备数据,线程一直处于阻塞状态，也就是"傻等"；

非阻塞：是指用户进程向内核进程提交请求，之后看内核进程是否已经准备好数据,如果准备好则进行读取到用户进程，如果没有准备好，则不进行等待，直接返回结果，但是会不断去尝试发起请求获取结果；

2.同步：是一种用户空间与内核空间的IO发起方式。同步IO是指用户空间的线程是主动发起IO请求的一方，内核空间是被动接受方

简单来说：阻塞是指用户空间（调用线程）一直在等待，而不能干别的事情；非阻塞是指用户空间（调用线程）拿到内核返回的状态值就返回自己的空间，IO操作可以干就干，不可以干，就去干别的事情。

3.异步IO：异步IO则反过来，是指系统内核是主动发起IO请求的一方，用户空间的线程是被动接受方(比如用户进程提供回调，用户空间的线程向内核空间注册了各种IO事件的回调函数，由内核去主动调用)；

4.IO多路复用：即经典的Reactor反应器设计模式，有时也称为异步阻塞IO, Java中的Selector选择器和Linux中的epoll都是这种模型。其实多路复用和同步非阻塞是密不可分的；

 

同步阻塞IO（Blocking IO）

在阻塞式IO模型中，Java应用程序从IO系统调用开始，直到系统调用返回，在这段时间内，Java进程是阻塞的。返回成功后，应用进程开始处理用户空间的缓存区数据。模型如下图:

阻塞IO的优点是：应用的程序开发非常简单；在阻塞等待数据期间，用户线程挂起。在阻塞期间，用户线程基本不会占用CPU资源。阻塞IO的缺点是：一般情况下，会为每个连接配备一个独立的线程；反过来说，就是一个线程维护一个连接的IO操作。在并发量小的情况下，这样做没有什么问题。但是，当在高并发的应用场景下，需要大量的线程来维护大量的网络连接，内存、线程切换开销会非常巨大。因此，基本上阻塞IO模型在高并发应用场景下是不可用的。

同步非阻塞NIO（None Blocking IO）

（1）在内核缓冲区中没有数据的情况下，系统调用会立即返回，返回一个调用失败的信息。

（2）在内核缓冲区中有数据的情况下，是阻塞的，直到数据从内核缓冲复制到用户进程缓冲。复制完成后，系统调用返回成功，应用进程开始处理用户空间的缓存数据。

模型图如下：

（1）在内核数据没有准备好的阶段，用户线程发起IO请求时，立即返回。所以，为了读取到最终的数据，用户线程需要不断地发起IO系统调用。

IO多路复用模型（IO Multiplexing）

在IO多路复用模型中，引入了一种新的系统调用，查询IO的就绪状态。在Linux系统中，对应的系统调用为select/epoll系统调用。通过该系统调用，一个进程可以监视多个文件描述符。目前支持IO多路复用的系统调用，有select、epoll等等

举个例子来说明IO多路复用模型的流程:

发起一个多路复用IO的read读操作的系统调用，流程如下：

（1）选择器注册。在这种模式中，首先，将需要read操作的目标socket网络连接，提前注册到select/epoll选择器中;

（2）就绪状态的轮询。通过选择器的查询方法，查询注册过的所有socket连接的就绪状态。通过查询的系统调用，内核会返回一个就绪的socket列表。当任何一个注册过的socket中的数据准备好了，内核缓冲区有数据（就绪）了，内核就将该socket加入到就绪的列表中。当用户进程调用了select查询方法，那么整个线程会被阻塞掉。

（3）用户线程主动获得了就绪状态的列表后，根据其中的socket连接，发起read系统调用，用户线程阻塞。内核开始复制数据，将数据从内核缓冲区复制到用户缓冲区。

（4）复制完成后，内核返回结果，用户线程才会解除阻塞的状态，用户线程读取到了数据，继续执行。

异步IO模型（Asynchronous IO）

在异步IO模型中，在整个内核的数据处理过程中，包括内核将数据从网络物理设备（网卡）读取到内核缓冲区、将内核缓冲区的数据复制到用户缓冲区，用户程序都不需要阻塞。

就目前而言，Windows系统下通过IOCP实现了真正的异步IO。而在Linux系统下，异步IO模型在2.6版本才引入，目前并不完善，其底层实现仍使用epoll，与IO多路复用相同，因此在性能上没有明显的优势。大多数的高并发服务器端的程序，一般都是基于Linux系统的。因而，目前这类高并发网络应用程序的开发，大多采用IO多路复用模型。大名鼎鼎的Netty框架，使用的就是IO多路复用模型，而不是异步IO模型。