IO多路复用

Posted 2021-07-17 四季帆

1. 前言

相比于我们通过I/O接口主动问内核这些文件描述符对应的外设是不是已经就绪了，一种更好的方法是，我们把这些感兴趣的文件描述符一股脑扔给内核，并霸气的告诉内核：“我这里有1万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。这是一种更加高效的I/O处理机制，现在我们可以一次处理多路I/O了，即I/O多路复用( I/O multiplexing)。

 

2. 过程

1. 我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)
2. 通过调用某个函数告诉内核：“这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行I/O读写操作的时候你再返回”
3. 当调用的这个函数返回后我们就能知道哪些文件描述符可以进行I/O操作了。也就是说通过I/O多路复用我们可以同时处理多路I/O。

3. 接口

3.1 select

特点：

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

3.2 poll

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

 

3.3 epoll

epoll通过引入epoll_ctl做到了只操作那些有变化的文件描述符，同时epoll和内核共享了同一块内存，这块内存中保存的就是那些已经可读或者可写的的文件描述符集合，这样就减少了内核和程序的拷贝开销。

 

4. 接口对比

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

在epoll机制下，进程不需要亲自下场了，进程只要等待在epoll上，epoll代替进程去各个文件描述符上等待，当哪个文件描述符可读或者可写的时候就告诉epoll，epoll记录下来然后唤醒进程，这样进程被唤醒后就无需自己从头到尾检查一遍。