linux I/O多路復用模型，為什么epoll性能高于select和poll？嚴格地說，這種說法是不準確的。Epoll的性能并不總是比select好。首先，我們需要了解select和Epoll的基本

linux I/O多路復用模型，為什么epoll性能高于select和poll？

嚴格地說，這種說法是不準確的。Epoll的性能并不總是比select好。首先，我們需要了解select和Epoll的基本原理。

假設我們現(xiàn)在有100個套接字連接。select的方法是每隔一段時間輪詢這100個連接，以確定是否存在網(wǎng)絡事件。如果有，它會處理它們。

Epoll的方法是創(chuàng)建一個鏈表，然后告訴操作系統(tǒng)，如果100個連接中的任何一個發(fā)生網(wǎng)絡事件，它將被放入鏈表中。然后epoll每隔一段時間就會檢查鏈表中是否有元素，如果有則進行處理。

與select相比，epoll大大減少了空輪詢次數(shù)，提高了輪詢效率。同時，epoll使用MMAP對其進行優(yōu)化，因為它需要在select輪詢期間將所有連接的FD從內(nèi)核復制到用戶空間，這會增加IO開銷。

然而，我們不能簡單地說誰更好。

例如，如果100個連接的網(wǎng)絡活動非常頻繁，則select的每次輪詢將很少或沒有空輪詢，select的無用功能將非常少。相反，epoll的性能會因為多了一步操作而變差。

因此，select適用于業(yè)務時間較短的短鏈接，如通用HTTP服務。Epoll適用于連接時間長但網(wǎng)絡活動不頻繁的場景，如聊天室。

epoll讀到一半又有新事件來了，該怎么辦？

Epoll需要與多個線程協(xié)同工作才能獲得最佳性能。當輪詢線程接收到IO時，它會立即將工作移交給預先分配的線程池以完成讀寫工作，而不是阻塞輪詢線程。這樣，就不會有讀寫另一個信號的問題。