I/O复用模型
多路复用是指使用一个线程来检查多个文件描述符（Socket）的就绪状态，比如调用select和poll函数，传入多个文件描述符（FileDescription，简称FD），如果有一个文件描述符（FileDescription）就绪，则返回，否则阻塞直到超时。得到就绪状态后进行真正的操作可以在同一个线程里执行，也可以启动线程执行（比如使用线程池）。

目前支持IO多路复用的系统调用有select，pselect，poll，epoll。IO多路复用是一种机制，一个进程监控多个描述符，一旦某个描述符准备就绪（一般是读就绪或者写就绪），通知应用进行相应的IO操作（读写）。但是select、pselect、poll、epoll本质上都是同步IO，它们都是要在读写事件就绪后自己负责读写，也就是说这个读写过程是阻塞的。而异步IO是无需自己负责读写，把所有的操作全部给内核来处理。系统内核负责把数据从内核复制到用户空间，在这个过程中，进程全程没有阻塞。

image.png

image.png

与多进程和线程的技术相比，I/O多路复用技术最大的优势就是系统开销小，系统不必创建进程/线程,也不必维护这些进程/线程，从而大大减小了系统的开销。

一、使用场景

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

• 当客户处理多个IO描述符时（一般是交互式输入和网络套接口），必须使用IO复用。
• 当一个客户同时处理多个套接口时，这种情况是可能的，但很少出现。
• 如果一个TCP既要处理监听套接字，又要处理已连接的套接字，一般也要用到I/O复用。
• 一个服务器既要处理TCP，又要处理UDP，一般也要使用I/O复用。
• 如果一个服务器要处理多个服务或者多个协议，一般也要使用I/O复用。

二、select、poll、epoll简介

epoll跟select都能提供多路IO复用的解决方案。在现在的Linux内核里有都能够支持，其中epoll是Linux特有的，而select是POSIX所规定，一般操作系统均有实现。

1. select

基本原理：select函数监视的文件描述符分为3类，分别为write_fds、read_fds、except_fds。调用select函数后，进程会阻塞，直到描述符就绪（有数据 可读、可写、或者有except），或者超时(timeout指定等待时间，如果立即返回设为null即可)，函数返回。当select函数返回后，可以通过遍历fd_set，来找到就绪的描述符。

• 基本流程 ，如图所示
  
  image.png
  
  select基本上在所有的平台上都支持，其良好跨平台支持也是它的一个优点。select的一个缺点就是单个进程能够监视的文件描述符的数量存在最大的限制，Linux上一般都是1024，可以修改宏定义来提升这一限制(内核需要重新的编译)。
  select的本质是通过设置或者检查存放fd标志位的数据结构来进一步的处理。下面是select的缺点。
• select的最大缺点是单个文件打开的FD有限制，由FD_SETSIZE设置，一般是1024。
• 对socket进行扫描时是线性扫描，即采用轮询的方法，效率低。
• 每次调用 select()，都需要把 fd 集合从用户态拷贝到内核态，这个开销在 fd 很多时会很大，同时每次调用 select() 都需要在内核遍历传递进来的所有 fd，这个开销在 fd 很多时也很大。

2. poll

select() 和 poll() 系统调用的本质一样，poll() 的机制与 select() 类似，与 select() 在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是 poll() 没有最大文件描述符数量的限制（但是数量过大后性能也是会下降）。poll() 和 select() 同样存在一个缺点就是，包含大量文件描述符的数组被整体复制于用户态和内核的地址空间之间，而不论这些文件描述符是否就绪，它的开销随着文件描述符数量的增加而线性增大。

注意：select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的文件描述符。如果只有很少的文件描述符处于就绪状态，那么随着监视的描述符数量的增长，其效率也会线性下降。

3.epoll

epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

epoll的优点：

• 没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。
• 效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。

只有活跃可用的FD才会调用callback函数；即epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，epoll的效率就会远远高于select和poll。

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

epoll的操作模式

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

• LT模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序可以不立即处理该事件。下次调用epoll_wait时，会再次响应应用程序并通知此事件。
  LT(level triggered)是缺省的工作方式，并且同时支持block和no-block socket。在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的。
• ET模式：当epoll_wait检测到描述符事件发生并将此事件通知应用程序，应用程序必须立即处理该事件。如果不处理，下次调用epoll_wait时，不会再次响应应用程序并通知此事件。
  ET(edge-triggered)是高速工作方式，只支持no-block socket。在这种模式下，当描述符从未就绪变为就绪时，内核通过epoll告诉你。然后它会假设你知道文件描述符已经就绪，并且不会再为那个文件描述符发送更多的就绪通知，直到你做了某些操作导致那个文件描述符不再为就绪状态了(比如，你在发送，接收或者接收请求，或者发送接收的数据少于一定量时导致了一个EWOULDBLOCK 错误）。但是请注意，如果一直不对这个fd作IO操作(从而导致它再次变成未就绪)，内核不会发送更多的通知(only once)。
  ET模式在很大程度上减少了epoll事件被重复触发的次数，因此效率要比LT模式高。epoll工作在ET模式的时候，必须使用非阻塞套接口，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

4.select、poll、epoll

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

三、select、poll、epoll区别

• 支持一个进程所能打开的最大连接数

  
  
  image.png

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

  
  
  image.png

• 消息传递方式

  
  
  image.png
  
  

  综上，在选择select，poll，epoll时要根据具体的使用场合以及这三种方式的自身特点：
  1、表面上看epoll的性能最好，但是在连接数少并且连接都十分活跃的情况下，select和poll的性能可能比epoll好，毕竟epoll的通知机制需要很多函数回调。
  2、select低效是因为每次它都需要轮询。但低效也是相对的，视情况而定，也可通过良好的设计改善。

四、面试可回答区别

select

• select能监控的描述符个数由内核中的FD_SETSIZE限制，仅为1024，这也是select最大的缺点，因为现在的服务器并发量远远不止1024。即使能重新编译内核改变FD_SETSIZE的值，但这并不能提高select的性能。
• 每次调用select都会线性扫描所有描述符的状态，在select结束后，用户也要线性扫描fd_set数组才知道哪些描述符准备就绪，等于说每次调用复杂度都是O（n）的，在并发量大的情况下，每次扫描都是相当耗时的，很有可能有未处理的连接等待超时。
• 每次调用select都要在用户空间和内核空间里进行内存复制fd描述符等信息。

poll

• poll使用pollfd结构来存储fd，突破了select中描述符数目的限制。
• 与select的后两点类似，poll仍然需要将pollfd数组拷贝到内核空间，之后依次扫描fd的状态，整体复杂度依然是O（n）的，在并发量大的情况下服务器性能会快速下降。

epoll

• epoll维护的描述符数目不受到限制，而且性能不会随着描述符数目的增加而下降。
• 服务器的特点是经常维护着大量连接，但其中某一时刻读写的操作符数量却不多。epoll先通过epoll_ctl注册一个描述符到内核中，并一直维护着而不像poll每次操作都将所有要监控的描述符传递给内核；在描述符读写就绪时，通过回掉函数将自己加入就绪队列中，之后epoll_wait返回该就绪队列。也就是说，epoll基本不做无用的操作，时间复杂度仅与活跃的客户端数有关，而不会随着描述符数目的增加而下降。
• epoll在传递内核与用户空间的消息时使用了内存共享，而不是内存拷贝，这也使得epoll的效率比poll和select更高。

参考自

https://www.cnblogs.com/jeakeven/p/5435916.html
https://www.nowcoder.com/questionTerminal/c162e1e930a34ea3ad6c8863ccff0fa2
https://blog.csdn.net/y396397735/article/details/55004775
https://www.cnblogs.com/ccsccs/articles/4224253.html (重点分析select)
https://blog.csdn.net/apacat/article/details/51375950 (这个也比较详细)
https://blog.csdn.net/yusiguyuan/article/details/15027821
https://blog.csdn.net/mmz_xiaokong/article/details/8704988
https://www.cnblogs.com/Anker/p/3265058.html (区别整理)
https://blog.csdn.net/men_wen/article/details/53456491 (最好的例子)
https://www.cnblogs.com/zhuwbox/p/4221934.html
https://blog.csdn.net/tennysonsky/article/details/45745887/ (配合了代码的分析)