面试老大难——select、poll、epoll

1、select、poll和epoll三者应用的场景

• 在《Netty权威指南》中提到网络编程对I/O模型进行分类，分为5大类：阻塞I/O模型、非阻塞I/O模型、I/O复用模型、信号驱动模型和异步I/O。其中在I/O复用模型中使用到了上述的三种接口，Linux提供的select/poll，进程通过将一个或者多个fd传递给select/poll进行系统调用，阻塞在select上，通过侦测多个fd是否处于就绪状态。比如我们常用的Nosql数据库redis就使用这中网络通信模式。
• select/poll通过顺序扫描的方式来判断fd是否就绪，支持的fd数量有限，当fd数量过大时效率明显下降。而epoll是居于事件驱动的，只有相应的事件发生才会调用处理器对数据进行处理。

• 	select/poll	epoll
  支持的fd数量	支持单个进程打开的fd数量是有限的，默认实1024	epoll支持的打开的fd的上限是操作系统的最大文件句柄数
  I/O效率	当拥有的socket集合很大时，由于这种方式是顺序扫描全部集合，随着集合的增大，效率会线性下降	使用事件驱动，依据每个fd上的回调函数来实现
  消息传递方式	这三种都是需要内核把FD消息通知给用户空间，避免不必要的消息复制就很重要，spoll使用共享内存的方式进行实现

2、底层实现

• epoll是只有在Linux上提供的I.O多路复用接口，由epoll_create、epoll_ctl和epoll_wait组成。使用红黑树的方式来组织interset list。epoll则会注册回调函数，在fd就绪时主动复制到ready list中。
  • epoll_create：函数的签名是int epoll_create(int size),调用这个函数内核会产生一个epoll实例并返回一个文件描述符。size参数表示所要监视的文件描述符的最大值。是用来向interset list中添加、删除和修改的API，而epoll_wait是用来向ready list中添加成员的接口

  • epoll_ctl：对于需要监视的文件描述符集合，epoll API使用interest list进行管理。用来阻塞要监听的事件类型

  • epoll_wait：等待事件的发生。处于ready状态的那些文件描述符会被复制到ready list中，epoll_wait用于向用户进程返回ready list。

  • ET模式（边缘触发）：在两次epoll_wait调用期间，如果监测文件描述符没有状态的上的变化（not ready到ready），即使其处于ready状态也不会被放入到ready list中。向应用程序通知后，应用程序应该立即进行处理，后续的epoll_wait将不再向应用程序通知此事件。

  • LT模式（水平触发）：每次调用epoll_wait的时候，只要被监测的文件描述符发生处于ready状态就会返回。后续再检测到该事件时，仍会向应用程序进行通知，直到该事件被处理。

• select和poll:都使用轮询的方式来fd的标识，但是select是基于数组实现的，而poll的底层实现是基于数组的。poll还有一个特点是水平触发（报告了fd后没有被处理，下次poll时还会再次报告该fd）。

参考:

1. https://blog.csdn.net/mcheaven/article/details/44257771