传统的I/O多路复用机制，如select和poll，虽然在一定程度上解决了这一问题，但在面对大规模并发连接时，其性能瓶颈逐渐显现
为了克服这些限制，Linux内核引入了epoll机制，作为select和poll的增强版本，极大地提高了在大量并发连接中只有少量活跃连接时的系统CPU利用率
一、select和poll的局限性 在讨论epoll之前，有必要先了解select和poll的工作原理及其存在的问题
select方法通过将一个文件描述符集合传递给内核，询问哪些文件描述符已经准备好进行读、写或出现异常
然而，select存在几个显著的局限性： 1.资源消耗大：每次调用select时，都需要将监控的文件描述符集合从用户态拷贝到内核态
在高并发场景下，这种拷贝操作会消耗大量资源
2.监听端口数量有限：select能够监听的文件描述符数量有限，默认通常只能监视1024个文件描述符（尽管可以通过修改系统配置来增加这个限制，但这并不能从根本上解决问题）
3.遍历效率低下：当有事件返回时，select需要遍历整个文件描述符集合，找到可读、可写或异常的文件描述符
这种遍历操作在文件描述符数量较多时，效率极低
poll方法对select的监听端口数量限制进行了改进，但它仍然存在两个核心问题： 1.资源消耗大：与select类似，每次调用poll时，都需要将监控的文件描述符集合从用户态拷贝到内核态，导致高并发场景下资源消耗大
2.遍历效率低下：当有事件返回时，poll同样需要遍历整个文件描述符集合，找到可读、可写的文件描述符
二、epoll的引入与优势 epoll（Event Poll）是Linux内核为处理大批量文件描述符而改进的poll机制，首次在Linux内核2.5.44版本中引入
epoll旨在替换select和poll系统调用，以在更苛刻的应用场景下实现更好的性能，特别是在需要监控大量文件描述符时
与select和poll相比，epoll具有以下几个显著优势： 1.高效的事件通知：epoll采用了一种基于事件驱动的机制，当有事件发生时，内核会异步通知应用程序，而不需要应用程序主动轮询
这种机制极大地提高了事件处理的效率
2.优化的数据结构：epoll使用红黑树来管理事件块，红黑树是一种自平衡二叉搜索树，能够在O(logn)的时间复杂度内完成查找、插入和删除操作
这使得epoll在处理大量文件描述符时，能够保持较高的性能
3.就绪列表：epoll维护了一个就绪列表，用于存储已经准备好进行读、写或异常处理的文件描述符
当应用程序调用epoll_wait时，内核会检查就绪列表，并将准备好的事件复制给用户空间，避免了遍历整个文件描述符集合的开销
三、epoll的使用 epoll的使用主要包括以下几个步骤： 1.初始化epoll句柄：使用epoll
