彻底搞懂 select/poll/epoll，就这篇了

女爷i 2023-09-28 10:24 131阅读 0赞

之前已经把网络 I/O 相关要点都盘了，还剩 select/poll/epoll 这几个区别没说，这篇就来搞搞它们，并且是从完全理解原理的角度来区分它们。

本来是要上源码的，但是感觉没啥必要，身为应用开发者我觉得理解原理就行了，源码反正看了就忘了，理解才是最重要！所以我就尽量避免代码且用大白话来盘一盘这三个玩意。

话不多说，发车。

## 小思考 ##

首先，我们知道 select/poll/epoll 是用来实现多路复用的，即一个线程利用它们即可 hold 诸多个 socket。

按照这个思路，线程不可能被任何一个被管理的 Socket 阻塞，且任一个 Socket 来数据之后都得告知 select/poll/epoll 线程。

想想看，这应该如何实现呢？

## 我们拿 select 的逻辑来分析下 ##

按照我们的理解，select 管理多个 Socket 的模型如下图所示：

![ef25f873b0255aae1955fe15feabe31f.png][]

> 这里要注意一下内核态和用户态的交互，用户程序访问不了内核空间。

所以，我们调用 select 会把所有要管理的 socket 的 fd (文件描述符，Linux下皆为文件，简单理解就是通过 fd 能找到这个 socket)传到内核中。

此时，要遍历所有 socket，看看是否有感兴趣的事件发生。如果没有一个 socket 有事件发生，那么 select 一上线程就需要让出 cpu 阻塞等待，这个等待可以是不设置超时时间的死等，也可以是设置 timeout 的有超时时间的等待。

假设此时客户端发送了数据，网卡接收到的数据塞到对应的 socket 的接收队列中，此时 socket 知道来数据了，那如何唤醒 select 呢？

其实每个 socket 有个属于自己的睡眠队列，select 会安排一个内应，即在被管理的 socket 的睡眠队列里面塞入一个 entry。

![dbe386eec3767e3d15a61e15a44d7a5d.png][]

当 socket 接收到网卡的数据后，就会去它的睡眠队列里遍历 entry，调用 entry 设置的 callback 方法，这个 callback 方法里就能唤醒 select ！

所以 select 在每个被它管理的人 socket 每个睡眠队列里都塞入一个与它相关的 entry，这样不论哪个 socket 来数据了，它立马就能被唤醒然后干活！

但是，select 的实现不太好，因为唤醒的 select 此时只知道来活了，并不知道具体是哪个 socket 来数据了，所以只能傻傻地遍历所有 socket ，看看到底是哪个 scoket 来活了，然后把所有来活的 socket 封装成事件返回。

这样用户程序就能获得发生的事件，然后进行 I/O 和业务处理了。

这就是 select 的实现逻辑，理解起来应该不难。

这里再提一嘴 select 的限制，因为被管理的 socket fd 需要从用户空间拷贝到内核空间，为了控制拷贝的大小而做了限制，即每个 select 能拷贝的 fds 集合大小只有1024。

然后要改的话只能修改宏..再重新编译内核。网上很多文章都是这样说的，但是（没错有个但是）。

我看了一篇文章，确实有这个宏愿，值也是 1024，但内核根本没有限制 fds 集合的大小。然后托人问了个内核大佬，大佬说内核确实没做限制，glibc那层做了。

所以..重新编译内核？那篇文章放在文末。

## poll ##

poll 这玩意相比于 select 主要就是优化了 fds 的结构，不再是 bit 数组了，而是一个叫 pollfd 的玩意，反正就是不用管啥 1024 的限制了。

不过现在也没人用 poll，我就不多说了。

## epoll ##

这个就是重点了。

相信看了 select 的确，我们稍微思考下，就能想出几个可以优化的点。

比如，为什么每次 select 需要把监控的 fds 传输到内核里？不能在内核里维护么？

为什么 socket 只唤醒 select，不能告诉它是哪个 socket 来数据了？

epoll 主要就是基于上面两点做了优化。

首先，搞了个叫 epoll\_ctl 的方法，这方法就是用来管理维护 epoll 所监控的那些 socket。

如果你的 epoll 要新加一个 socket 来管理，那就调用 epoll\_ctl，要删除一个 socket 也调用 epoll\_ctl，通过不同的入参来控制增删改。

![12c021b567829d143b93fc2f4952f3fb.png][]

这样，在内核里面就维护了此 epoll 管理的 socket 集合，这样就不用每次调用的时候都得把所有管理的 fds 拷贝到内核了。

对了，这个 socket 集合是用红黑树实现的。

然后和 select 类似，每个 socket 的睡眠队列里都会加个 entry，当每个 socket 来数据之后，同样也会调用 entry 对应的 callback。

与 select 不同的是，引入了一个 ready\_list 双向链表，callback 里面会把当前的 socket 加入到 ready\_list 然后唤醒 epoll。

![e923e0a6ebfb8ab3f2fc470863658a68.png][]

这样被唤醒的 epoll 只需要遍历 ready\_list 即可，这个链表里一定是有数据可读的 socket，相比于 select 就不会做无用的遍历了。

同时收集到的可读的 fd 按理是要拷贝到用户空间的，这里又做了个优化，利用了 mmp，让用户空间和内核空间映射到同一块内存中，这样就避免了拷贝。

完美啊~

这就是 epoll 基于 select 所作的优化，还有一些差别没细说，比如 epoll 是阻塞睡眠在一个 single\_epoll\_wait\_list 而不是 socket 的睡眠队列等等，我就不提了，理解上面的这些已经够了。

## ET< ##

都谈到 epoll 了，避免不了要扯扯 ET 和 LT 两个模式。

ET，边沿触发。

按照上面的逻辑就是 epoll 遍历 ready\_list 的时候，会把 socket 从 ready\_list 里面移除，然后读取这个 scoket 的事件。

而 LT，水平触发，有点不一样。

在这个模式下 epoll 遍历 ready\_list 的时候，会把 socket 从 ready\_list 里面移除，然后读取这个 scoket 的事件，如果这个 socket 返回了感兴趣的事件，那么当前这个 socket 会再被加入到 ready\_list 中，这样下次调用 epoll\_wait 的时候，还能拿到这个 socket。

这就是这两者最本质的区别了。

> 看到这有人会问，这两种模式的使用会造成哪种不一样的结果？

如果此时一个客户端同时发来了 5 个数据包，按正常的逻辑，只需要唤醒一次 epoll ，把当前 socket 加一次到 ready\_list 就行了，不需要加 5 次。然后用户程序可以把 socket 接收队列的所有数据包都读完。

但假设用户程序就读了一个包，然后处理报错了，后面不读了，那后面的 4 个包咋办？

如果是 ET 模式，就读不了了，因为没有把 socket 加入到 ready\_list 的触发条件了。除非这个客户端发了新的数据包过来，这样才会再把当前 socket 加入到 ready\_list，在新包过来之前，这 4 个数据包都不会被读到。

而 LT 模式不一样，因为每次读完有感兴趣的事件发生之后，会把当前 socket 再加入到 ready\_list，所以下次肯定能读到这个 socket，所以后面的 4 个数据包会被访问到，不论客户端是否发送新包。

至此，我想你应该理解什么是 ET ，什么是 LT 了，而不用对着一些什么状态变更触发这些不易理解的名词而发晕。

## 最后 ##

好了，今天的分析到此完毕，我个人觉得对 select/poll/epoll 的理解到这个程度就差不多了，当然还有很多细节，需要自行去看源码探究，问我我也不懂，这些都是阅读网上的源码分析文章得出的结论。

我也不建议读的那么深，毕竟人的精力有限对吧，有涉及到相关底层优化的时候，再去研究也不迟。

![36549c508dfb4fea828a0a0f50f3d9ca.jpeg][]

[ef25f873b0255aae1955fe15feabe31f.png]: https://img-blog.csdnimg.cn/img_convert/ef25f873b0255aae1955fe15feabe31f.png
[dbe386eec3767e3d15a61e15a44d7a5d.png]: https://img-blog.csdnimg.cn/img_convert/dbe386eec3767e3d15a61e15a44d7a5d.png
[12c021b567829d143b93fc2f4952f3fb.png]: https://img-blog.csdnimg.cn/img_convert/12c021b567829d143b93fc2f4952f3fb.png
[e923e0a6ebfb8ab3f2fc470863658a68.png]: https://img-blog.csdnimg.cn/img_convert/e923e0a6ebfb8ab3f2fc470863658a68.png
[36549c508dfb4fea828a0a0f50f3d9ca.jpeg]: https://img-blog.csdnimg.cn/36549c508dfb4fea828a0a0f50f3d9ca.jpeg