共计 7291 个字符，预计需要花费 19 分钟才能阅读完成。
武侠小说里有很多的“心法”和“招式”。计算机技术里的“心法”和“招式”呢，咱们能够简称为“道”和“术”；
“道” 最根底的计算机实践，暗藏于表象之下，十分形象、艰涩难懂，须要用具象化的事物加以了解；
“术”具体的技能，它有可能是一门语言，比方：python 出手见效快；
咱们明天要给大家讲的底层的 IO 就属于“道”的领域，看上去简略，实则形象。并且在它之上衍生出了语言层面用于实战的技术，比方咱们相熟的 java 语言中的 NIO 或者像 Netty 这样的框架。
一、凌乱的 IO 概念
IO 是 Input 和 Output 的缩写，即输出和输入。狭义上的围绕计算机的输入输出有很多：鼠标、键盘、扫描仪等等。而咱们明天要探讨的是在计算机外面，次要是作用在内存、网卡、硬盘等硬件设施上的输入输出操作。
谈起 IO 的模型，大多数人脑子里必定是一坨凌乱的概念，“阻塞”、“非阻塞”，“同步”、“异步”有什么区别？很多同学傻傻分不清，有尝试去搜寻相干材料去探索假相，后果又被吞没在茫茫的概念之中。
这里尝试简略地去解释下为啥会呈现这种景象，其中一个很重要的起因就是大家看到的材料对概念的解释都站在了不同的角度，有的站在了底层内核的视角，有的间接在 java 层面或者 Netty 框架层面给大家介绍 API，所以给大家造成了肯定水平的困扰。
所以在开篇之前，还是要说下本文所站的视角，咱们将会从底层内核的层面给大家解说下 IO。因为万变不离其宗，只有理解了底层原理，不论语言层面如何花里胡哨，咱们都能以不变应万变。
二、用户空间和内核空间
为了便于大家了解简单的 IO 以及零拷贝相干的技术，咱们还是得花点工夫在回顾下操作系统相干的常识。这一节咱们重点看下用户空间和内核空间，基于此前面咱们能力更好地聊聊多路复用和零拷贝。
硬 件 层（Hardware）
包含和咱们熟知的和 IO 相干的 CPU、内存、磁盘和网卡几个硬件；
内核空间（Kernel Space）
计算机开机后首先会运行内核程序，内核程序占用的一块公有的空间就是内核空间，并且可反对拜访 CPU 所有的指令集（ring0 – ring3）以及所有的内存空间、IO 及硬件设施；
用户空间（User Space）
每个一般的用户过程都有一个独自的用户空间，用户空间只能拜访受限的资源（CPU 的“保护模式”）也就是说用户空间是无奈间接操作像内存、网卡和磁盘等硬件的；
如上所述，那咱们可能会有疑难，用户空间的过程想要去拜访或操作磁盘和网卡该怎么办呢？
为此，操作系统在内核中开拓了一块惟一且非法的调用入口“System Call Interface”，也就是咱们常说的零碎调用，零碎调用为下层用户提供了一组可能操作底层硬件的 API。这样一来，用户过程就能够通过零碎调用拜访到操作系统内核，进而就可能间接地实现对底层硬件的操作。这个拜访的过程也即用户态到内核态的切换。常见的零碎调用有很多，比方：内存映射 mmap()、文件操作类的 open()、IO 读写 read()、write()等等。
三、IO 模型
1、BIO（Blocking IO）
咱们先看一下大家都相熟的 BIO 模型的 Java 伪代码：
ServerSocket serverSocket = new ServerSocket(8080); // step1: 创立一个 ServerSocket，并监听 8080 端口
while(true) { // step2: 主线程进入死循环
Socket socket = serverSocket.accept(); // step3: 线程阻塞，开启监听
BufferedReader reader = new BufferedReader(nwe InputStreamReader(socket.getInputStream()));
System.out.println("read data:" + reader.readLine()); // step4: 数据读取
PrintWriter print = new PrintWriter(socket.getOutputStream(), true);
print.println("write data"); // step5: socket 数据写入
}这段代码能够简略了解成一下几个步骤：
- 创立 ServerSocket，并监听 8080 端口；
- 主线程进入死循环，用来阻塞监听客户端的连贯，socket.accept()；
- 数据读取，socket.read()；
- 写入数据，socket.write()；
问题
以上三个步骤：accept(…)、read(…)、write(…)都会造成线程阻塞。上述这个代码应用了单线程，会导致主线程会间接夯死在阻塞的中央。
优化
咱们要晓得一点“过程的阻塞是不会耗费 CPU 资源的”，所以在多核的环境下，咱们能够创立多线程，把接管到的申请抛给多线程去解决，这样就无效地利用了计算机的多核资源。甚至为了防止创立大量的线程解决申请，咱们还能够进一步做优化，创立一个线程池，利用池化技术，对临时解决不了的申请做一个缓冲。
2、“C10K”问题
“C10K”即“client 10k”用来指代数量宏大的客户端；
BIO 看上去十分的简略，事实上采纳“BIO+ 线程池”来解决大量的并发申请还是比拟适合的，也是最优的。然而面临数量宏大的客户端和申请，这时候应用多线程的弊病就逐步凸显进去了：
- 重大依赖线程，线程还是比拟耗系统资源的（一个线程大概占用 1M 的空间）；
- 频繁地创立和销毁代价很大，因为波及到简单的零碎调用；
- 线程间上下文切换的老本很高，因为产生线程切换前，须要保留上一个工作的状态，以便切回来的时候，能够再次加载这个工作的状态。如果线程数量宏大，会造成线程做上下文切换的工夫甚至大于线程执行的工夫，CPU 负载变高。
3、NIO 非阻塞模型
上面开始真正走向 Java NIO 或者 Netty 框架所形容的“非阻塞”，NIO 叫 Non-Blocking IO 或者 New IO，因为 BIO 可能会引入的大量线程，所以能够简略地了解 NIO 解决问题的形式是通过单线程或者大量线程达到解决大量客户端申请的目标。为了达成这个目标，首先要做的就是把阻塞的过程非阻塞化。要想做到非阻塞，那必须得要有内核的反对，同时须要对用户空间的过程裸露零碎调用函数。所以，这里的“非阻塞”能够了解成零碎调用 API 级别的，而真正底层的 IO 操作都是阻塞的，咱们前面会缓缓介绍。
事实上，内核曾经对“非阻塞”做好了反对，举个咱们刚刚说的的 accept()办法阻塞的例子（Tips：java 中的 accept 办法对应的零碎调用函数也叫 accept），看下官网文档对其非阻塞局部的形容。
官网文档对 accetp()零碎调用的形容是通过把 ”flags“ 参数设成 ”SOCK_NONBLOCK“ 就能够达到非阻塞的目标，非阻塞之后线程会始终解决轮询调用，这时候能够通过每次返回非凡的异样码“EAGAIN”或 ”EWOULDBLOCK“ 通知主程序还没有连贯达到能够持续轮询。
咱们能够很容易设想程序非阻塞之后的一个大抵过程。所以，非阻塞模式有个最大的特点就是：用户过程须要一直去被动询问内核数据筹备好了没有！
上面咱们通过一段伪代码，看下这个调用过程：
// 循环遍历
while(1) {
// 遍历 fd 汇合
for (fdx in range(fd1, fdn)) {
// 如果 fdx 有数据
if (null != fdx.data) {
// 进行读取和解决
read(fdx)&handle(fdx);
}
}
}这种调用形式也暴露出非阻塞模式的最大的弊病，就是须要让用户过程一直切换到内核态，对连贯状态或读写数据做轮询。有没有一种形式来简化用户空间 for 循环轮询的过程呢？那就是咱们上面要重点介绍的IO 多路复用模型。
4、IO 多路复用模型
非阻塞模型会让用户过程始终轮询调用零碎函数，频繁地做内核态切换。想要做优化其实也比较简单，咱们假想个业务场景，A 业务零碎会调用 B 的根底服务查问单个用户的信息。随着业务的倒退，A 的逻辑变简单了，须要查 100 个用户的信息。很显著，A 心愿 B 提供一个批量查问的接口，用汇合作为入参，一次性把数据传递过来就省去了频繁的零碎间调用。
多路复用理论也差不多就是这个实现思路，只不过入参这个“汇合”须要你注册 / 填写感兴趣的事件，读 fd、写 fd 或者连贯状态的 fd 等，而后交给内核帮你进行解决。
那咱们就具体来看看多路复用外面大家都可能听过的几个零碎调用 \- select()、poll()、epoll()。
4.1 select()
select() 构造函数信息如下所示：
/**
* select()零碎调用
*
* 参数列表：* nfds - 值为最大的文件描述符 +1
* *readfds - 用户查看可读性
* *writefds - 用户查看可写性
* *exceptfds - 用于查看外带数据
* *timeout - 超时工夫的构造体指针
*/
int select（int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout）;官网文档对 select() 的形容：
DESCRIPTION
select() and pselect() allow a program to monitor multiple file descriptors, waiting until one or more of the file descriptors become “ready” for some class of I/O operation (e.g.,input possible). A file descriptor is considered ready if it is possible to perform the corresponding I/O operation (e.g., read(2)) without blocking.
select()容许程序监控多个 fd，阻塞期待直到一个或多个 fd 达到 ” 就绪 ” 状态。
内核应用 select() 为用户过程提供了相似批量的接口，函数自身也会始终阻塞直到有 fd 为就绪状态返回。上面咱们来具体看下 select() 函数实现，以便咱们更好地剖析它有哪些优缺点。在 select() 函数的结构器里，咱们很容易看到 ”fd_set“ 这个入参类型。它是用位图算法 bitmap 实现的，应用了一个大小固定的数组（fd\_set 设置了 FD\_SETSIZE 固定长度为1024），数组中的每个元素都是 0 和 1 这样的二进制 byte，0,1 映射 fd 对应地位上是否有读写事件，举例：如果 fd == 5，那么 fd_set = 000001000。
同时 fd_set 定义了四个宏来解决 bitmap：
- FD_ZERO(&set); // 初始化，清空的作用，使汇合中不含任何 fd
- FD_SET(fd, &set); // 将 fd 退出 set 汇合，给某个地位赋值的操作
- FD_CLR(fd, &set); // 将 fd 从 set 汇合中革除，去掉某个地位的值
- FD_ISSET(fd, &set); // 校验某地位的 fd 是否在汇合中
应用 bitmap 算法的益处非常明显，运算效率高，占用内存少（应用了一个 byte，8bit）。咱们用伪代码和图片来形容下用户过程调用 select()的过程：
假如 fds 为 {1, 2, 3, 5, 7} 对应的 bitmap 为 ”01110101″，抛给内核空间轮询，当有读写事件时从新标记同时进行阻塞，而后整体返回用户空间。由此咱们能够看到 select()零碎调用的弊病也是比拟显著的：
- 复杂度 O(n)，轮询的工作交给了内核来做，复杂度并没有变动，数据取出后也须要轮询哪个 fd 上产生了变动；
- 用户态还是须要一直切换到内核态，直到所有的 fds 数据读取完结，整体开销仍然很大；
- fd_set 有大小的限度，目前被硬编码成了1024；
- fd_set 不可重用，每次操作完都必须重置；
4.2 poll()
poll() 构造函数信息如下所示：
/**
* poll()零碎调用
*
* 参数列表：* *fds - pollfd 构造体
* nfds - 要监督的描述符的数量
* timeout - 等待时间
*/
int poll（struct pollfd *fds, nfds_t nfds, int *timeout）;
### pollfd 的构造体
struct pollfd{
int fd；// 文件描述符
short event；// 申请的事件
short revent；// 返回的事件
}官网文档对 poll() 的形容：
DESCRIPTION
poll() performs a similar task to select(2): it waits for one of a set of file descriptors to become ready to perform I/O.
poll() 十分像 select()，它也是阻塞期待直到一个或多个 fd 达到 ” 就绪 ” 状态。
看官网文档形容能够晓得，poll()和 select() 是十分类似的，惟一的区别在于 poll() 摒弃掉了位图算法，应用自定义的构造体 pollfd，在pollfd 外部封装了 fd，并通过 event 变量注册感兴趣的可读可写事件（POLLIN、POLLOUT），最初把 pollfd 交给内核。当有读写事件触发的时候，咱们能够通过轮询 pollfd，判断 revent 确定该 fd 是否产生了可读可写事件。
老样子咱们用伪代码来形容下用户过程调用 poll() 的过程：
poll() 绝对于select()，次要的劣势是应用了 pollfd 的构造体：
- 没有了 bitmap 大小 1024 的限度；
- 通过构造体中的 revents 置位；
然而用户态到内核态切换及 O(n)复杂度的问题仍旧存在。
4.3 epoll()
epoll()应该是目前最支流，应用范畴最广的一组多路复用的函数调用，像咱们熟知的 Nginx、Redis 都宽泛地应用了此种模式。接下来咱们重点剖析下，epoll()的实现采纳了“三步走”策略，它们别离是epoll\_create()、epoll\_ctl()、epoll_wait()。
4.3.1 epoll_create()
/**
* 返回专用的文件描述符
*/
int epoll_create（int size）;用户过程通过 epoll_create() 函数在内核空间外面创立了一块空间（为了便于了解，能够设想成创立了一块白板），并返回了形容此空间的 fd。
4.3.2 epoll_ctl()
/**
* epoll_ctl()零碎调用
*
* 参数列表：* epfd - 由 epoll_create()返回的 epoll 专用的文件描述符
* op - 要进行的操作例如注册事件, 可能的取值: 注册 -EPOLL_CTL_ADD、批改 -EPOLL_CTL_MOD、删除 -EPOLL_CTL_DEL
* fd - 关联的文件描述符
* event - 指向 epoll_event 的指针
*/
int epoll_ctl（int epfd, int op, int fd , struce epoll_event *event）;刚刚咱们说通过 epoll_create() 能够创立一块具体的空间“白板”，那么通过 epoll_ctl() 咱们能够通过自定义的 epoll_event 构造体在这块 ” 白板上 ” 注册感兴趣的事件了。
- 注册 \- EPOLL\_CTL\_ADD
- 批改 \- EPOLL\_CTL\_MOD
- 删除 \- EPOLL\_CTL\_DEL
4.3.3 epoll_wait()
/**
* epoll_wait()返回 n 个可读可写的 fds
*
* 参数列表：* epfd - 由 epoll_create()返回的 epoll 专用的文件描述符
* epoll_event - 要进行的操作例如注册事件, 可能的取值: 注册 -EPOLL_CTL_ADD、批改 -EPOLL_CTL_MOD、删除 -EPOLL_CTL_DEL
* maxevents - 每次能解决的事件数
* timeout - 期待 I / O 事件产生的超时值；- 1 相当于阻塞，0 相当于非阻塞。个别用 - 1 即可
*/
int epoll_wait（int epfd, struce epoll_event *event , int maxevents, int timeout）;epoll_wait() 会始终阻塞期待，直到硬盘、网卡等硬件设施数据筹备实现后发动 硬中断 ，中断 CPU，CPU 会立刻执行数据拷贝工作，数据从磁盘缓冲传输到内核缓冲，同时将筹备实现的 fd 放到就绪队列中供用户态进行读取。用户态阻塞进行，接管到 具体数量 的可读写的 fds，返回用户态进行数据处理。
整体过程能够通过上面的伪代码和图示进一步理解：
epoll() 基本上完满地解决了 poll() 函数遗留的两个问题：
- 没有了频繁的用户态到内核态的切换；
- O(1)复杂度，返回的 ”nfds” 是一个确定的可读写的数量，相比于之前循环 n 次来确认，复杂度升高了不少；
四、同步、异步
仔细的敌人可能会发现，本篇文章始终在解释“阻塞 ”和“ 非阻塞 ”，“ 同步 ”、“ 异步 ”的概念没有波及，其实在很多场景下同步 & 异步和阻塞 & 非阻塞基本上是一个同义词。阻塞和非阻塞适宜从零碎调用 API 层面来看，就像咱们本文介绍的 select()、poll() 这样的零碎调用，同步和异步更适宜站在应用程序的角度来看。应用程序在同步执行代码片段的时候后果不会立刻返回，这时候底层 IO 操作不肯定是阻塞的，也齐全有可能是非阻塞。所以说：
- 阻塞和非阻塞：读写没有就绪或者读写没有实现，函数是否要始终期待还是采纳轮询；
- 同步和异步：同步是读写由应用程序实现。异步是读写由操作系统来实现，并通过回调的机制告诉应用程序。
这边顺便提两种大家可能会常常听到的模式：Reactor 和 Preactor。
- Reactor 模式：被动模式。
- Preactor 模式：被动模式。
五、总结
本篇文章从底层解说了下从 BIO 到 NIO 的一个过程，着重介绍了 IO 多路复用的几个零碎调用 select()、poll()、epoll()，剖析了下各自的优劣，技术都是继续倒退演进的，目前也有很多的痛点。后续会持续给大家介绍下与此相关的“零拷贝”技术，以及 Java NIO 和 Netty 框架。
vivo 官网商城开发团队