傳統的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
