select和epoll的優缺點
select，epoll都是IO多路複用的機制。I/O多路複用就通過一種機制，可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程序進行相應的讀寫操作。但select，epoll本質上都是同步I/O，因爲他們都需要在讀寫事件就緒後自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而異步I/O則無需自己負責進行讀寫，異步I/O的實現會負責把數據從內核拷貝到用戶空間。
select
文件描述符的數量
單個進程能夠監視的文件描述符的數量存在最大限制，通常是1024，當然可以更改數量；(在linux內核頭文件中定義：#define __FD_SETSIZE 1024)
就緒fd採用輪詢的方式掃描
select返回的是int，可以理解爲返回的是ready(準備好的)一個或者多個文件描述符，應用程序需要遍歷整個文件描述符數組才能發現哪些fd句柄發生了事件，由於select採用輪詢的方式掃描文件描述符（不知道那個文件描述符讀寫數據，所以需要把所有的fd都遍歷），文件描述符數量越多，性能越差
內核 /用戶空間內存拷貝
select每次都會改變內核中的句柄數據結構集(fd集合)，因而每次調用select都需要從用戶空間向內核空間複製所有的句柄數據結構(fd集合)，產生巨大的開銷
select的觸發方式
select的觸發方式是水平觸發，應用程序如果沒有完成對一個已經就緒的文件描述符進行IO操作，那麼之後每次調用select還是會將這些文件描述符通知進程
epoll
先看一下epoll和select調用接口上的不同，select只提供了一個函數——select函數。而epoll提供了三個函數，epoll_create,epoll_ctl和epoll_wait。
- epoll_create是創建一個epoll句柄；
- epoll_ctl是註冊要監聽的事件類型；
- epoll_wait則是等待事件的產生。
文件描述符的數量
epoll沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於1024,舉個例子,在2GB內存的機器上是20萬左右（具體數目可以cat /proc/sys/fs/file-max查看）
就緒fd 採用事件方式回調
epoll在內核中會維護一個紅黑樹和一個雙向鏈表，紅黑樹存放通過epoll_ctl方法向epoll對象中添加進來的事件，所以不需要每次調用epoll_wait都全量複製所有的事件結構。雙向鏈表存放就緒的事件，所有添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關係，也就是說，當相應的事件發生時會調用這個回調方法，這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。調用epoll_wait就會直接返回鏈表中的就緒事件，效率高
內核 /用戶空間內存拷貝
epoll的解決方案在epoll_ctl函數中。每次註冊新的事件到epoll句柄中時（在epoll_ctl中指定EPOLL_CTL_ADD），會把所有的fd拷貝進內核，而不是在epoll_wait的時候重複拷貝。epoll保證了每個fd在整個過程中只會拷貝一次
epoll的觸發方式
水平觸發LT和邊緣觸發ET
水平觸發LT
其中LT就是與select和poll類似，當被監控的文件描述符上有可讀寫事件發生時，epoll_wait()會通知處理程序去讀寫。如果這次沒有把數據一次性全部讀寫完(如讀寫緩衝區太小)，那麼下次調用 epoll_wait()時，它還會通知你在上次沒讀寫完的文件描述符上繼續讀寫
邊緣觸發ET
當被監控的文件描述符上有可讀寫事件發生時，epoll_wait()會通知處理程序去讀寫。如果這次沒有把數據全部讀寫完(如讀寫緩衝區太小)，那麼下次調用epoll_wait()時，它不會通知你，也就是它只會通知你一次，直到該文件描述符上出現第二次可讀寫事件纔會通知你
總結
未驗證總結：併發小於1萬select，併發大於百萬epoll
參考：
https://blog.csdn.net/davidsguo008/article/details/73556811
https://www.bilibili.com/video/BV1jJ411j7ot?from=search&seid=5931515930271108680
https://github.com/0voice/interview_internal_reference/blob/master/01.%E9%98%BF%E9%87%8C%E7%AF%87/1.1.5%20%E5%85%B3%E4%BA%8Eepoll%E5%92%8Cselect%E7%9A%84%E5%8C%BA%E5%88%AB%EF%BC%8C%E4%BB%A5%E4%B8%8B%E5%93%AA%E4%BA%9B%E8%AF%B4%E6%B3%95%E6%98%AF%E6%AD%A3%E7%A1%AE%E7%9A%84.md
https://blog.csdn.net/shangsongwww/article/details/102619771