终于明白了，一文彻底理解I/O多路复用

蔚落 2023-01-16 04:54 109阅读 0赞

在讲解该技术之前，我们需要预习一下文件以及文件描述符。

**什么是文件**

程序员使用I/O最终都逃不过文件这个概念。

在Linux世界中文件是一个很简单的概念，作为程序员我们只需要将其理解为一个N byte的**序列**就可以了：

***b1, b2, b3, b4, ....... bN***

实际上所有的I/O设备都被抽象为了文件这个概念，一切皆文件，Everything is File，磁盘、网络数据、终端，甚至进程间通信工具管道pipe等都被当做文件对待。

![36f306dddc4a77fa7bd855e5ce8cae94.png][]

所有的I/O操作也都可以通过文件读写来实现，**这一非常优雅的抽象可以让程序员使用一套接口就能对所有外设I/O操作**。

常用的I/O操作接口一般有以下几类：

*  打开文件，open
 *  改变读写位置，seek
 *  文件读写，read、write
 *  关闭文件，close

程序员通过这几个接口几乎可以实现所有I/O操作，这就是文件这个概念的强大之处。

**文件描述符**

在上一篇《[读取文件时，程序经历了什么][Link 1]》中我们讲到，要想进行I/O读操作，像磁盘数据，我们需要指定一个buff用来装入数据，一般都是这样写的：

read(buff);

但是这里我们忽略了一个关键问题，那就是虽然我们指定了往哪里写数据，但是我们该从哪里读数据呢？

从上一节中我们知道，通过文件这个概念我们能实现几乎所有I/O操作，**因此这里少的一个主角就是文件**。

那么我们一般都怎样使用文件呢？

如果周末你去比较火的餐厅吃饭应该会有体会，一般周末人气高的餐厅都会排队，然后服务员会给你一个排队序号，通过这个序号服务员就能找到你，这里的好处就是服务员无需记住你是谁、你的名字是什么、来自哪里、喜好是什么、是不是保护环境爱护小动物等等，这里的关键点就是**服务员对你一无所知，但依然可以通过一个号码就能找到你**。

同样的，在Linux世界要想使用文件，我们也需要借助一个号码，根据“[弄不懂原则][Link 2]”，这个号码就被称为了文件描述符，**file descriptors**，在Linux世界中鼎鼎大名，其道理和上面那个排队号码一样。

因此，文件描述仅仅就是一个数字而已，但是通过这个数字我们可以操作一个打开的文件，这一点要记住。

![15432faad2012390a7e6894164d1a02c.png][]

**有了文件描述符，进程可以对文件一无所知**，比如文件在磁盘的什么位置、加载到内存中又是怎样管理的等等，这些信息统统交由操作系统打理，进程无需关心，操作系统只需要给进程一个文件描述符就足够了。

因此我们来完善上述程序：

int fd = open(file_name); // 获取文件描述符
    read(fd, buff);

怎么样，是不是非常简单。

**文件描述符太多了怎么办**

经过了这么多的铺垫，终于要到高性能、高并发这一主题了。

从前几节我们知道，所有I/O操作都可以通过文件样的概念来进行，这当然包括网络通信。

如果你有一个web服务器，当三次握手成功以后，我们会调用accept来获取一个链接，调用该函数我们同样会得到一个文件描述符，通过这个文件描述符就可以处理客户端发送的请求并且把处理结果发送回去。也就是说通过这个描述符我们就可以和客户端进行通信了。

// 通过accept获取客户端的文件描述符
    int conn_fd = accept(...);

server的处理逻辑通常是读取客户端请求数据，然后执行某些特定逻辑：

if(read(conn_fd, request_buff) > 0) {
        do_something(request_buff);
    }

是不是非常简单，然而世界终归是复杂的，当然也不是这么简单的。

接下来就是比较复杂的了。

![b01e5e4beef35b39379af5b6a72406b6.gif][]

既然我们的主题是高并发，那么**server就不可能只和一个客户端通信**，而是可能会同时和成千上万个客户端进行通信。**这时你需要处理不再是一个描述符这么简单，而是有可能要处理成千上万个描述符**。

为了不让问题一上来就过于复杂，我们先简单化，假设只同时处理两个客户端的请求。

有的同学可能会说，这还不简单，这样写不就行了：

if(read(socket_fd1, buff) > 0) { // 处理第一个
        do_something();
    }
    if(read(socket_fd2, buff) > 0) { // 处理第二个
        do_something();

在上一篇《[读取文件时，程序都经历了什么][Link 1]》中我们讨论过这是非常典型的阻塞式I/O，如果此时没有数据可读那么进程会被阻塞而暂停运行，这时我们就无法处理第二个请求了，即使第二个请求的数据已经就位，这也就意味着处理某一个客户端时由于进程被阻塞导致剩下的所有其它客户端必须**等待**，在同时处理几万客户端的server上，这显然是不能容忍的。

聪明的你一定会想到使用多线程，为每个客户端请求开启一个线程，这样一个客户端被阻塞就不会影响到处理其它客户端的线程了，注意，既然是高并发，那么我们要为成千上万个请求开启成千上万个线程吗，大量创建销毁线程会严重影响系统性能。

那么这个问题该怎么解决呢？

**这里的关键点在于，我们事先并不知道一个文件描述对应的I/O设备是否是可读的、是否是可写的**，在外设的不可读或不可写的状态下进行I/O只会导致进程阻塞被暂停运行。

因此要优雅的解决这个问题，就要从其它角度来思考这个问题了。

![3d6b0716078e59ff5944ce9a52337ea2.gif][]

**不要打电话给我，有需要我会打给你**

大家生活中肯定会接到过推销电话，而且不止一个，一天下来接上十个八个推销电话你的身体会被掏空的。

这个场景的关键点在于打电话的人并不知道你是不是要买东西，只能来一遍遍问你，因此一种更好的策略是不要让他们打电话给你，记下他们的电话，有需要的话打给他们，这样推销员就不会一遍一遍的来烦你了(虽然现实生活中这并不可能)。

在这个例子中，你，就好比内核，推销者就好比应用程序，电话号码就好比文件描述符，和你用电话沟通就好比I/O。

现在你应该明白了吧，处理多个文件描述符的更好方法其实就存在于推销电话中。

因此相比上一节中我们通过I/O接口**主动**问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些感兴趣的文件描述符一股脑扔给内核，并霸气的告诉内核：“**我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理**”。而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了吗？。。。”

这样应用程序就**从“繁忙”的主动变为了清闲的被动**，**反正文件描述可读可写了内核会通知我**，能偷懒我才不要那么勤奋。

![4093a676180e32e81b35581f67a09f7e.gif][]

这是一种更加高效的I/O处理机制，**现在我们可以一次处理多路I/O了**，为这种机制起一个名字吧，再次祭出“[弄不懂原则][Link 2]”，就叫I/O多路复用吧，这就是 I/O multiplexing。

**I/O多路复用，I/O multiplexing**

multiplexing一词其实多用于通信领域，为了充分利用通信线路，希望在一个信道中传输多路信号，要想在一个信道中传输多路信号就需要把这多路信号结合为一路，将多路信号组合成一个信号的设备被称为multiplexer，显然接收方接收到这一路组合后的信号后要恢复原先的多路信号，这个设备被称为demultiplexer，如图所示：

![597d1f04cfc20698573545656448fa48.png][]

回到我们的主题。

所谓I/O多路复用指的是这样一个过程：

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)

2. 通过调用**某个函数**告诉内核：“**这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回**”

3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。

也就是说**通过I/O多路复用我们可以同时处理多路I/O**。那么有哪些函数可以用来进行I/O多路复用呢？

在Linux世界中有这样三种机制可以用来进行I/O多路复用：

*  select
 *  poll
 *  epoll

接下来我们就来介绍一下牛掰的I/O多路复用三剑客。

![5024a2376583f52d58fdfc5b6f5d884b.gif][]

**I/O多路复用三剑客**

本质上select、poll、epoll都是阻塞式I/O，也就是我们常说的同步I/O，原因在于调用这些I/O多路复用函数时如果任何一个需要监视的文件描述符都不可读或者可写那么进程会被阻塞暂停执行，直到有文件描述符可读或者可写才继续运行。

**1，select：初出茅庐**

在select这种I/O多路复用机制下，我们需要把想监控的文件描述集合通过函数参数的形式告诉select，然后select会将这些文件描述符集合**拷贝**到内核中，我们知道数据拷贝是有性能损耗的，因此为了减少这种数据拷贝带来的性能损耗，Linux内核对集合的大小做了限制，并规定用户监控的文件描述集合不能超过1024个，同时当select返回后**我们仅仅能知道有些文件描述符可以读写了，但是我们不知道是哪一个**，因此程序员必须再遍历一边找到具体是哪个文件描述符可以读写了。

因此，总结下来select有这样几个特点：

*  我能照看的文件描述符数量有限，不能超过1024个
 *  用户给我的文件描述符需要拷贝的内核中
 *  我只能告诉你有文件描述符满足要求了，但是我不知道是哪个，你自己一个一个去找吧(遍历)

因此我们可以看到，select机制的这些特性在高并发网络服务器动辄几万几十万并发链接的场景下无疑是低效的。

![a8658f6e8a7489548cb47015ced61b54.gif][]

**2，poll：小有所成**

poll和select是非常相似的，poll相对于select的优化仅仅在于解决了文件描述符不能超过1024个的限制，select和poll都会随着监控的文件描述数量增加而性能下降，因此不适合高并发场景。

**3，epoll：独步天下**

在select面临的三个问题中，文件描述数量限制已经在poll中解决了，剩下的两个问题呢？

针对拷贝问题，epoll使用的策略是**各个击破**与**共享内存**。

实际上文件描述符集合的变化频率比较低，select和poll频繁的拷贝整个集合，内核都快被烦死了，epoll通过引入epoll\_ctl很体贴的做到了只操作那些有变化的文件描述符，同时epoll和内核还成为了好朋友，共享了同一块内存，这块内存中保存的就是那些已经可读或者可写的的文件描述符集合，这样就减少了内核和程序的拷贝开销。

针对需要遍历文件描述符才能知道哪个可读可写这一问题，epoll使用的策略是“当小弟”。

在select和poll机制下，**进程要亲自下场去各个文件描述符上等待**，任何一个文件描述可读或者可写就唤醒进程，但是进程被唤醒后也是一脸懵逼并不知道到底是哪个文件描述符可读或可写，还要再从头到尾检查一遍。

但epoll就懂事多了，主动找到进程要当小弟替大哥出头。

![76a2d3629fbd9eee1fc6cd99d12d5ae7.gif][]

在这种机制下，进程不需要亲自下场了，进程只要等待在epoll上，epoll代替进程去各个文件描述符上等待，当哪个文件描述符可读或者可写的时候就告诉epoll，epoll用小本本认真记录下来然后唤醒大哥：“进程大哥，快醒醒，你要处理的文件描述符我都记下来了”，这样进程被唤醒后就无需自己从头到尾检查一遍，因为epoll小弟都已经记下来了。

因此我们可以看到，在epoll这种机制下，实际上利用的就是“不要打电话给我，有需要我会打给你”这种策略，进程不需要一遍一遍麻烦的问各个文件描述符，而是翻身做主人了，“你们这些文件描述符有哪个可读或者可写了主动报上来”，这种机制实际上就是大名鼎鼎的事件驱动，Event-driven，这也是我们下一篇的主题。

实际上在Linux平台，**epoll基本上就是高并发的代名词**。

**总结**

基于一切皆文件的设计哲学，I/O也可以通过文件的形式实现，高并发场景下要与多个文件交互，这就离不开高效的I/O多路复用技术，本文我们详细讲解了什么是I/O多路复用以及使用方法，这其中以epoll为代表的I/O多路复用(基于事件驱动)技术使用非常广泛，实际上你会发现但凡涉及到高并发、高性能的场景基本上都能见到事件驱动的编程方法，当然这也是下一篇我们要重点讲解的主题，敬请期待。

·················· END ··················

关注后回复「1024」，获取海量学习资源

![9d88c879fe1c00d7bbb064b1385a516b.gif][]

[36f306dddc4a77fa7bd855e5ce8cae94.png]: /images/20221022/b803b9e02e4949f4a6eabac3877a4d39.png
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ%3D%3D&chksm=fcb9822acbce0b3cba63913ff6de1e37c133b878f02035bc816f7f2ec8423d908bd8560d3605&idx=1&mid=2247484788&scene=21&sn=e2a084694bedf9b148bbcd5570747add#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzU2NTYyOTQ4OQ%3D%3D&chksm=fcb9823ecbce0b28ca28d021e68c78138cde4a1b86ea7209c0c667d3d544d223d8b2aecbccec&idx=1&mid=2247484768&scene=21&sn=049db350af9e5eea5cf3523ceb83f447#wechat_redirect
[15432faad2012390a7e6894164d1a02c.png]: /images/20221022/f98dfcc152e344f1a7d643392d6d37c1.png
[b01e5e4beef35b39379af5b6a72406b6.gif]: /images/20221022/b51f45e525724289bbf6437691c5c15c.png
[3d6b0716078e59ff5944ce9a52337ea2.gif]: /images/20221022/2952019bd9e942aa86082eaa5f82a37d.png
[4093a676180e32e81b35581f67a09f7e.gif]: /images/20221022/b740b8f912a04070bbc05c7f47211c68.png
[597d1f04cfc20698573545656448fa48.png]: /images/20221022/7d2fdcc5ea3f410d8eb0c1c7e04cf77c.png
[5024a2376583f52d58fdfc5b6f5d884b.gif]: /images/20221022/4d46bbb0d6ed4d1da3ab9df9d1eba63f.png
[a8658f6e8a7489548cb47015ced61b54.gif]: /images/20221022/732b2a45b8244d4ca5c46b56afcf6f5f.png
[76a2d3629fbd9eee1fc6cd99d12d5ae7.gif]: /images/20221022/7de9aa8de8d04634b44f1a6216e18b17.png
[9d88c879fe1c00d7bbb064b1385a516b.gif]: /images/20221022/28c31e11ecac4ece8812683701391015.png