select :
1.每次調用 select()，都需要把 fd 集合從用戶態拷貝到內核態，這個開銷在 fd 很多時會很大，同時每次調用 select() 都需要在內核遍歷傳遞進來的所有 fd，這個開銷在 fd 很多時也很大。
2.單個進程能夠監視的文件描述符的數量存在最大限制，在 Linux 上一般爲 1024，可以通過修改宏定義甚至重新編譯內核的方式提升這一限制，但是這樣也會造成效率的降低
poll:
select() 和 poll() 系統調用的本質一樣，poll() 的機制與 select() 類似，與 select() 在本質上沒有多大差別，管理多個描述符也是進行輪詢，根據描述符的狀態進行處理，但是 poll() 沒有最大文件描述符數量的限制（但是數量過大後性能也是會下降）。poll() 和 select() 同樣存在一個缺點就是，包含大量文件描述符的數組被整體複製於用戶態和內核的地址空間之間，而不論這些文件描述符是否就緒，它的開銷隨着文件描述符數量的增加而線性增大。
epoll:
epoll 是在 2.6 內核中提出的，是之前的 select() 和 poll() 的增強版本。相對於 select() 和 poll() 來說，epoll 更加靈活，沒有描述符限制。epoll 使用一個文件描述符管理多個描述符，將用戶關係的文件描述符的事件存放到內核的一個事件表中，這樣在用戶空間和內核空間的 copy 只需一次。
copy一次
回調
總結：
與select相比，epoll的回調機制使得資源能夠直接使用在有活動的事件上，而不用線性輪詢所有的事件。同時 epoll通過內核與用戶空間mmap同一塊內存，減少了用戶空間和內核空間的數據交換，解決了select的重要痛點。
另一方面，LT是epoll的默認操作模式，當epoll_wait函數檢測到有事件發生並將通知應用程序，而應用程序不一定必須立即進行處理，這樣epoll_wait函數再次檢測到此事件的時候還會通知應用程序，直到事件被處理。
而ET模式，只要epoll_wait函數檢測到事件發生，通知應用程序立即進行處理，後續的epoll_wait函數將不再檢測此事件。因此ET模式在很大程度上降低了同一個事件被epoll觸發的次數，因此效率比LT模式高。