IO系列文章3：Unix中的IO模型：帮你弄清阻塞VS非阻塞、同步VS异步

对同步和异步、阻塞和非阻塞这些名词困惑了很久了，曾经相当然的认为阻塞就是同步、非阻塞就是异步，这也是典型的错误，后来从Unix网络编程卷1上才看到最全面的解析，下面主要的内容来自Unix网络编程，算是自己的一个学习笔记吧！

由于这本书中面向的是Unix编程，所以在其他的环境中IO模型可能会有稍微的不同，比如Java中的IO模型，但是也不会相差很多，毕竟Unix作为众多技术的鼻祖，很多的思想和实现都来自它。

首先要明白输入和输出操作的过程，这个过程包括两个阶段：

等待数据准备好：这里所说的准备好指的是数据已经到硬件设备上了，而不管该数据的来源是什么，可能是通过网线或者无线电传输过来的010101，还有可能是本机进程通过系统调用写到存储器上的101011，总而言之此时硬件设备上必须要有对应的数据才能算是准备好；
将数据从内核中复制到相应的进程中：更明确的说，是通过内核将硬件设备上的数据复制到进程空间中然后进行进一步的操作，这个过程其实是应用进程通过调用内核提供的系统接口完成的。

这个过程如下图：

其实在这个过程中内核空间其实是担当了一个代理人的角色，进程通过调用内核提供的系统接口才能读取硬件上存储的数据。所以上面的两个过程说的更抽象一点：一个是硬件已经存在数据，软件能够读取数据。

由于上图也涉及到了进程之间的通信，有必要说明一下，进程之间通信不一定要通过操作系统内核，比如共享内存就不会经过内核，但是其他的比如管道等还是会经过内核。

一、阻塞式I/O模型

对于写过IO程序的人来说，这种模型一定不陌生，不管是使用C还是Java，内部默认的都是这种IO模型，这类所谓的阻塞其实是指应用进程受阻于内核提供的系统调用，该调用直到数据成功返回或者出错才返回（其他情况下不返回），这时阻塞结束。具体如下图：

二、非阻塞式IO模型

所谓非阻塞，是和阻塞式相对应的，不过这种非阻塞也是相对的。与阻塞式中的系统调用返回时机不同，在非阻塞式中当应用进程调用系统接口时，如果数据没有准备好，则会返回一个标志来标识这种情况，这时系统应用知道数据没有准备好则不会一直阻塞，而是通过隔一段时间轮询一次，在两次轮询的间隙之间应用进程可以做其他的事情。具体如下图：

从上图可以看出，所谓非阻塞式和阻塞式的区别和联系在于：

在处理数据的第一阶段不同，即确定数据是否准备好；
- 阻塞式IO模型对这一阶段不做任何干涉，如果没准备好就不返回；
- 非阻塞式IO模型则对内核进行轮询，如果没有准备好则返回一个标志，这种方式虽然在一定程度上解放了应用进程，但是却占用了CPU的大量时间；
在处理的数据的第二个阶段，两种模型则是完全相同的；

当然这种模型的实现需要系统内核支持读取数据时的多状态标识。

三、IO复用模型

IO复用模型中的“复用”是该模型的核心，究竟复用的是什么？如何进行复用呢？这里还是要联系上之前的两个模式，在之前的两个模式中，应用进程都是直接调用真正的IO系统接口，这个接口是面向应用进行直接读取硬件上的数据的。但是在IO复用模型中，应用进程直接调用的是一个选择器select/poll，这个选择器类似于一个数字电路中的多路开关，如下图：

这种模型相当于在应用进程和直接IO系统调用之间添加了一个代理，之前的阻塞和非阻塞模型由于是直接面向IO系统调用的，可以看成为其中有一个隐形的代理，但是只能代理一个IO通道；但是在IO复用模型中，该代理可以代理多个IO通道，所以复用的其实是IO通道。当有一个IO通道可以进行读写时，则select/poll返回告诉应用进程，此时应用进程开始执行对应的读写操作，这里需要注意的是select/poll上的通道是需要应用进程自己去注册的，通道可以是读操作，也可以是写操作。具体如下图：

从图中可以看出，IO复用模型与阻塞式和非阻塞式模型的关系如下：

相对于阻塞式模型，从图中看，其实就是多了上半部分的select选择器代理，如果当IO通道只有一个的时候，IO复用模型的效率相对于阻塞模型可能会更差一些，因为它经过两层系统调用，但是当IO通道多的时候，IO复用模型的效率就显示出来了；
相对于非阻塞式模型，相当于将应用进程执行的轮询操作交给了操作系统内核的select/poll来做，但是非阻塞式模型中轮询的是一个IO通道的状态，而IO复用模型中轮询的是多个IO通道的状态；
IO复用模型是阻塞于select/poll系统调用，而阻塞式模型和非阻塞式模型则是阻塞于直接IO系统调用；

与IO复用模型非常相似的一种模型，是通过多线程结合阻塞式模型，这种阻塞式模型的变体看起来和IO复用模型、非阻塞式模型相同，会让人误以为这种模型就是非阻塞式的，IO复用模型和非阻塞时模型的区别上面已经说明，而这种多线程结合阻塞式模型的一个非常大的不同就是它并不需要去轮询IO通道，而是通过一个线程执行一次系统调用来执行IO系统操作，这样就不会占用大量CPU的时间，但是维护多线程环境则会占用较多资源，并给编程带来一些挑战。

四、信号驱动式IO模型

信号驱动式IO模型与之前的非阻塞时模型和IO复用模型类似，但是对应用进程的通知不是通过轮询实现的，而是使用信号机制来实现，这就使得在第一阶段，等待数据准备的时候，应用进程确确实实的不阻塞，具体如下图：

在该图中可以看出，其实应用进程是调用操作系统内核提供的signal信号处理接口，但是该接口不会造成阻塞而是立即返回。当数据准备好了之后内核则再返回一个信号，告诉应用程序。而之后的过程前面三种模型完全一样，应用进程仍然会阻塞知道数据复制完毕。从第一个阶段的是过程来看，极有可能的一种实现方式就是通过函数回调来完成这种通知。

五、异步IO模型

其实在上面的4种模型说明后，异步IO模型就呼之欲出了，在前面4种模型中不管怎么优化，针对的对象都是数据输入的第一个阶段，即等待数据准备好，如果将数据复制过程也考虑进来，那么结果就清晰了，顺着信号驱动模IO模型，将信号通知的时机放到数据复制完成之后，就是一步IO模型，这样从整体上来看，应用进程从来没有阻塞过，而是一直运行，直到被通知数据已经被复制到自己的空间中了。具体如下：

六、模型对比

6.1 同步模型之间

上面所说的4种模型：

阻塞式IO模型
非阻塞式IO模型
IO复用模型
信号驱动式IO模型

都是同步模型，它们的主要区别在第一阶段，每个模型中应用进程阻塞的实现和方式不同，而在第二个阶段则全部相同，都会阻塞于内核复制数据过程。所以不管阻塞和还是不阻塞都是同步模型。它们的区别是在准备数据的过程中，应用进程是不是阻塞。

6.2 同步模型 VS 异步模型

同步模型：导致应用进程阻塞，直到IO操作完成；
异步模型：不会造成应用进程阻塞；

上面5种模型的对比如下图：

要说明的是，异步和多线程并不是相同的概念，虽然我们在平时经常将两者混用，其实它们不是一个层次上的概念，异步具体的说是要达到的目的，而多线程只是实现这个目的的一个手段，还有其他的手段，比如多进程，但是由于常用的实现异步的方式就是多线程，所以常常将两者混淆，因此针对多线程的编程准确的来说应该是并发编程而不是异步编程。所以在上面提到的多线程结合阻塞IO模型，虽然使用了多线程，但是从本质上来说，每个线程对应的仍是阻塞IO模型，所以它也是同步模型，只不过是从主线程来看达到了异步的效果。

关于异步和多线程的关系