使用select()时，少数活跃FD会导致其他FD出现饥饿问题吗？

• select() 本身仅负责检测哪些文件描述符（FD）处于就绪状态，不会对FD的处理顺序做任何调度或公平性保证。如果你的程序按固定顺序（比如FD编号从小到大）遍历就绪FD，而高活跃FD恰好排在前面，那么每次select()返回后，程序会优先处理这个高活跃FD——由于它持续有大量数据传入，处理它可能占用大量CPU时间，甚至处理完一轮后，它立刻又变成就绪状态，导致select()再次立刻返回，程序陷入“处理高活跃FD→调用select→处理高活跃FD”的循环，其他就绪FD完全得不到处理机会。

• 哪怕你遍历所有就绪FD，高活跃FD的持续就绪也会挤压其他FD的处理窗口。比如，每次处理完高活跃FD后，它马上又有新数据，select()几乎不会阻塞，程序会立刻回到处理它的流程中，其他FD的就绪事件虽然被select()检测到，但程序始终没有足够的时间去处理它们，最终导致这些FD的请求被无限延迟，出现饥饿。

怎么避免这种情况？ #

• 给高活跃FD的处理加“上限”：用非阻塞IO，每次处理该FD时只读取固定大小的数据（比如1KB），然后立刻切换去处理其他就绪FD，避免长时间占用CPU。
• 改用更高效的IO多路复用机制：比如epoll的边缘触发（ET）模式，高活跃FD只会在状态变化时触发一次通知，不会持续唤醒程序；或者用epoll的水平触发（LT）配合非阻塞IO，控制每次处理的量。
• 调整FD处理顺序：采用轮询方式遍历就绪FD，或者给低活跃FD设置优先级，确保它们能得到处理机会。

内容的提问来源于stack exchange，提问作者anand