1. 引言

同步异步 I/O，阻塞非阻塞 I/O 是程序员老生常谈的话题了，也是自己一直以来懵懵懂懂的一个话题。比如：何为同步异步？何为阻塞与非阻塞？二者的区别在哪里？阻塞在何处？为什么会有多种 IO 模型，分别用来解决问题？常用的框架采用的是何种 I/O 模型？各种 IO 模型的优劣势在哪里，适用于何种应用场景？

简而言之，对于 I/O 的认知，不能仅仅停留在字面上认识，了解内部玄机，才能深刻理解 I/O，才能看清 I/O 相关问题的本质。

2. I/O 的定义

I/O 的全称是 Input/Output。虽常谈及 I/O，但想必你也一时不能给出一个完整的定义。搜索了谷歌，发现也尽是些冗长的论述。要想厘清 I/O 这个概念，我们需要从不同的视角去理解它。

2.1. 计算机视角

冯•诺伊曼计算机的基本思想中有提到计算机硬件组成应为五大部分：控制器，运算器，存储器，输入和输出。其中输入是指将数据输入到计算机的设备，比如键盘鼠标；输出是指从计算机中获取数据的设备，比如显示器；以及既是输入又是输出设备，硬盘，网卡等。

用户通过操作系统才能完成对计算机的操作。计算机启动时，第一个启动的程序是操作系统的内核，它将负责计算机的资源管理和进程的调度。换句话说：操作系统负责从输入设备读取数据并将数据写入到输出设备。

所以 I/O 之于计算机，有两层意思：

1. I/O 设备

2. 对 I/O 设备的数据读写

对于一次 I/O 操作，必然涉及 2 个参与方，一个输入端，一个输出端，而又根据参与双方的设备类型，我们又可以分为磁盘 I/O，网络 I/O（一次网络的请求响应，网卡）等。

2.2. 程序视角

应用程序作为一个文件保存在磁盘中，只有加载到内存到成为一个进程才能运行。应用程序运行在计算机内存中，必然会涉及到数据交换，比如读写磁盘文件，访问数据库，调用远程 API 等等。但我们编写的程序并不能像操作系统内核一样直接进行 I/O 操作。

因为为了确保操作系统的安全稳定运行，操作系统启动后，将会开启保护模式：将内存分为内核空间（内核对应进程所在内存空间）和用户空间，进行内存隔离。我们构建的程序将运行在用户空间，用户空间无法操作内核空间，也就意味着用户空间的程序不能直接访问由内核管理的 I/O，比如：硬盘、网卡等。

但操作系统向外提供 API，其由各种类型的系统调用（System Call）组成，以提供安全的访问控制。

所以应用程序要想访问内核管理的 I/O，必须通过调用内核提供的系统调用(system call）进行间接访问。

所以 I/O 之于应用程序来说，强调的通过向内核发起系统调用完成对 I/O 的间接访问。换句话说应用程序发起的一次 IO 操作实际包含两个阶段：

1. IO 调用阶段：应用程序进程向内核发起系统调用

2. IO 执行阶段：内核执行 IO 操作并返回

2.1. 准备数据阶段：内核等待 I/O 设备准备好数据

2.2. 拷贝数据阶段：将数据从内核缓冲区拷贝到用户空间缓冲区

怎么理解准备数据阶段呢？

对于写请求：等待系统调用的完整请求数据，并写入内核缓冲区；

对于读请求：等待系统调用的完整请求数据；（若请求数据不存在于内核缓冲区）则将外围设备的数据读入到内核缓冲区。

而应用程序进程在发起 IO 调用至内核执行 IO 返回之前，应用程序进程/线程所处状态，就是我们下面要讨论的第二个话题阻塞 IO 与非阻塞 IO。

3. IO 模型之阻塞 I/O(BIO)

应用程序中进程在发起 IO 调用后至内核执行 IO 操作返回结果之前，若发起系统调用的线程一直处于等待状态，则此次 IO 操作为阻塞 IO。阻塞 IO 简称 BIO，Blocking IO。其处理流程如下图所示：

从上图可知当用户进程发起 IO 系统调用后，内核从准备数据到拷贝数据到用户空间的两个阶段期间用户调用线程选择阻塞等待数据返回。

因此 BIO 带来了一个问题：如果内核数据需要耗时很久才能准备好，那么用户进程将被阻塞，浪费性能。为了提升应用的性能，虽然可以通过多线程来提升性能，但线程的创建依然会借助系统调用，同时多线程会导致频繁的线程上下文的切换，同样会影响性能。所以要想解决 BIO 带来的问题，我们就得看到问题的本质，那就是阻塞二字。

4. IO 模型之非阻塞 I/O(NIO)

那解决方案自然也容易想到，将阻塞变为非阻塞，那就是用户进程在发起系统调用时指定为非阻塞，内核接收到请求后，就会立即返回，然后用户进程通过轮询的方式来拉取处理结果。也就是如下图所示：

应用程序中进程在发起 IO 调用后至内核执行 IO 操作返回结果之前，若发起系统调用的线程不会等待而是立即返回，则此次 IO 操作为非阻塞 IO 模型。非阻塞 IO 简称 NIO，Non-Blocking IO。

然而，非阻塞 IO 虽然相对于阻塞 IO 大幅提升了性能，但依旧不是完美的解决方案，其依然存在性能问题，也就是频繁的轮询导致频繁的系统调用，会耗费大量的 CPU 资源。比如当并发很高时，假设有 1000 个并发，那么单位时间循环内将会有 1000 次系统调用去轮询执行结果，而实际上可能只有 2 个请求结果执行完毕，这就会有 998 次无效的系统调用，造成严重的性能浪费。有问题就要解决，那 NIO 问题的本质就是频繁轮询导致的无效系统调用。

5. IO 模型之 IO 多路复用

解决 NIO 的思路就是降解无效的系统调用，如何降解呢？我们一起来看看以下几种 IO 多路复用的解决思路。

5.1. IO 多路复用之 select/poll

Select 是内核提供的系统调用，它支持一次查询多个系统调用的可用状态，当任意一个结果状态可用时就会返回，用户进程再发起一次系统调用进行数据读取。换句话说，就是 NIO 中 N 次的系统调用，借助 Select，只需要发起一次系统调用就够了。其 IO 流程如下所示：

但是，select 有一个限制，就是存在连接数限制，针对于此，又提出了 poll。其与 select 相比，主要是解决了连接限制。

select/epoll 虽然解决了 NIO 重复无效系统调用用的问题，但同时又引入了新的问题。问题是：

1. 用户空间和内核空间之间，大量的数据拷贝

2. 内核循环遍历 IO 状态，浪费 CPU 时间

换句话说，select/poll 虽然减少了用户进程的发起的系统调用，但内核的工作量只增不减。在高并发的情况下，内核的性能问题依旧。所以 select/poll 的问题本质是：内核存在无效的循环遍历。

5.2. IO 多路复用之 epoll

针对 select/pool 引入的问题，我们把解决问题的思路转回到内核上，如何减少内核重复无效的循环遍历呢？变主动为被动，基于事件驱动来实现。其流程图如下所示：

epoll 相较于 select/poll，多了两次系统调用，其中 epollcreate 建立与内核的连接，epollctl 注册事件，epoll_wait 阻塞用户进程，等待 IO 事件。

epoll，已经大大优化了 IO 的执行效率，但在 IO 执行的第一阶段：数据准备阶段都还是被阻塞的。所以这是一个可以继续优化的点。

6. IO 模型之信号驱动 IO(SIGIO)

信号驱动 IO 与 BIO 和 NIO 最大的区别就在于，在 IO 执行的数据准备阶段，不会阻塞用户进程。

如下图所示：当用户进程需要等待数据的时候，会向内核发送一个信号，告诉内核我要什么数据，然后用户进程就继续做别的事情去了，而当内核中的数据准备好之后，内核立马发给用户进程一个信号，说”数据准备好了，快来查收“，用户进程收到信号之后，立马调用 recvfrom，去查收数据。

乍一看，信号驱动式 I/O 模型有种异步操作的感觉，但是在 IO 执行的第二阶段，也就是将数据从内核空间复制到用户空间这个阶段，用户进程还是被阻塞的。

综上，你会发现，不管是 BIO 还是 NIO 还是 SIGIO，它们最终都会被阻塞在 IO 执行的第二阶段。

那如果能将 IO 执行的第二阶段变成非阻塞，那就完美了。

7. IO 模型之异步 IO(AIO)

异步 IO 真正实现了 IO 全流程的非阻塞。用户进程发出系统调用后立即返回，内核等待数据准备完成，然后将数据拷贝到用户进程缓冲区，然后发送信号告诉用户进程 IO 操作执行完毕（与 SIGIO 相比，一个是发送信号告诉用户进程数据准备完毕，一个是 IO 执行完毕）。其流程如下：

所以，之所以称为异步 IO，取决于 IO 执行的第二阶段是否阻塞。因此前面讲的 BIO，NIO 和 SIGIO 均为同步 IO。

8. 总结

梳理完这些 IO 模型后，之前一直处于懵懂状态的阻塞，非阻塞，同步异步 IO，终于算是有个概念了。同时也纠正了自己一直以来的误解，所以一路走来，愈发觉得返璞归真的重要性，只有如此，才能在快速更迭的技术演进中，以不变应万变。

本片综合多方资料写就，难免纰漏，但只有写下来，才能得以指正。所以，烦请各位看官不吝赐教。

参考资料：

1. 程序员应该这样理解IO

2. IO复用模型同步，异步，阻塞，非阻塞及实例详解

3. 服务器网络编程之 IO 模型

4. http://www.c-jump.com/CIS77/CPU/VonNeumann/lecture.html

5. 同步I/O(阻塞I/O，非阻塞I/O)，异步I/O

6. 马士兵：权威讲解nio,epoll,多路复用

7. Linux 内核详解以及内核缓冲区技术