什麽是epoll

epoll是什麽？按照man手冊的說法：是為處理大批量句柄而作了改進的poll。當然，這不是2.6內核才有的，它是在2.5.44內核中被引進的(epoll(4) is a new API introduced in Linux kernel 2.5.44)，它幾乎具備了之前所說的一切優點，被公認為Linux2.6下性能最好的多路I/O就緒通知方法。

epoll的相關系統調用

epoll只有epoll_create,epoll_ctl,epoll_wait 3個系統調用。

1. int epoll_create(int size);

創建一個epoll的句柄。自從linux2.6.8之後，size參數是被忽略的。需要註意的是，當創建好epoll句柄後，它就是會占用一個fd值，在linux下如果查看/proc/進程id/fd/，是能夠看到這個fd的，所以在使用完epoll後，必須調用close()關閉，否則可能導致fd被耗盡。

2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll的事件註冊函數，它不同於select()是在監聽事件時告訴內核要監聽什麽類型的事件，而是在這裏先註冊要監聽的事件類型。

第一個參數是epoll_create()的返回值。

第二個參數表示動作，用三個宏來表示：

EPOLL_CTL_ADD：註冊新的fd到epfd中；

EPOLL_CTL_MOD：修改已經註冊的fd的監聽事件；

EPOLL_CTL_DEL：從epfd中刪除一個fd；

第三個參數是需要監聽的fd。

第四個參數是告訴內核需要監聽什麽事，struct epoll_event結構如下：

typedef union epoll_data {  
    void *ptr;  
    int fd;  
    __uint32_t u32;  
    __uint64_t u64;  
} epoll_data_t;  
 //感興趣的事件和被觸發的事件  
struct epoll_event {  
    __uint32_t events; /* Epoll events */  
    epoll_data_t data; /* User data variable */  
};

events可以是以下幾個宏的集合：

EPOLLIN ：表示對應的文件描述符可以讀（包括對端SOCKET正常關閉）；

EPOLLOUT：表示對應的文件描述符可以寫；

EPOLLPRI：表示對應的文件描述符有緊急的數據可讀（這裏應該表示有帶外數據到來）；

EPOLLERR：表示對應的文件描述符發生錯誤；

EPOLLHUP：表示對應的文件描述符被掛斷；

EPOLLET： 將EPOLL設為邊緣觸發(Edge Triggered)模式，這是相對於水平觸發(Level Triggered)來說的。

EPOLLONESHOT：只監聽一次事件，當監聽完這次事件之後，如果還需要繼續監聽這個socket的話，需要再次把這個socket加入到EPOLL隊列裏

3. int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);

收集在epoll監控的事件中已經發送的事件。參數events是分配好的epoll_event結構體數組，epoll將會把發生的事件賦值到events數組中（events不可以是空指針，內核只負責把數據復制到這個events數組中，不會去幫助我們在用戶態中分配內存）。maxevents告之內核這個events有多大，這個 maxevents的值不能大於創建epoll_create()時的size，參數timeout是超時時間（毫秒，0會立即返回，-1是永久阻塞）。如果函數調用成功，返回對應I/O上已準備好的文件描述符數目，如返回0表示已超時。

Epoll的2種工作方式-水平觸發（LT）和邊緣觸發（ET）

水平觸發（LT）：缺省的工作方式，如果一個描述符就緒，內核就會通知處理，如果不進行處理，下一次內核還是會通知

邊緣觸發（ET）：只支持非阻塞描述符。需要程序保證緩存區的數據全部被讀取或者全部寫出（以為ET模式下，描述符的就緒不會再次通知），因此需要發的非阻塞的描述符。

對於讀操作，如果read一次沒有讀盡buffer中的數據，那麽下次將得不到讀就緒的通知，造成buffer中已有的數據無機會讀出，除非有新的數據再次到達。對於寫操作，主要是因為ET模式下fd通常為非阻塞造成的一個問題——如何保證 將用戶要求寫的數據寫完。

epoll相比於select/poll的優點：

1.支持一個進程打開大數目的socket描述符(FD)

select 最不能忍受的是一個進程所打開的FD是有一定限制的，由FD_SETSIZE設置，默認值是2048。對於那些需要支持的上萬連接數目的IM服務器來說顯然太少了。這時候你一是可以選擇修改這個宏然後重新編譯內核，不過資料也同時指出這樣會帶來網絡效率的下降，二是可以選擇多進程的解決方案(傳統的 Apache方案)，不過雖然linux上面創建進程的代價比較小，但仍舊是不可忽視的，加上進程間數據同步遠比不上線程間同步的高效，所以也不是一種完美的方案。不過 epoll則沒有這個限制，它所支持的FD上限是最大可以打開文件的數目，這個數字一般遠大於2048,舉個例子,在1GB內存的機器上大約是10萬左右，具體數目可以cat /proc/sys/fs/file-max察看,一般來說這個數目和系統內存關系很大。

2.IO效率不隨FD數目增加而線性下降

傳統的select/poll另一個致命弱點就是當你擁有一個很大的socket集合，不過由於網絡延時，任一時間只有部分的socket是"活躍"的，但是select/poll每次調用都會線性掃描全部的集合，導致效率呈現線性下降。但是epoll不存在這個問題，它只會對"活躍"的socket進行操作---這是因為在內核實現中epoll是根據每個fd上面的callback函數實現的。那麽，只有"活躍"的socket才會主動的去調用 callback函數，其他idle狀態socket則不會，在這點上，epoll實現了一個"偽"AIO，因為這時候推動力在os內核。在一些 benchmark中，如果所有的socket基本上都是活躍的---比如一個高速LAN環境，epoll並不比select/poll有什麽效率，相反，如果過多使用epoll_ctl,效率相比還有稍微的下降。但是一旦使用idle connections模擬WAN環境,epoll的效率就遠在select/poll之上了。

3.使用mmap加速內核與用戶空間的消息傳遞

無論是select,poll還是epoll都需要內核把FD消息通知給用戶空間，如何避免不必要的內存拷貝就很重要，在這點上，epoll是通過內核於用戶空間mmap同一塊內存實現的。而如果你想我一樣從2.5內核就關註epoll的話，一定不會忘記手工 mmap這一步的。

epoll機理

當某一進程調用epoll_create方法時，Linux內核會創建一個eventpoll結構體，這個結構體中有兩個成員與epoll的使用方式密切相關。eventpoll結構體如下所示：

struct eventpoll{  
    ....  
    /*紅黑樹的根節點，這顆樹中存儲著所有添加到epoll中的需要監控的事件*/  
    struct rb_root  rbr;  
    /*雙鏈表中則存放著將要通過epoll_wait返回給用戶的滿足條件的事件*/  
    struct list_head rdlist;  
    ....  
};  

每一個epoll對象都有一個獨立的eventpoll結構體，用於存放通過epoll_ctl方法向epoll對象中添加進來的事件。這些事件都會掛載在紅黑樹中，如此，重復添加的事件就可以通過紅黑樹而高效的識別出來(紅黑樹的插入時間效率是lgn，其中n為樹的高度)。

而所有添加到epoll中的事件都會與設備(網卡)驅動程序建立回調關系，也就是說，當相應的事件發生時會調用這個回調方法。這個回調方法在內核中叫ep_poll_callback,它會將發生的事件添加到rdlist雙鏈表中。

在epoll中，對於每一個事件，都會建立一個epitem結構體，如下所示：

struct epitem{  
    struct rb_node  rbn;//紅黑樹節點  
    struct list_head    rdllink;//雙向鏈表節點  
    struct epoll_filefd  ffd;  //事件句柄信息  
    struct eventpoll *ep;    //指向其所屬的eventpoll對象  
    struct epoll_event event; //期待發生的事件類型  
}

當調用epoll_wait檢查是否有事件發生時，只需要檢查eventpoll對象中的rdlist雙鏈表中是否有epitem元素即可。如果rdlist不為空，則把發生的事件復制到用戶態，同時將事件數量返回給用戶。

linux epoll總結