嚴格的說，這個說法是不準確的，epoll的效能並不總是優於select.

首先需要了解下select和epoll的基本原理。

假設我們現在有100個socket連線，select的做法是，每隔一段時間輪詢這100個連線，判斷是否有網路事件，如果有，則進行處理。

epoll的做法是，建立一個連結串列，然後告訴作業系統，那100個連線如果哪個發生了網路事件，就給我放到這個連結串列裡，然後epoll每隔一段時間就檢查下這個連結串列是否有元素，有的話就進行處理。

對比不難發現，epoll相對於select，大大降低了空輪詢的次數，提高了輪詢的效率，同時，由於select輪詢時，需要將所有連線的fd從核心複製到使用者空間，增加了io開銷，epoll在這方面用mmap進行了最佳化。

不過，不能簡單的說誰更好。

比如，這100個連線，如果網路活動十分頻繁，那麼select每次輪詢時，只有很少或者根本沒有空輪詢，那select的無用功就很少，相反，epoll由於多了一步操作，效能反而更差。

因此，select適用於業務時間較短的短連結，比如一般的http服務。epoll適用於連線時間較長但是網路活動不頻繁的場景，比如聊天室。

應該是存在大量不活躍的連線時候，epoll會比select高效，因為select會進行全量遍歷。在連線數不多或者全部活躍的場景下，select可能比epoll高效。

select和poll都是輪詢指定的檔案描述符陣列，返回哪些可讀、可寫、異常。epoll是查詢epoll控制代碼，獲取可讀、可寫、異常的檔案描述符。

select對陣列元素的檢查，需要沒個描述符去判斷。epoll只需要返回當前有狀態（或狀態切換）的註冊到了該epoll控制代碼的描述符。

很多答案會說明使用者態和系統態切換是核心效能的關鍵，個人習慣認為是軟體層次和介面設計的必然結果：複用陣列的構建是使用者程式碼，epoll控制代碼內部實現是系統執行。