select和epoll的优缺点

select和epoll的优缺点

select，epoll都是IO多路复用的机制。I/O多路复用就通过一种机制，可以监视多个描述符，一旦某个描述符就绪（一般是读就绪或者写就绪），能够通知程序进行相应的读写操作。但select，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后自己负责进行读写，也就是说这个读写过程是阻塞的，而异步I/O则无需自己负责进行读写，异步I/O的实现会负责把数据从内核拷贝到用户空间。

select

文件描述符的数量

单个进程能够监视的文件描述符的数量存在最大限制，通常是1024，当然可以更改数量；(在linux内核头文件中定义：#define __FD_SETSIZE 1024)

就绪fd采用轮询的方式扫描

select返回的是int，可以理解为返回的是ready(准备好的)一个或者多个文件描述符，应用程序需要遍历整个文件描述符数组才能发现哪些fd句柄发生了事件，由于select采用轮询的方式扫描文件描述符（不知道那个文件描述符读写数据，所以需要把所有的fd都遍历），文件描述符数量越多，性能越差

内核 /用户空间内存拷贝

select每次都会改变内核中的句柄数据结构集(fd集合)，因而每次调用select都需要从用户空间向内核空间复制所有的句柄数据结构(fd集合)，产生巨大的开销

select的触发方式

select的触发方式是水平触发，应用程序如果没有完成对一个已经就绪的文件描述符进行IO操作，那么之后每次调用select还是会将这些文件描述符通知进程

epoll

先看一下epoll和select调用接口上的不同，select只提供了一个函数——select函数。而epoll提供了三个函数，epoll_create,epoll_ctl和epoll_wait。

1. epoll_create是创建一个epoll句柄；
2. epoll_ctl是注册要监听的事件类型；
3. epoll_wait则是等待事件的产生。

文件描述符的数量

epoll没有这个限制，它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于1024,举个例子,在2GB内存的机器上是20万左右（具体数目可以cat /proc/sys/fs/file-max查看）

就绪fd 采用事件方式回调

epoll在内核中会维护一个红黑树和一个双向链表，红黑树存放通过epoll_ctl方法向epoll对象中添加进来的事件，所以不需要每次调用epoll_wait都全量复制所有的事件结构。双向链表存放就绪的事件，所有添加到epoll中的事件都会与设备(网卡)驱动程序建立回调关系，也就是说，当相应的事件发生时会调用这个回调方法，这个回调方法在内核中叫ep_poll_callback,它会将发生的事件添加到rdlist双链表中。调用epoll_wait就会直接返回链表中的就绪事件，效率高

内核 /用户空间内存拷贝

epoll的解决方案在epoll_ctl函数中。每次注册新的事件到epoll句柄中时（在epoll_ctl中指定EPOLL_CTL_ADD），会把所有的fd拷贝进内核，而不是在epoll_wait的时候重复拷贝。epoll保证了每个fd在整个过程中只会拷贝一次

epoll的触发方式

水平触发LT和边缘触发ET

水平触发LT

其中LT就是与select和poll类似，当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据一次性全部读写完(如读写缓冲区太小)，那么下次调用 epoll_wait()时，它还会通知你在上次没读写完的文件描述符上继续读写

边缘触发ET

当被监控的文件描述符上有可读写事件发生时，epoll_wait()会通知处理程序去读写。如果这次没有把数据全部读写完(如读写缓冲区太小)，那么下次调用epoll_wait()时，它不会通知你，也就是它只会通知你一次，直到该文件描述符上出现第二次可读写事件才会通知你

总结

未验证总结：并发小于1万select，并发大于百万epoll

参考：
https://blog.csdn.net/davidsguo008/article/details/73556811
https://www.bilibili.com/video/BV1jJ411j7ot?from=search&seid=5931515930271108680
https://github.com/0voice/interview_internal_reference/blob/master/01.%E9%98%BF%E9%87%8C%E7%AF%87/1.1.5%20%E5%85%B3%E4%BA%8Eepoll%E5%92%8Cselect%E7%9A%84%E5%8C%BA%E5%88%AB%EF%BC%8C%E4%BB%A5%E4%B8%8B%E5%93%AA%E4%BA%9B%E8%AF%B4%E6%B3%95%E6%98%AF%E6%AD%A3%E7%A1%AE%E7%9A%84.md
https://blog.csdn.net/shangsongwww/article/details/102619771