在网络服务器开发中，程序经常需要同时监控多个文件描述符(file descriptor)的状态——是否有数据可读、是否可以写入、是否发生异常。最基本的方案是为每个连接分配一个线程（或进程），但这种方式在C10K甚至C100K规模下会遇到严重的资源瓶颈：每个线程需要独占一个内核栈（默认8KB）、调度开销随线程数增长线性增加、上下文切换的cache污染在高并发下成为主要性能瓶颈。
I/O多路复用(I/O Multiplexing)的核心思想是：用一个线程同时监控多个文件描述符，只有当某个fd真正就绪时才进行处理，从而避免轮询浪费和线程爆炸。Linux提供了三种系统调用实现这一目标：select、poll，以及本文的主角——epoll。
select是POSIX标准定义的最古老的I/O多路复用接口，诞生于1983年。其核心函数签名如下：
select有三个严重的性能问题：1) fd_set是位图结构，最大 fd 数量受 FD_SETSIZE 限制（通常1024）；2) 每次调用都需要将fd_set从用户空间拷贝到内核空间，然后内核需要遍历所有被监控的fd来标记就绪状态；3) 返回后用户需要再次遍历整个fd_set来找出哪些fd就绪。这三个问题导致select的时间复杂度是O(N)，且每次调用都是全量遍历。
poll解决了FD_SETSIZE限制的问题，使用动态数组代替位图：
但poll仍然有三个性能问题：1) 每次调用仍需要全量拷贝pollfd数组到内核；2) 内核仍需遍历全部fd才能标记就绪；3) 返回后用户仍需遍历整个数组。时间复杂度依然是O(N)，所以在高并发场景下与select一样会线性退化。
epoll引入了三个系统调用，将"设置监控"和"等待事件"分离：
这种分离设计是关键优化点。epoll在内核中维护一棵红黑树(监控的所有fd)和一个就绪链表(已就绪的fd)。epoll_ctl负责红黑树的增删改（O(log N)），epoll_wait只需检查就绪链表是否为空（O(1)），完全避免了全量遍历。
epoll的核心数据结构是eventpoll，它在内核中的组织如下：
每个被监控的fd对应一个epitem节点。epoll的工作流程是：当某个fd上有数据到达时，内核通过回调机制(ep_poll_callback)将该fd对应的epitem加入就绪链表，并唤醒在epoll_wait中阻塞的进程。epoll_wait返回时只需遍历就绪链表，将就绪事件拷贝回用户空间。
epoll支持两种触发模式，这是很多开发者容易混淆的概念：
- LT(Level Triggered，水平触发)：默认模式。只要fd的接收缓冲区中有未读数据（即缓冲区非空），epoll_wait就会持续报告该fd就绪。这种模式编程最简单，不用担心遗漏事件，但也可能造成不必要的epoll_wait调用。
- ET(Edge Triggered，边缘触发)：只在fd状态从"未就绪"变为"就绪"时才通知一次。必须一次性读完所有数据（直到read返回EAGAIN/EWOULDBLOCK），否则可能丢失后续数据（实际上不会丢失，内核会再触发一次，但如果没有新数据到来就不会再通知了）。
ET模式的关键在于：必须使用非阻塞fd，且必须循环read直到返回-1且errno为EAGAIN。这样可以减少epoll_wait的系统调用次数，在极高并发下性能比LT高出约10-15%。
epoll与select/poll最本质的区别在于回调驱动。每个fd对应一个ep_poll_callback函数：当网卡收到数据、管道有写入、socket关闭等事件发生时，内核会调用该fd的poll方法，如果返回了感兴趣的事件掩码，内核就会调用ep_poll_callback将该fd加入就绪链表。这相当于把O(N)的主动遍历变成了O(1)的被动回调。
epoll_wait在返回就绪事件时，需要将内核的epoll_event数组拷贝到用户空间。在极高频率下（每秒数十万次的epoll_wait调用），这个拷贝的开销不可忽视。Linux 5.1引入了epoll_pwait2配合io_uring可以进一步减少系统调用次数。此外，配合splice/sendfile等零拷贝技术，可以实现数据从 NIC → kernel buffer → socket fd的全路径零拷贝。
当多个进程/线程在同一个epoll实例上调用epoll_wait时，内核使用等待队列(wait queue)的回调机制来实现高效唤醒。当就绪事件到来时，内核遍历等待队列上的所有waiter，只唤醒一个（独占模式WQ_FLAG_EXCLUSIVE）或全部唤醒（非独占）。独占模式可以避免"惊群效应"(thundering herd)，这在多线程accept的经典场景中非常重要。
发表评论 取消回复