epoll_wait事件顺序疑问：Linux 4.9.62下是否存在套接字饥饿

先直接给你明确结论：在Linux 4.9.62内核的水平触发模式下，epoll_wait不是按FIFO队列返回就绪事件，而是会从epoll内部的就绪链表头部开始遍历，优先返回更早被添加到epoll实例的套接字。如果你的就绪套接字数始终超过epoll_event数组的容量，后加入的套接字确实会出现饥饿问题。

内核逻辑细节（针对4.9.62版本） #

• epoll维护了一个双向循环就绪链表：当套接字触发就绪事件且不在链表中时，会被追加到链表的尾部。
• 调用epoll_wait()时，内核从就绪链表的头部开始逐个取出事件，拷贝到你提供的epoll_event数组里，直到数组填满或者遍历完整个链表。
• 水平触发（未设置EPOLLET）的关键特性：只要套接字还处于就绪状态（比如读缓冲区还有未读数据、写缓冲区可写），它不会被从就绪链表中移除。也就是说，下一次调用epoll_wait()时，它依然待在链表的原有位置，会被优先再次选中返回。

你的场景具体分析 #

假设你按1-10的顺序把10个套接字加入epoll，每次epoll_wait()只分配5个epoll_event结构：

1. 第一次调用时，所有10个套接字都就绪，内核从链表头部取前5个（1-5）返回给你。
2. 你处理这5个的过程中，所有10个套接字又收到新数据——但1-5本来就处于就绪状态（水平触发下没处理完就一直就绪），所以它们还留在链表的头部区域；6-10也一直处于就绪状态，待在链表后半段。
3. 第二次调用epoll_wait()时，内核还是从链表头部开始取，依然返回1-5，6-10根本没机会被处理，时间长了就会出现饥饿。

解决饥饿的几种思路 #

• 增大epoll_event数组容量：如果业务场景中就绪套接字数量较多，直接分配足够大的数组（比如和最大连接数匹配）是最简单的方案。
• 切换到边缘触发（EPOLLET）模式：边缘触发下，套接字只有在状态变化时才会触发事件，不会一直赖在就绪链表中。但这要求你必须一次性处理完所有就绪数据（比如循环读直到返回EAGAIN），实现复杂度会高一些。
• 手动调整就绪顺序（不推荐）：比如每次处理完一批事件后，先把这些套接字从epoll中移除再重新添加，让它们进入就绪链表的尾部，给其他套接字腾机会。但这种方式会带来额外的系统调用开销，高并发场景下不建议用。

内容的提问来源于stack exchange，提问作者Mr. Rogers