Linux NIO 系列(04-4) select、poll、epoll 对比

Linux NIO 系列(04-4) select、poll、epoll 对比

目录

• 一、API 对比
  • 1.1 select API
  • 1.2 poll API
  • 1.3 epoll API
• 二、总结
  • 2.1 支持一个进程打开的 socket 描述符(FD)不受限制(仅受限于操作系统的最大文件句柄数)
  • 2.2 I/O 效率不会随着 FD 数目的増加而线性下降
  • 2.3 使用 mmap 加速内核与用户空间的消息传递
  • 2.4 epoll API 更加简单
• 附表1： select/poll/epoll 区别

Netty 系列目录(https://www.cnblogs.com/binarylei/p/10117436.html)

既然 select/poll/epoll 都是 I/O 多路复用的具体的实现，之所以现在同时存在，其实他们也是不同历史时期的产物

• select 出现是 1984 年在 BSD 里面实现的
• 14 年之后也就是 1997 年才实现了 poll，其实拖那么久也不是效率问题， 而是那个时代的硬件实在太弱，一台服务器处理1千多个链接简直就是神一样的存在了，select 很长段时间已经满足需求
• 2002, 大神 Davide Libenzi 实现了 epoll

一、API 对比

1.1 select API

int select(int maxfdp, fd_set *readset, fd_set *writeset, fd_set *exceptset,struct timeval *timeout);
int FD_ZERO(int fd, fd_set *fdset);     // 一个 fd_set 类型变量的所有位都设为 0
int FD_CLR(int fd, fd_set *fdset);      // 清除某个位时可以使用
int FD_SET(int fd, fd_set *fd_set);     // 设置变量的某个位置位
int FD_ISSET(int fd, fd_set *fdset);    // 测试某个位是否被置位

select() 的机制中提供一种 fd_set 的数据结构，实际上是一个 long 类型的数组，每一个数组元素都能与一打开的文件句柄建立联系(这种联系需要自己完成)，当调用 select() 时，由内核根据IO 状态修改 fd_set 的内容，由此来通知执行了 select() 的进程哪一 Socket 或文件可读。

select 机制的问题

1. 每次调用 select，都需要把 fd_set 集合从用户态拷贝到内核态，如果 fd_set 集合很大时，那这个开销也很大
2. 同时每次调用 select 都需要在内核遍历传递进来的所有 fd_set，如果 fd_set 集合很大时，那这个开销也很大
3. 为了减少数据拷贝带来的性能损坏，内核对被监控的 fd_set 集合大小做了限制(默认为 1024)

1.2 poll API

int poll(struct pollfd *fds, nfds_t nfds, int timeout);
struct pollfd {
    int fd;         // 文件描述符
    short events;   // 感兴趣的事件
    short revents;  // 实际发生的事件
};

poll 的机制与 select 类似，与 select 在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，但是 poll 没有最大文件描述符数量的限制。也就是说，poll 只解决了上面的问题 3，并没有解决问题 1，2 的性能开销问题。

1.3 epoll API

// 函数创建一个 epoll 句柄，实际上是一棵红黑树
int epoll_create(int size);
// 函数注册要监听的事件类型，op 表示红黑树进行增删改
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
// 函数等待事件的就绪，成功时返回就绪的事件数目，调用失败时返回 -1，等待超时返回 0
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

epoll 在 Linux2.6 内核正式提出，是基于事件驱动的 I/O 方式，相对于 select 来说，epoll 没有描述符个数限制，使用一个文件描述符管理多个描述符，将用户关心的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

二、总结

I/O 多路复用技术在 I/O 编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者 I/O 多路复用技术进行处理。I/O 多路复用技术通过把多个 I/O 的阻塞复用到同一个 select 的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O 多路复用的最大优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源，I/O多路复用的主要应用场景如下：

• 服务器需要同时处理多个处于监听状态或者多个连接状态的套接字
• 服务器需要同时处理多种网络协议的套接字。

目前支持 I/O 多路复用的系统调用有 select、pselect、poll、epoll，在 Linux 网络编程过程中，很长一段时间都使用 select 做轮询和网络事件通知，然而 select 的一些固有缺陷导致了它的应用受到了很大的限制，最终 Linux 不得不在新的内核版本中寻找 select 的替代方案，最终选择了 epoll。epoll 与 select 的原理比较类似，为了克服 select 的缺点， epoll 作了很多重大改进，现总结如下。

2.1 支持一个进程打开的 socket 描述符(FD)不受限制(仅受限于操作系统的最大文件句柄数)

select、poll 和 epoll 底层数据各不相同。select 使用数组；poll 采用链表，解决了 fd 数量的限制；epoll 底层使用的是红黑树，能够有效的提升效率。

select 最大的缺陷就是单个进程所打开的 FD 是有一定限制的，它由 FD_SETSIZE 设置，默认值是 1024。对于那些需要支持上万个 TCP 连接的大型服务器来说显然太少了。可以选择修改这个宏然后重新编译内核，不过这会带来网络效率的下降。我们也可以通过选择多进程的方案(传统的 Apache 方案)解决这个问题，不过虽然在 Linux 上创建进程的代价比较小，但仍旧是不可忽视的。另外，进程间的数据交换非常麻烦，对于 Java 来说，由于没有共享内存，需要通过 Socket 通信或者其他方式进行数据同步，这带来了额外的性能损耗，増加了程序复杂度，所以也不是一种完美的解决方案。值得庆幸的是， epoll 并没有这个限制，它所支持的 FD 上限是操作系统的最大文件句柄数，这个数字远远大于 1024。例如，在 1GB 内存的机器上大约是 10 万个句柄左右，具体的值可以通过 cat proc/sys/fs/file-max 查看，通常情况下这个值跟系统的内存关系比较大。

# (所有进程)当前计算机所能打开的最大文件个数。受硬件影响，这个值可以改（通过limits.conf）
cat /proc/sys/fs/file-max

# (单个进程)查看一个进程可以打开的socket描述符上限。缺省为1024
ulimit -a 
# 修改为默认的最大文件个数。【注销用户，使其生效】
ulimit -n 2000

# soft软限制 hard硬限制。所谓软限制是可以用命令的方式修改该上限值，但不能大于硬限制
vi /etc/security/limits.conf
* soft nofile 3000      # 设置默认值。可直接使用命令修改
* hard nofile 20000     # 最大上限值

2.2 I/O 效率不会随着 FD 数目的増加而线性下降

传统 select/poll 的另一个致命弱点，就是当你拥有一个很大的 socket 集合时，由于网络延时或者链路空闲，任一时刻只有少部分的 socket 是“活跃”的，但是 select/poll 每次调用都会线性扫描全部的集合，导致效率呈现线性下降。 epoll 不存在这个问题，它只会对“活跃”的 socket 进行操作一一这是因为在内核实现中， epoll 是根据每个 fd 上面的 callback 函数实现的。那么，只有“活跃”的 socket オ会去主动调用 callback 函数，其他 idle 状态的 socket 则不会。在这点上， epoll 实现了一个伪 AIO。针对 epoll 和 select 性能对比的 benchmark 测试表明：如果所有的 socket 都处于活跃态 - 例如一个高速 LAN 环境， epoll 并不比 select/poll 效率高太多；相反，如果过多使用 epoll_ctl，效率相比还有稍微地降低但是一旦使用 idle connections 模拟 WAN 环境， epoll 的效率就远在 select/poll 之上了。

2.3 使用 mmap 加速内核与用户空间的消息传递

无论是 select、poll 还是 epoll 都需要内核把 FD 消息通知给用户空间，如何避免不必要的内存复制就显得非常重要，epoll 是通过内核和用户空间 mmap 同一块内存来实现的。

2.4 epoll API 更加简单

包括创建一个 epoll 描述符、添加监听事件、阻塞等待所监听的事件发生、关闭 epoll 描述符等。

值得说明的是，用来克服 select/poll 缺点的方法不只有 epoll， epoll 只是一种 Linux 的实现方案。在 freeBSD 下有 kqueue，而 dev/poll 是最古老的 Solaris 的方案，使用难度依次递增。 kqueue 是 freeBSD 宠儿，它实际上是一个功能相当丰富的 kernel 事件队列，它不仅仅是 select/poll 的升级，而且可以处理 signal、目录结构变化、进程等多种事件。 kqueue 是边缘触发的。 /dev/poll 是 Solaris 的产物，是这一系列高性能 API 中最早出现的。 Kernel 提供了一个特殊的设备文件 /dev/poll，应用程序打开这个文件得到操作 fd_set 的句柄，通过写入 polled 来修改它，一个特殊的 ioctl 调用用来替换 select。不过由于出现的年代比较早，所以 /dev/poll 的接口实现比较原始。

附表1： select/poll/epoll 区别

比较	select	poll	epoll
操作方式	遍历	遍历	回调
底层实现	数组	链表	红黑树
IO效率	每次调用都进行线性遍历， 时间复杂度为O(n)	每次调用都进行线性遍历， 时间复杂度为O(n)

事件通知方式，每当fd就绪，
系统注册的回调函数就会被调用，
将就绪fd放到readyList里面，
时间复杂度O(1)
最大连接数 | 1024 | 无上限 | 无上限
fd拷贝 | 每次调用select，
都需要把fd集合从用户态拷贝到内核态 | 每次调用poll，
都需要把fd集合从用户态拷贝到内核态 | 调用epoll_ctl时拷贝进内核并保存，
之后每次epoll_wait不拷贝

总结：epoll 是 Linux 目前大规模网络并发程序开发的首选模型。在绝大多数情况下性能远超 select 和 poll。目前流行的高性能 web 服务器 Nginx 正式依赖于 epoll 提供的高效网络套接字轮询服务。但是，在并发连接不高的情况下，多线程+阻塞 I/O 方式可能性能更好。

参考：

1. IO多路复用的三种机制Select，Poll，Epoll

---

每天用心记录一点点。内容也许不重要，但习惯很重要！