epoll 的数据结构：红黑树、就绪队列与回调机制
💡
原文中文，约18600字，阅读约需45分钟。
📝
内容提要
2003年，Davide Libenzi 提交了epoll补丁，解决了select和poll在I/O多路复用中的性能问题。epoll通过内核维护监控集合，仅在事件发生时回调，显著提高了效率。其核心数据结构包括红黑树、就绪链表和回调函数，优化了事件处理流程，特别适合高并发场景下监控大量连接。本文深入分析了epoll的实现原理及其在Linux内核中的应用。
🎯
关键要点
- 2003年，Davide Libenzi 提交了epoll补丁，解决了select和poll在I/O多路复用中的性能问题。
- epoll通过内核维护监控集合，仅在事件发生时回调，显著提高了效率。
- epoll的核心数据结构包括红黑树、就绪链表和回调函数，优化了事件处理流程。
- epoll的设计将'注册兴趣'和'等待事件'拆分为独立操作，提升了性能。
- epoll_wait的复杂度只与就绪事件数量有关，而不是监控的总fd数。
- epoll在高并发场景下表现优异，适合监控大量连接。
- 与io_uring相比，epoll在网络I/O场景下性能相近，但io_uring在磁盘I/O场景下表现更好。
- epoll的设计思想强调使用合适的数据结构解决合适的问题，具有长期的实用价值。
❓
延伸问答
epoll 的主要优势是什么？
epoll 通过内核维护监控集合，仅在事件发生时回调，显著提高了 I/O 多路复用的效率，特别适合高并发场景。
epoll 的核心数据结构有哪些？
epoll 的核心数据结构包括红黑树、就绪链表和回调函数。
epoll_wait 的复杂度与什么有关？
epoll_wait 的复杂度只与就绪事件的数量有关，而不是监控的总文件描述符数。
epoll 与 select/poll 的主要区别是什么？
epoll 通过内核维护监控集合，避免了每次调用都要拷贝整个文件描述符集合的性能损耗，而 select/poll 每次调用都需要全量操作。
epoll 的回调机制是如何工作的？
当 fd 上发生事件时，内核的协议栈代码会唤醒该 fd 的等待队列，调用回调函数将 epitem 加入就绪链表，并唤醒 epoll_wait 中的进程。
epoll 在高并发场景下的表现如何？
epoll 在高并发场景下表现优异，能够有效监控大量连接，适合处理高并发的网络应用。
➡️
