本文主要是介绍linux下三组IO复用函数的比较，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
| 原理 | |
| select (Fd_set集合) | select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是(只能处理1024个文件描述符) 1 单个进程可监视的fd数量被限制 2 需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大 3 对socket进行扫描时是线性扫描（是FD_ISSET的一个扫描） |
| poll | poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。 它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点： 大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。 poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。 |
| epoll | 在前面说到的复制问题上，epoll使用mmap减少复制开销。 还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知 |
| 一个进程所能打开的最大连接数 | |
| select | 单个进程所能打开的最大连接数有FD_SETSIZE宏定义，其大小是32个整数的大小（在32位的机器上，大小就是32*32(1024个文件描述符)，同理64位机器上FD_SETSIZE为32*64），当然我们可以对进行修改，然后重新编译内核，但是性能可能会受到影响，这需要进一步的测试。 |
| poll | poll本质上和select没有区别，但是它没有最大连接数的限制，原因是它是基于链表来存储的, 1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接 |
| epoll | 没有上限，但是很大，1G内存的机器上可以打开10万左右的连接，2G内存的机器可以打开20万左右的连接 |
| FD剧增后带来的IO效率问题 | |
| select | 因为每次调用时都会对连接进行线性遍历，所以随着FD的增加会造成遍历速度慢的“线性下降性能问题”。 |
| poll | 同上 |
| epoll | 因为epoll内核中实现是根据每个fd上的callback函数来实现的，只有活跃的socket才会主动调用callback，所以在活跃socket较少的情况下，使用epoll没有前面两者的线性下降的性能问题，但是所有socket都很活跃的情况下，可能会有性能问题。 |
| 消息传递方式 | |
| select | 内核需要将消息传递到用户空间，都需要内核拷贝动作 |
| poll | 同上 |
| epoll | epoll通过内核和用户空间共享一块内存来实现的。 |
这篇关于linux下三组IO复用函数的比较的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
