聊聊IO多路复用之select、poll、epoll详解

IO多路复⽤是指内核⼀旦发现进程指定的⼀个或者多个IO条件准备读取，它就通知该进程。IO多路复⽤适⽤如下场合：

1. 当客户处理多个描述符时（⼀般是交互式输⼊和⽹络套接⼝），必须使⽤I/O复⽤。

2. 当⼀个客户同时处理多个套接⼝时，⽽这种情况是可能的，但很少出现。

3. 如果⼀个TCP服务器既要处理监听套接⼝，⼜要处理已连接套接⼝，⼀般也要⽤到I/O复⽤。

4. 如果⼀个服务器即要处理TCP，⼜要处理UDP，⼀般要使⽤I/O复⽤。

5. 如果⼀个服务器要处理多个服务或多个协议，⼀般要使⽤I/O复⽤。

与多进程和多线程技术相⽐，I/O多路复⽤技术的最⼤优势是系统开销⼩，系统不必创建进程/线程，也不必维护这些进程/线程，从⽽⼤⼤减⼩了系统的开销。

⽬前⽀持I/O多路复⽤的系统调⽤有 select，pselect，poll，epoll，I/O多路复⽤就是通过⼀种机制，⼀个进程可以监视多个描述符，⼀旦某个描述符就绪（⼀般是读就绪或者写就绪），能够通知程序进⾏相应的读写操作。但select，pselect，poll，epoll本质上都是同步I/O，因为他们都需要在读写事件就绪后⾃⼰负责进⾏读写，也就是说这个读写过程是阻塞的，⽽异步I/O则⽆需⾃⼰负责进⾏读写，异步I/O的实现会负责把数据从内核拷贝到⽤户空间。

对于IO多路复⽤机制不理解的同学，可以先⾏参考《》，来了解Linux五种IO模型。

1 select、poll、epoll简介

epoll跟select都能提供多路I/O复⽤的解决⽅案。在现在的Linux内核⾥有都能够⽀持，其中epoll是Linux所特有，⽽select则应该是POSIX所规定，⼀般操作系统均有实现。

1.1 select

基本原理：

select 函数监视的⽂件描述符分3类，分别是writefds、readfds、和exceptfds。调⽤后select函数会阻塞，直到有描述符就绪（有数据 可读、可写、或者有except），或者超时（timeout指定等待时间，如果⽴即返回设为null即可），函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。

基本流程，如图所⽰：

select⽬前⼏乎在所有的平台上⽀持，其良好跨平台⽀持也是它的⼀个优点。select的⼀个缺点在于单个进程能够监视的⽂件描述符的数量存在最⼤，在Linux上⼀般为1024，可以通过修改宏定义甚⾄重新编译内核的⽅式提升这⼀，但是这样也会造成效率的降低。

select本质上是通过设置或者检查存放fd标志位的数据结构来进⾏下⼀步处理。这样所带来的缺点是：

1. select最⼤的缺陷就是单个进程所打开的FD是有⼀定的，它由FD_SETSIZE设置，默认值是1024。

⼀般来说这个数⽬和系统内存关系很⼤，具体数⽬可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。位机默认是2048.

2. 对socket进⾏扫描时是线性扫描，即采⽤轮询的⽅法，效率较低。

当套接字⽐较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历⼀遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，⾃动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。

3. 需要维护⼀个⽤来存放⼤量fd的数据结构，这样会使得⽤户空间和内核空间在传递该结构时复制开销⼤.

1.2 poll

基本原理：

poll本质上和select没有区别，它将⽤户传⼊的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加⼊⼀项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它⼜要再次遍历fd。这个过程经历了多次⽆谓的遍历。

它没有最⼤连接数的，原因是它是基于链表来存储的，但是同样有⼀个缺点：

1. ⼤量的fd的数组被整体复制于⽤户态和内核地址空间之间，⽽不管这样的复制是不是有意义。

2. poll还有⼀个特点是“⽔平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。 注意：

从上⾯看，select和poll都需要在返回后，通过遍历⽂件描述符来获取已经就绪的socket。事实上，同时连接的⼤量客户端在⼀时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

1.3 epoll

epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符。epoll使⽤⼀个

⽂件描述符管理多个描述符，将⽤户关系的⽂件描述符的事件存放到内核的⼀个事件表中，这样在⽤户空间和内核空间的copy只需⼀次。

基本原理：

epoll⽀持⽔平触发和边缘触发，最⼤的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知⼀次。还有⼀个特点是，epoll使⽤“事件”的就绪通知⽅式，通过epoll_ctl注册fd，⼀旦该fd就绪，内核就会采⽤类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

epoll的优点：

1. 没有最⼤并发连接的，能打开的FD的上限远⼤于1024（1G的内存上能监听约10万个端⼝）。

2. 效率提升，不是轮询的⽅式，不会随着FD数⽬的增加效率下降。只有活跃可⽤的FD才会调⽤callback函数；即Epoll最⼤的优点就在于它只管你“活跃”的连接，⽽跟连接总数⽆关，因此在实际的⽹络环境中，Epoll的效率就会远远⾼于select和poll。

3. 内存拷贝，利⽤mmap()⽂件映射内存加速与内核空间的消息传递；即epoll使⽤mmap减少复制开销。

epoll对⽂件描述符的操作有两种模式：LT（level trigger）和ET（edge trigger）。LT模式是默认模式，LT模式与ET模式的区别如下：

LT模式：当epoll_wait检测到描述符事件发⽣并将此事件通知应⽤程序，应⽤程序可以不⽴即处理该事件。下次调⽤epoll_wait时，会再次响应应⽤程序并通知此事件。

ET模式：当epoll_wait检测到描述符事件发⽣并将此事件通知应⽤程序，应⽤程序必须⽴即处理该事件。如果不处理，下次调⽤epoll_wait时，不会再次响应应⽤程序并通知此事件。

1. LT模式

LT(level triggered)是缺省的⼯作⽅式，并且同时⽀持block和no-block socket。在这种做法中，内核告诉你⼀个⽂件描述符是否就绪了，然后你可以对这个就绪的fd进⾏IO操作。如果你不作任何操作，内核还是会继续通知你的。 2. ET模式

ET(edge-triggered)是⾼速⼯作⽅式，只⽀持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道⽂件描述符已经就绪，并且不会再为那个⽂件描述符发送更多的就绪通知，直到你做了某些操作导致那个⽂件描述符不再为就绪状态了(⽐如，你在发送，接收或者接收请求，或者发送接收的数据少于⼀定量时导致了⼀个EWOULDBLOCK 错

误）。但是请注意，如果⼀直不对这个fd作IO操作(从⽽导致它再次变成未就绪)，内核不会发送更多的通知(only once)。ET模式在很⼤程度上减少了epoll事件被重复触发的次数，因此效率要⽐LT模式⾼。epoll⼯作在ET模式的时候，必须使⽤⾮阻塞套接⼝，以避免由于⼀个⽂件句柄的阻塞读/阻塞写操作把处理多个⽂件描述符的任务饿死。

3. 在select/poll中，进程只有在调⽤⼀定的⽅法后，内核才对所有监视的⽂件描述符进⾏扫描，⽽epoll事先通过epoll_ctl()来注册⼀个⽂件描述符，⼀旦基于某个⽂件描述符就绪时，内核会采⽤类似callback的回调机制，迅速激活这个⽂件描述符，当进程调⽤epoll_wait()时便得到通知。(此处去掉了遍历⽂件描述符，⽽是通过监听回调的的机制。这正是epoll的魅⼒所在。) 注意：

如果没有⼤量的idle-connection或者dead-connection，epoll的效率并不会⽐select/poll⾼很多，但是当遇到⼤量的idle-connection，就会发现epoll的效率⼤⼤⾼于select/poll。

2 select、poll、epoll区别

1. ⽀持⼀个进程所能打开的最⼤连接数

2. FD剧增后带来的IO效率问题

3. 消息传递⽅式

综上，在选择select，poll，epoll时要根据具体的使⽤场合以及这三种⽅式的⾃⾝特点：

1. 表⾯上看epoll的性能最好，但是在连接数少并且连接都⼗分活跃的情况下，select和poll的性能可能⽐epoll好，毕竟epoll的通知机制需要很多函数回调。

2. select低效是因为每次它都需要轮询。但低效也是相对的，视情况⽽定，也可通过良好的设计改善。