同步IO和非同步IO，阻塞IO和非阻塞IO分別是什麼，到底有什麼區別？不同的人在不同的上下文下給出的答案是不同的。
在進行解釋之前，首先要說明幾個概念：- 使用者空間和核心空間- 程式切換- 程式的阻塞- 檔案描述符- 快取 I/O
使用者空間與核心空間
現在作業系統都是採用虛擬儲存器，那麼對32位作業系統而言，它的定址空間（虛擬儲存空間）為4G（2的32次方）。作業系統的核心是核心，獨立於普通的應用程式，可以訪問受保護的記憶體空間，也有訪問底層硬體裝置的所有許可權。為了保證使用者程式不能直接操作核心（kernel），保證核心的安全，操心繫統將虛擬空間劃分為兩部分，一部分為核心空間，一部分為使用者空間。針對linux作業系統而言，將最高的1G位元組（從虛擬地址0xC0000000到0xFFFFFFFF），供核心使用，稱為核心空間，而將較低的3G位元組（從虛擬地址0x00000000到0xBFFFFFFF），供各個程式使用，稱為使用者空間。
程式切換
為了控制程式的執行，核心必須有能力掛起正在CPU上執行的程式，並恢復以前掛起的某個程式的執行。這種行為被稱為程式切換。因此可以說，任何程式都是在作業系統核心的支援下執行的，是與核心緊密相關的。
從一個程式的執行轉到另一個程式上執行，這個過程中經過下面這些變化：1. 儲存處理機上下文，包括程式計數器和其他暫存器。2. 更新PCB資訊。3. 把程式的PCB移入相應的佇列，如就緒、在某事件阻塞等佇列。4. 選擇另一個程式執行，並更新其PCB。5. 更新記憶體管理的資料結構。6. 恢復處理機上下文。
注：總而言之就是很耗資源，具體的可以參考這篇文章：程式切換
程式的阻塞
正在執行的程式，由於期待的某些事件未發生，如請求系統資源失敗、等待某種操作的完成、新資料尚未到達或無新工作做等，則由系統自動執行阻塞原語(Block)，使自己由執行狀態變為阻塞狀態。可見，程式的阻塞是程式自身的一種主動行為，也因此只有處於執行態的程式（獲得CPU），才可能將其轉為阻塞狀態。當程式進入阻塞狀態，是不佔用CPU資源的。
檔案描述符fd
檔案描述符（File descriptor）是電腦科學中的一個術語，是一個用於表述指向檔案的引用的抽象化概念。
檔案描述符在形式上是一個非負整數。實際上，它是一個索引值，指向核心為每一個程式所維護的該程式開啟檔案的記錄表。當程式開啟一個現有檔案或者建立一個新檔案時，核心向程式返回一個檔案描述符。在程式設計中，一些涉及底層的程式編寫往往會圍繞著檔案描述符展開。但是檔案描述符這一概念往往只適用於UNIX、Linux這樣的作業系統。
快取 I/O
快取 I/O 又被稱作標準 I/O，大多數檔案系統的預設 I/O 操作都是快取 I/O。在 Linux 的快取 I/O 機制中，作業系統會將 I/O 的資料快取在檔案系統的頁快取（ page cache ）中，也就是說，資料會先被拷貝到作業系統核心的緩衝區中，然後才會從作業系統核心的緩衝區拷貝到應用程式的地址空間。
快取 I/O 的缺點：資料在傳輸過程中需要在應用程式地址空間和核心進行多次資料拷貝操作，這些資料拷貝操作所帶來的 CPU 以及記憶體開銷是非常大的。
需要C/C++ Linux伺服器架構師學習資料加群812855908（資料包括C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg等），免費分享
剛才說了，對於一次IO訪問（以read舉例），資料會先被拷貝到作業系統核心的緩衝區中，然後才會從作業系統核心的緩衝區拷貝到應用程式的地址空間。所以說，當一個read操作發生時，它會經歷兩個階段：1. 等待資料準備 (Waiting for the data to be ready)2. 將資料從核心拷貝到程式中 (Copying the data from the kernel to the process)
正式因為這兩個階段，linux系統產生了下面五種網路模式的方案。- 阻塞 I/O（blocking IO）- 非阻塞 I/O（nonblocking IO）- I/O 多路複用（ IO multiplexing）- 訊號驅動 I/O（ signal driven IO）- 非同步 I/O（asynchronous IO）
注：由於signal driven IO在實際中並不常用，所以我這隻提及剩下的四種IO Model。
阻塞 I/O（blocking IO）
在linux中，預設情況下所有的socket都是blocking，一個典型的讀操作流程大概是這樣：
當使用者程式呼叫了recvfrom這個系統呼叫，kernel就開始了IO的第一個階段：準備資料（對於網路IO來說，很多時候資料在一開始還沒有到達。比如，還沒有收到一個完整的UDP包。這個時候kernel就要等待足夠的資料到來）。這個過程需要等待，也就是說資料被拷貝到作業系統核心的緩衝區中是需要一個過程的。而在使用者程式這邊，整個程式會被阻塞（當然，是程式自己選擇的阻塞）。當kernel一直等到資料準備好了，它就會將資料從kernel中拷貝到使用者記憶體，然後kernel返回結果，使用者程式才解除block的狀態，重新執行起來。
所以，blocking IO的特點就是在IO執行的兩個階段都被block了。
非阻塞 I/O（nonblocking IO）
linux下，可以通過設定socket使其變為non-blocking。當對一個non-blocking socket執行讀操作時，流程是這個樣子：
當使用者程式發出read操作時，如果kernel中的資料還沒有準備好，那麼它並不會block使用者程式，而是立刻返回一個error。從使用者程式角度講 ，它發起一個read操作後，並不需要等待，而是馬上就得到了一個結果。使用者程式判斷結果是一個error時，它就知道資料還沒有準備好，於是它可以再次傳送read操作。一旦kernel中的資料準備好了，並且又再次收到了使用者程式的system call，那麼它馬上就將資料拷貝到了使用者記憶體，然後返回。
所以，nonblocking IO的特點是使用者程式需要不斷的主動詢問kernel資料好了沒有。
I/O 多路複用（ IO multiplexing）
IO multiplexing就是我們說的select，poll，epoll，有些地方也稱這種IO方式為event driven IO。select/epoll的好處就在於單個process就可以同時處理多個網路連線的IO。它的基本原理就是select，poll，epoll這個function會不斷的輪詢所負責的所有socket，當某個socket有資料到達了，就通知使用者程式。
當使用者程式呼叫了select，那麼整個程式會被block，而同時，kernel會“監視”所有select負責的socket，當任何一個socket中的資料準備好了，select就會返回。這個時候使用者程式再呼叫read操作，將資料從kernel拷貝到使用者程式。
所以，I/O 多路複用的特點是通過一種機制一個程式能同時等待多個檔案描述符，而這些檔案描述符（套接字描述符）其中的任意一個進入讀就緒狀態，select()函式就可以返回。
這個圖和blocking IO的圖其實並沒有太大的不同，事實上，還更差一些。因為這裡需要使用兩個system call (select 和 recvfrom)，而blocking IO只呼叫了一個system call (recvfrom)。但是，用select的優勢在於它可以同時處理多個connection。
所以，如果處理的連線數不是很高的話，使用select/epoll的web server不一定比使用multi-threading + blocking IO的web server效能更好，可能延遲還更大。select/epoll的優勢並不是對於單個連線能處理得更快，而是在於能處理更多的連線。）
在IO multiplexing Model中，實際中，對於每一個socket，一般都設定成為non-blocking，但是，如上圖所示，整個使用者的process其實是一直被block的。只不過process是被select這個函式block，而不是被socket IO給block。
非同步 I/O（asynchronous IO）
inux下的asynchronous IO其實用得很少。先看一下它的流程：
使用者程式發起read操作之後，立刻就可以開始去做其它的事。而另一方面，從kernel的角度，當它受到一個asynchronous read之後，首先它會立刻返回，所以不會對使用者程式產生任何block。然後，kernel會等待資料準備完成，然後將資料拷貝到使用者記憶體，當這一切都完成之後，kernel會給使用者程式傳送一個signal，告訴它read操作完成了。
總結
blocking和non-blocking的區別
呼叫blocking IO會一直block住對應的程式直到操作完成，而non-blocking IO在kernel還準備資料的情況下會立刻返回。
synchronous IO和asynchronous IO的區別
在說明synchronous IO和asynchronous IO的區別之前，需要先給出兩者的定義。POSIX的定義是這樣子的：- A synchronous I/O operation causes the requesting process to be blocked until that I/O operation completes;- An asynchronous I/O operation does not cause the requesting process to be blocked;
兩者的區別就在於synchronous IO做”IO operation”的時候會將process阻塞。按照這個定義，之前所述的blocking IO，non-blocking IO，IO multiplexing都屬於synchronous IO。
有人會說，non-blocking IO並沒有被block啊。這裡有個非常“狡猾”的地方，定義中所指的”IO operation”是指真實的IO操作，就是例子中的recvfrom這個system call。non-blocking IO在執行recvfrom這個system call的時候，如果kernel的資料沒有準備好，這時候不會block程式。但是，當kernel中資料準備好的時候，recvfrom會將資料從kernel拷貝到使用者記憶體中，這個時候程式是被block了，在這段時間內，程式是被block的。
而asynchronous IO則不一樣，當程式發起IO 操作之後，就直接返回再也不理睬了，直到kernel傳送一個訊號，告訴程式說IO完成。在這整個過程中，程式完全沒有被block。
各個IO Model的比較如圖所示：
通過上面的圖片，可以發現non-blocking IO和asynchronous IO的區別還是很明顯的。在non-blocking IO中，雖然程式大部分時間都不會被block，但是它仍然要求程式去主動的check，並且當資料準備完成以後，也需要程式主動的再次呼叫recvfrom來將資料拷貝到使用者記憶體。而asynchronous IO則完全不同。它就像是使用者程式將整個IO操作交給了他人（kernel）完成，然後他人做完後發訊號通知。在此期間，使用者程式不需要去檢查IO操作的狀態，也不需要主動的去拷貝資料。
select，poll，epoll都是IO多路複用的機制。I/O多路複用就是通過一種機制，一個程式可以監視多個描述符，一旦某個描述符就緒（一般是讀就緒或者寫就緒），能夠通知程式進行相應的讀寫操作。但select，poll，epoll本質上都是同步I/O，因為他們都需要在讀寫事件就緒後自己負責進行讀寫，也就是說這個讀寫過程是阻塞的，而非同步I/O則無需自己負責進行讀寫，非同步I/O的實現會負責把資料從核心拷貝到使用者空間。（這裡囉嗦下）
select
int select (int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
select 函式監視的檔案描述符分3類，分別是writefds、readfds、和exceptfds。呼叫後select函式會阻塞，直到有描述副就緒（有資料 可讀、可寫、或者有except），或者超時（timeout指定等待時間，如果立即返回設為null即可），函式返回。當select函式返回後，可以 通過遍歷fdset，來找到就緒的描述符。
select目前幾乎在所有的平臺上支援，其良好跨平臺支援也是它的一個優點。select的一 個缺點在於單個程式能夠監視的檔案描述符的數量存在最大限制，在Linux上一般為1024，可以通過修改巨集定義甚至重新編譯核心的方式提升這一限制，但 是這樣也會造成效率的降低。
poll
int poll (struct pollfd *fds, unsigned int nfds, int timeout);
不同與select使用三個點陣圖來表示三個fdset的方式，poll使用一個 pollfd的指標實現。
struct pollfd {
int fd; /* file descriptor */
short events; /* requested events to watch */
short revents; /* returned events witnessed */
};
pollfd結構包含了要監視的event和發生的event，不再使用select“引數-值”傳遞的方式。同時，pollfd並沒有最大數量限制（但是數量過大後效能也是會下降）。 和select函式一樣，poll返回後，需要輪詢pollfd來獲取就緒的描述符。
從上面看，select和poll都需要在返回後，通過遍歷檔案描述符來獲取已經就緒的socket。事實上，同時連線的大量客戶端在一時刻可能只有很少的處於就緒狀態，因此隨著監視的描述符數量的增長，其效率也會線性下降。
epoll
epoll是在2.6核心中提出的，是之前的select和poll的增強版本。相對於select和poll來說，epoll更加靈活，沒有描述符限制。epoll使用一個檔案描述符管理多個描述符，將使用者關係的檔案描述符的事件存放到核心的一個事件表中，這樣在使用者空間和核心空間的copy只需一次。
一 epoll操作過程
epoll操作過程需要三個介面，分別如下：
int epoll_create(int size)；//建立一個epoll的控制程式碼，size用來告訴核心這個監聽的數目一共有多大
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；
int epoll_wait(int epfd, struct epoll_event * events, int maxevents, int timeout);
1. int epoll_create(int size);建立一個epoll的控制程式碼，size用來告訴核心這個監聽的數目一共有多大，這個引數不同於select()中的第一個引數，給出最大監聽的fd+1的值，引數size並不是限制了epoll所能監聽的描述符最大個數，只是對核心初始分配內部資料結構的一個建議。當建立好epoll控制程式碼後，它就會佔用一個fd值，在linux下如果檢視/proc/程式id/fd/，是能夠看到這個fd的，所以在使用完epoll後，必須呼叫close()關閉，否則可能導致fd被耗盡。
2. int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)；函式是對指定描述符fd執行op操作。- epfd：是epoll_create()的返回值。- op：表示op操作，用三個巨集來表示：新增EPOLL_CTL_ADD，刪除EPOLL_CTL_DEL，修改EPOLL_CTL_MOD。分別新增、刪除和修改對fd的監聽事件。- fd：是需要監聽的fd（檔案描述符）- epoll_event：是告訴核心需要監聽什麼事，struct epoll_event結構如下：
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);等待epfd上的io事件，最多返回maxevents個事件。引數events用來從核心得到事件的集合，maxevents告之核心這個events有多大，這個maxevents的值不能大於建立epoll_create()時的size，引數timeout是超時時間（毫秒，0會立即返回，-1將不確定，也有說法說是永久阻塞）。該函式返回需要處理的事件數目，如返回0表示已超時。
二 工作模式
epoll對檔案描述符的操作有兩種模式：LT（level trigger）和ET（edge trigger）。LT模式是預設模式，LT模式與ET模式的區別如下： LT模式：當epoll_wait檢測到描述符事件發生並將此事件通知應用程式，應用程式可以不立即處理該事件。下次呼叫epoll_wait時，會再次響應應用程式並通知此事件。 ET模式：當epoll_wait檢測到描述符事件發生並將此事件通知應用程式，應用程式必須立即處理該事件。如果不處理，下次呼叫epoll_wait時，不會再次響應應用程式並通知此事件。
1. LT模式
LT(level triggered)是預設的工作方式，並且同時支援block和no-block socket.在這種做法中，核心告訴你一個檔案描述符是否就緒了，然後你可以對這個就緒的fd進行IO操作。如果你不作任何操作，核心還是會繼續通知你的。
2. ET模式
ET(edge-triggered)是高速工作方式，只支援no-block socket。在這種模式下，當描述符從未就緒變為就緒時，核心通過epoll告訴你。然後它會假設你知道檔案描述符已經就緒，並且不會再為那個檔案描述符傳送更多的就緒通知，直到你做了某些操作導致那個檔案描述符不再為就緒狀態了(比如，你在傳送，接收或者接收請求，或者傳送接收的資料少於一定量時導致了一個EWOULDBLOCK 錯誤）。但是請注意，如果一直不對這個fd作IO操作(從而導致它再次變成未就緒)，核心不會傳送更多的通知(only once)
ET模式在很大程度上減少了epoll事件被重複觸發的次數，因此效率要比LT模式高。epoll工作在ET模式的時候，必須使用非阻塞套介面，以避免由於一個檔案控制程式碼的阻塞讀/阻塞寫操作把處理多個檔案描述符的任務餓死。
3. 總結
假如有這樣一個例子：1. 我們已經把一個用來從管道中讀取資料的檔案控制程式碼(RFD)新增到epoll描述符2. 這個時候從管道的另一端被寫入了2KB的資料3. 呼叫epoll_wait(2)，並且它會返回RFD，說明它已經準備好讀取操作4. 然後我們讀取了1KB的資料5. 呼叫epoll_wait(2)……
LT模式：如果是LT模式，那麼在第5步呼叫epoll_wait(2)之後，仍然能受到通知。
ET模式：如果我們在第1步將RFD新增到epoll描述符的時候使用了EPOLLET標誌，那麼在第5步呼叫epoll_wait(2)之後將有可能會掛起，因為剩餘的資料還存在於檔案的輸入緩衝區內，而且資料發出端還在等待一個針對已經發出資料的反饋資訊。只有在監視的檔案控制程式碼上發生了某個事件的時候 ET 工作模式才會彙報事件。因此在第5步的時候，呼叫者可能會放棄等待仍在存在於檔案輸入緩衝區內的剩餘資料。
當使用epoll的ET模型來工作時，當產生了一個EPOLLIN事件後，讀資料的時候需要考慮的是當recv()返回的大小如果等於請求的大小，那麼很有可能是緩衝區還有資料未讀完，也意味著該次事件還沒有處理完，所以還需要再次讀取：
while(rs){
buflen = recv(activeevents[i].data.fd, buf, sizeof(buf), 0);
if(buflen < 0){
// 由於是非阻塞的模式,所以當errno為EAGAIN時,表示當前緩衝區已無資料可讀
// 在這裡就當作是該次事件已處理處.
if(errno == EAGAIN){
break;
}
else{
return;
}
}
else if(buflen == 0){
// 這裡表示對端的socket已正常關閉.
}
if(buflen == sizeof(buf){
rs = 1; // 需要再次讀取
}
else{
rs = 0;
}
}
Linux中的EAGAIN含義
Linux環境下開發經常會碰到很多錯誤(設定errno)，其中EAGAIN是其中比較常見的一個錯誤(比如用在非阻塞操作中)。從字面上來看，是提示再試一次。這個錯誤經常出現在當應用程式進行一些非阻塞(non-blocking)操作(對檔案或socket)的時候。
例如，以 O_NONBLOCK的標誌開啟檔案/socket/FIFO，如果你連續做read操作而沒有資料可讀。此時程式不會阻塞起來等待資料準備就緒返回，read函式會返回一個錯誤EAGAIN，提示你的應用程式現在沒有資料可讀請稍後再試。又例如，當一個系統呼叫(比如fork)因為沒有足夠的資源(比如虛擬記憶體)而執行失敗，返回EAGAIN提示其再呼叫一次(也許下次就能成功)。
三 程式碼演示
下面是一段不完整的程式碼且格式不對，意在表述上面的過程，去掉了一些模板程式碼。
#define IPADDRESS "127.0.0.1"
#define PORT 8787
#define MAXSIZE 1024
#define LISTENQ 5
#define FDSIZE 1000
#define EPOLLEVENTS 100
listenfd = socket_bind(IPADDRESS,PORT);
struct epoll_event events[EPOLLEVENTS];
//建立一個描述符
epollfd = epoll_create(FDSIZE);
//新增監聽描述符事件
add_event(epollfd,listenfd,EPOLLIN);
//迴圈等待
for ( ; ; ){
//該函式返回已經準備好的描述符事件數目
ret = epoll_wait(epollfd,events,EPOLLEVENTS,-1);
//處理接收到的連線
handle_events(epollfd,events,ret,listenfd,buf);
}
//事件處理函式
static void handle_events(int epollfd,struct epoll_event *events,int num,int listenfd,char *buf)
{
int i;
int fd;
//進行遍歷;這裡只要遍歷已經準備好的io事件。num並不是當初epoll_create時的FDSIZE。
for (i = 0;i < num;i++)
{
fd = events[i].data.fd;
//根據描述符的型別和事件型別進行處理
if ((fd == listenfd) &&(events[i].events & EPOLLIN))
handle_accpet(epollfd,listenfd);
else if (events[i].events & EPOLLIN)
do_read(epollfd,fd,buf);
else if (events[i].events & EPOLLOUT)
do_write(epollfd,fd,buf);
}
}
//新增事件
static void add_event(int epollfd,int fd,int state){
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_ADD,fd,&ev);
}
//處理接收到的連線
static void handle_accpet(int epollfd,int listenfd){
int clifd;
struct sockaddr_in cliaddr;
socklen_t cliaddrlen;
clifd = accept(listenfd,(struct sockaddr*)&cliaddr,&cliaddrlen);
if (clifd == -1)
perror("accpet error:");
else {
printf("accept a new client: %s:%d\n",inet_ntoa(cliaddr.sin_addr),cliaddr.sin_port); //新增一個客戶描述符和事件
add_event(epollfd,clifd,EPOLLIN);
}
}
//讀處理
static void do_read(int epollfd,int fd,char *buf){
int nread;
nread = read(fd,buf,MAXSIZE);
if (nread == -1) {
perror("read error:");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLIN); //刪除監聽
}
else if (nread == 0) {
fprintf(stderr,"client close.\n");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLIN); //刪除監聽
}
else {
printf("read message is : %s",buf);
//修改描述符對應的事件，由讀改為寫
modify_event(epollfd,fd,EPOLLOUT);
}
}
//寫處理
static void do_write(int epollfd,int fd,char *buf) {
int nwrite;
nwrite = write(fd,buf,strlen(buf));
if (nwrite == -1){
perror("write error:");
close(fd); //記住close fd
delete_event(epollfd,fd,EPOLLOUT); //刪除監聽
}else{
modify_event(epollfd,fd,EPOLLIN);
}
memset(buf,0,MAXSIZE);
}
//刪除事件
static void delete_event(int epollfd,int fd,int state) {
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_DEL,fd,&ev);
}
//修改事件
static void modify_event(int epollfd,int fd,int state){
struct epoll_event ev;
ev.events = state;
ev.data.fd = fd;
epoll_ctl(epollfd,EPOLL_CTL_MOD,fd,&ev);
}
//注：另外一端我就省了
四 epoll總結
在 select/poll中，程式只有在呼叫一定的方法後，核心才對所有監視的檔案描述符進行掃描，而epoll事先通過epoll_ctl()來註冊一 個檔案描述符，一旦基於某個檔案描述符就緒時，核心會採用類似callback的回撥機制，迅速啟用這個檔案描述符，當程式呼叫epoll_wait() 時便得到通知。(此處去掉了遍歷檔案描述符，而是通過監聽回撥的的機制。這正是epoll的魅力所在。)
epoll的優點主要是以下個方面：1. 監視的描述符數量不受限制，它所支援的FD上限是最大可以開啟檔案的數目，這個數字一般遠大於2048,舉個例子,在1GB記憶體的機器上大約是10萬左 右，具體數目可以cat /proc/sys/fs/file-max檢視,一般來說這個數目和系統記憶體關係很大。select的最大缺點就是程式開啟的fd是有數量限制的。這對 於連線數量比較大的伺服器來說根本不能滿足。雖然也可以選擇多程式的解決方案( Apache就是這樣實現的)，不過雖然linux上面建立程式的代價比較小，但仍舊是不可忽視的，加上程式間資料同步遠比不上執行緒間同步的高效，所以也不是一種完美的方案。
- IO的效率不會隨著監視fd的數量的增長而下降。epoll不同於select和poll輪詢的方式，而是通過每個fd定義的回撥函式來實現的。只有就緒的fd才會執行回撥函式。
如果沒有大量的idle -connection或者dead-connection，epoll的效率並不會比select/poll高很多，但是當遇到大量的idle- connection，就會發現epoll的效率大大高於select/poll。
本作品採用《CC 協議》，轉載必須註明作者和本文連結