盘点Linux Epoll那些致命弱点
内容提要
本文讨论了Linux上I/O多路复用技术面临的挑战及问题。在多线程扩展性方面，水平触发模式下存在过度唤醒问题，边缘触发模式下存在过度唤醒和饥饿问题。解决方法包括使用EPOLLEXCLUSIVE标志和EPOLLONESHOT模拟LT + EPOLLEXCLUSIVE效果。在处理大量TCP连接的read(2)方面，水平触发模式下存在数据错乱问题，边缘触发模式下也存在数据错乱问题。正确的做法是使用EPOLLONESHOT标志保证数据落到同一个线程上。另外，还讨论了epoll中文件描述符与文件描述的关系问题。
延伸解读
多线程扩展性：LT与ET的固有缺陷
文章指出，epoll在多线程负载均衡上存在明显短板。LT模式下，惊群效应导致多个worker被无谓唤醒，浪费CPU；ET模式虽只唤醒一个，但可能引发饥饿，且仍有不必要的唤醒。直到Linux 4.5引入EPOLLEXCLUSIVE，才提供可扩展的解决方案。这反映出epoll最初设计并未充分考虑多核场景。
数据错乱风险：EPOLLONESHOT的必要性
处理大量TCP连接时，即使使用EPOLLEXCLUSIVE，LT和ET模式仍可能导致同一连接的数据被不同线程读取，造成乱序。文章强调，唯一可靠的方法是使用EPOLLONESHOT标志，确保每个连接的数据始终由同一线程处理，并在处理完后重新注册。这增加了编程复杂度，但避免了数据竞争。
fd与file description生命周期陷阱
epoll注册的是fd与内核file description的元组，而非fd本身。若在close前未显式调用epoll_ctl(EPOLL_CTL_DEL)，且file description仍有其他引用（如dup），epoll会继续上报已关闭fd的事件，且无法再删除。文章建议始终先DEL再close，但封装库时难以强制用户遵守，因此基于epoll的抽象层设计需格外谨慎。
Q&A
Linux上epoll的多线程扩展性问题主要表现在哪些方面？
主要表现为负载均衡问题，尤其是在处理大量TCP连接时，水平触发和边缘触发模式都存在过度唤醒和数据错乱的问题。
如何解决epoll在水平触发模式下的过度唤醒问题？
可以使用EPOLLEXCLUSIVE标志来避免惊群效应，确保只有一个线程被唤醒。
边缘触发模式下epoll存在哪些问题？
边缘触发模式下存在不必要的唤醒和饥饿问题，可能导致某些线程长时间得不到处理机会。
在处理大量TCP连接的read(2)时，epoll会遇到什么挑战？
在处理大量TCP连接时，水平触发和边缘触发模式都可能导致数据错乱，影响数据的顺序。
使用EPOLLONESHOT标志有什么好处？
使用EPOLLONESHOT标志可以确保数据始终落到同一个线程上，避免数据错乱。
epoll中文件描述符与文件描述的关系是什么？
epoll中的文件描述符与内核中的文件描述的生命周期不一致，可能导致在关闭文件描述符后仍然接收到事件。
