socket阻塞與非阻塞，同步與異步

1. 概念理解

在進行網(wǎng)絡編程時，我們常常見到同步(Sync)/異步(Async)，阻塞(Block)/非阻塞(Unblock)四種調(diào)用方式：

同步/異步主要針對C端:

同步：

所謂同步，就是在c端發(fā)出一個功能調(diào)用時，在沒有得到結(jié)果之前，該調(diào)用就不返回。也就是必須一件一件事做,等前一件做完了才能做下一件事。

例如普通B/S模式（同步）：提交請求->等待服務器處理->處理完畢返回 這個期間客戶端瀏覽器不能干任何事

異步：

異步的概念和同步相對。當c端一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實際處理這個調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者。

例如 ajax請求（異步）: 請求通過事件觸發(fā)->服務器處理（這是瀏覽器仍然可以作其他事情）->處理完畢

阻塞/非阻塞主要針對S端:

阻塞

阻塞調(diào)用是指調(diào)用結(jié)果返回之前，當前線程會被掛起（線程進入非可執(zhí)行狀態(tài)，在這個狀態(tài)下，cpu不會給線程分配時間片，即線程暫停運行）。函數(shù)只有在得到結(jié)果之后才會返回。

有人也許會把阻塞調(diào)用和同步調(diào)用等同起來，實際上他是不同的。對于同步調(diào)用來說，很多時候當前線程還是激活的，只是從邏輯上當前函數(shù)沒有返回而已。 例如，我們在socket中調(diào)用recv函數(shù)，如果緩沖區(qū)中沒有數(shù)據(jù)，這個函數(shù)就會一直等待，直到有數(shù)據(jù)才返回。而此時，當前線程還會繼續(xù)處理各種各樣的消息。

快遞的例子：比如到你某個時候到A樓一層（假如是內(nèi)核緩沖區(qū)）取快遞，但是你不知道快遞什么時候過來，你又不能干別的事，只能死等著。但你可以睡覺（進程處于休眠狀態(tài)），因為你知道快遞把貨送來時一定會給你打個電話（假定一定能叫醒你）。

非阻塞

非阻塞和阻塞的概念相對應，指在不能立刻得到結(jié)果之前，該函數(shù)不會阻塞當前線程，而會立刻返回。

還是等快遞的例子：如果用忙輪詢的方法，每隔5分鐘到A樓一層(內(nèi)核緩沖區(qū)）去看快遞來了沒有。如果沒來，立即返回。而快遞來了，就放在A樓一層，等你去取。

對象的阻塞模式和阻塞函數(shù)調(diào)用

對象是否處于阻塞模式和函數(shù)是不是阻塞調(diào)用有很強的相關性，但是并不是一一對應的。阻塞對象上可以有非阻塞的調(diào)用方式，我們可以通過一定的API去輪詢狀 態(tài)，在適當?shù)臅r候調(diào)用阻塞函數(shù)，就可以避免阻塞。而對于非阻塞對象，調(diào)用特殊的函數(shù)也可以進入阻塞調(diào)用。函數(shù)select就是這樣的一個例子。

1. 同步，就是我客戶端（c端調(diào)用者）調(diào)用一個功能，該功能沒有結(jié)束前，我（c端調(diào)用者）死等結(jié)果。

2. 異步，就是我（c端調(diào)用者）調(diào)用一個功能，不需要知道該功能結(jié)果，該功能有結(jié)果后通知我（c端調(diào)用者）即回調(diào)通知。

同步/異步主要針對C端, 但是跟S端不是完全沒有關系，同步/異步機制必須S端配合才能實現(xiàn).同步/異步是由c端自己控制,但是S端是否阻塞/非阻塞,C端完全不需要關心.

3. 阻塞，就是調(diào)用我（s端被調(diào)用者，函數(shù)），我（s端被調(diào)用者，函數(shù)）沒有接收完數(shù)據(jù)或者沒有得到結(jié)果之前，我不會返回。

4. 非阻塞，就是調(diào)用我（s端被調(diào)用者，函數(shù)），我（s端被調(diào)用者，函數(shù)）立即返回，通過select通知調(diào)用者

同步IO和異步IO的區(qū)別就在于：數(shù)據(jù)訪問的時候進程是否阻塞！

阻塞IO和非阻塞IO的區(qū)別就在于：應用程序的調(diào)用是否立即返回！

同步和異步都只針對于本機SOCKET而言的。

同步和異步,阻塞和非阻塞,有些混用,其實它們完全不是一回事,而且它們修飾的對象也不相同。

阻塞和非阻塞是指當server端的進程訪問的數(shù)據(jù)如果尚未就緒,進程是否需要等待,簡單說這相當于函數(shù)內(nèi)部的實現(xiàn)區(qū)別,也就是未就緒時是直接返回還是等待就緒;

而同步和異步是指client端訪問數(shù)據(jù)的機制,同步一般指主動請求并等待I/O操作完畢的方式,當數(shù)據(jù)就緒后在讀寫的時候必須阻塞(區(qū)別就緒與讀寫二個階段,同步的讀寫必須阻塞),異步則指主動請求數(shù)據(jù)后便可以繼續(xù)處理其它任務,隨后等待I/O,操作完畢的通知,這可以使進程在數(shù)據(jù)讀寫時也不阻塞。(等待"通知")

Node.js里面的描述：

線程在執(zhí)行中如果遇到磁盤讀寫或網(wǎng)絡通信（統(tǒng)稱為I/O 操作），通常要耗費較長的時間，這時操作系統(tǒng)會剝奪這個線程的CPU 控制權(quán)，使其暫停執(zhí)行，同時將資源讓給其他的工作線程，這種線程調(diào)度方式稱為 阻塞。當I/O 操作完畢時，操作系統(tǒng)將這個線程的阻塞狀態(tài)解除，恢復其對CPU的控制權(quán)，令其繼續(xù)執(zhí)行。這種I/O 模式就是通常的同步式I/O（Synchronous I/O）或阻塞式I/O （Blocking I/O）。  

相應地，異步式I/O （Asynchronous I/O）或非阻塞式I/O （Non-blocking I/O）則針對所有I/O 操作不采用阻塞的策略。當線程遇到I/O 操作時，不會以阻塞的方式等待I/O 操作的完成或數(shù)據(jù)的返回，而只是將I/O 請求發(fā)送給操作系統(tǒng)，繼續(xù)執(zhí)行下一條語句。當操作系統(tǒng)完成I/O 操作時，以事件的形式通知執(zhí)行I/O 操作的線程，線程會在特定時候處理這個事件。為了處理異步I/O，線程必須有事件循環(huán)，不斷地檢查有沒有未處理的事件，依次予以處理。阻塞模式下，一個線程只能處理一項任務，要想提高吞吐量必須通過多線程。而非阻塞模式下，一個線程永遠在執(zhí)行計算操作，<span style="color:#ff0000;">這個線程所使用的CPU 核心利用率永遠是100%</span>，I/O 以事件的方式通知。<span style="color:#ff0000;">在阻塞模式下，多線程往往能提高系統(tǒng)吞吐量，因為一個線程阻塞時還有其他線程在工作，多線程可以讓CPU 資源不被阻塞中的線程浪費。</span>而在非阻塞模式下，線程不會被I/O 阻塞，永遠在利用CPU。多線程帶來的好處僅僅是在多核CPU 的情況下利用更多的核，而Node.js的單線程也能帶來同樣的好處。這就是為什么Node.js 使用了單線程、非阻塞的事件編程模式。 

2. Linux下的五種I/O模型
1)阻塞I/O（blocking I/O）

2)非阻塞I/O （nonblocking I/O）

3) I/O復用(select 和poll) （I/O multiplexing）

4)信號驅(qū)動I/O （signal driven I/O (SIGIO)）

5)異步I/O （asynchronous I/O (the POSIX aio_functions)）

前四種都是同步，只有最后一種才是異步IO。

阻塞I/O模型：

簡介：進程會一直阻塞，直到數(shù)據(jù)拷貝完成

應用程序調(diào)用一個IO函數(shù)，導致應用程序阻塞，等待數(shù)據(jù)準備好。 如果數(shù)據(jù)沒有準備好，一直等待….數(shù)據(jù)準備好了，從內(nèi)核拷貝到用戶空間,IO函數(shù)返回成功指示。

我們 第一次接觸到的網(wǎng)絡編程都是從 listen()、send()、recv()等接口開始的。使用這些接口可以很方便的構(gòu)建服務器 /客戶機的模型。

阻塞I/O模型圖：在調(diào)用recv()/recvfrom（）函數(shù)時，發(fā)生在內(nèi)核中等待數(shù)據(jù)和復制數(shù)據(jù)的過程。

當調(diào)用recv()函數(shù)時，系統(tǒng)首先查是否有準備好的數(shù)據(jù)。如果數(shù)據(jù)沒有準備好，那么系統(tǒng)就處于等待狀態(tài)。當數(shù)據(jù)準備好后，將數(shù)據(jù)從系統(tǒng)緩沖區(qū)復制到用戶空間，然后該函數(shù)返回。在套接應用程序中，當調(diào)用recv()函數(shù)時，未必用戶空間就已經(jīng)存在數(shù)據(jù)，那么此時recv()函數(shù)就會處于等待狀態(tài)。

當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時，默認的套接字都是阻塞的。這意味著當調(diào)用Windows Sockets API不能立即完成時，線程處于等待狀態(tài)，直到操作完成。

并不是所有Windows Sockets API以阻塞套接字為參數(shù)調(diào)用都會發(fā)生阻塞。例如，以阻塞模式的套接字為參數(shù)調(diào)用bind()、listen()函數(shù)時，函數(shù)會立即返回。將可能阻塞套接字的Windows Sockets API調(diào)用分為以下四種:

1．輸入操作： recv()、recvfrom()、WSARecv()和WSARecvfrom()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)接收數(shù)據(jù)。如果此時套接字緩沖區(qū)內(nèi)沒有數(shù)據(jù)可讀，則調(diào)用線程在數(shù)據(jù)到來前一直睡眠。

2．輸出操作： send()、sendto()、WSASend()和WSASendto()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)發(fā)送數(shù)據(jù)。如果套接字緩沖區(qū)沒有可用空間，線程會一直睡眠，直到有空間。

3．接受連接：accept()和WSAAcept()函數(shù)。以阻塞套接字為參數(shù)調(diào)用該函數(shù)，等待接受對方的連接請求。如果此時沒有連接請求，線程就會進入睡眠狀態(tài)。

4．外出連接：connect()和WSAConnect()函數(shù)。對于TCP連接，客戶端以阻塞套接字為參數(shù)，調(diào)用該函數(shù)向服務器發(fā)起連接。該函數(shù)在收到服務器的應答前，不會返回。這意味著TCP連接總會等待至少到服務器的一次往返時間。

使用阻塞模式的套接字，開發(fā)網(wǎng)絡程序比較簡單，容易實現(xiàn)。當希望能夠立即發(fā)送和接收數(shù)據(jù)，且處理的套接字數(shù)量比較少的情況下，使用阻塞模式來開發(fā)網(wǎng)絡程序比較合適。

阻塞模式套接字的不足表現(xiàn)為，在大量建立好的套接字線程之間進行通信時比較困難。當使用“生產(chǎn)者-消費者”模型開發(fā)網(wǎng)絡程序時，為每個套接字都分別分配一個讀線程、一個處理數(shù)據(jù)線程和一個用于同步的事件，那么這樣無疑加大系統(tǒng)的開銷。其最大的缺點是當希望同時處理大量套接字時，將無從下手，其擴展性很差.

阻塞模式給網(wǎng)絡編程帶來了一個很大的問題，如在調(diào)用 send()的同時，線程將被阻塞，在此期間，線程將無法執(zhí)行任何運算或響應任何的網(wǎng)絡請求。這給多客戶機、多業(yè)務邏輯的網(wǎng)絡編程帶來了挑戰(zhàn)。這時，我們可能會選擇多線程的方式來解決這個問題。

應對多客戶機的網(wǎng)絡應用，最簡單的解決方式是在服務器端使用多線程（或多進程）。多線程（或多進程）的目的是讓每個連接都擁有獨立的線程（或進程），這樣任何一個連接的阻塞都不會影響其他的連接。

具體使用多進程還是多線程，并沒有一個特定的模式。傳統(tǒng)意義上，進程的開銷要遠遠大于線程，所以，如果需要同時為較多的客戶機提供服務，則不推薦使用多進程；如果單個服務執(zhí)行體需要消耗較多的 CPU 資源，譬如需要進行大規(guī)模或長時間的數(shù)據(jù)運算或文件訪問，則進程較為安全。通常，使用 pthread_create () 創(chuàng)建新線程，fork() 創(chuàng)建新進程。

多線程/進程服務器同時為多個客戶機提供應答服務。模型如下：

主線程持續(xù)等待客戶端的連接請求，如果有連接，則創(chuàng)建新線程，并在新線程中提供為前例同樣的問答服務。

上述多線程的服務器模型似乎完美的解決了為多個客戶機提供問答服務的要求，但其實并不盡然。如果要同時響應成百上千路的連接請求，則無論多線程還是多進程都會嚴重占據(jù)系統(tǒng)資源，降低系統(tǒng)對外界響應效率，而線程與進程本身也更容易進入假死狀態(tài)。

由此可能會考慮使用“線程池”或“連接池”?！熬€程池”旨在減少創(chuàng)建和銷毀線程的頻率，其維持一定合理數(shù)量的線程，并讓空閑的線程重新承擔新的執(zhí)行任務?！斑B接池”維持連接的緩存池，盡量重用已有的連接、減少創(chuàng)建和關閉連接的頻率。這兩種技術都可以很好的降低系統(tǒng)開銷，都被廣泛應用很多大型系統(tǒng)，如apache，MySQL數(shù)據(jù)庫等。

但是，“線程池”和“連接池”技術也只是在一定程度上緩解了頻繁調(diào)用 IO 接口帶來的資源占用。而且，所謂“池”始終有其上限，當請求大大超過上限時，“池”構(gòu)成的系統(tǒng)對外界的響應并不比沒有池的時候效果好多少。所以使用“池”必須考慮其面臨的響應規(guī)模，并根據(jù)響應規(guī)模調(diào)整“池”的大小。

對應上例中的所面臨的可能同時出現(xiàn)的上千甚至上萬次的客戶端請求，“線程池”或“連接池”或許可以緩解部分壓力，但是不能解決所有問題。

非阻塞IO模型 ：

簡介：非阻塞IO通過進程反復調(diào)用IO函數(shù)（多次系統(tǒng)調(diào)用，并馬上返回）；在數(shù)據(jù)拷貝的過程中，進程是阻塞的；      

我們把一個SOCKET接口設置為非阻塞就是告訴內(nèi)核，當所請求的I/O操作無法完成時，不要將進程睡眠，而是返回一個錯誤。這樣我們的I/O操作函數(shù)將不斷的測試數(shù)據(jù)是否已經(jīng)準備好，如果沒有準備好，繼續(xù)測試，直到數(shù)據(jù)準備好為止。在這個不斷測試的過程中，會大量的占用CPU的時間。

把SOCKET設置為非阻塞模式，即通知系統(tǒng)內(nèi)核：在調(diào)用Windows Sockets API時，不要讓線程睡眠，而應該讓函數(shù)立即返回。在返回時，該函數(shù)返回一個錯誤代碼。圖所示，一個非阻塞模式套接字多次調(diào)用recv()函數(shù)的過程。前三次調(diào)用recv()函數(shù)時，內(nèi)核數(shù)據(jù)還沒有準備好。因此，該函數(shù)立即返回WSAEWOULDBLOCK錯誤代碼。第四次調(diào)用recv()函數(shù)時，數(shù)據(jù)已經(jīng)準備好，被復制到應用程序的緩沖區(qū)中，recv()函數(shù)返回成功指示，應用程序開始處理數(shù)據(jù)。

當使用socket()函數(shù)和WSASocket()函數(shù)創(chuàng)建套接字時，默認都是阻塞的。在創(chuàng)建套接字之后，通過調(diào)用ioctlsocket()函數(shù)，將該套接字設置為非阻塞模式。Linux下的函數(shù)是:fcntl().
    套接字設置為非阻塞模式后，在調(diào)用Windows Sockets API函數(shù)時，調(diào)用函數(shù)會立即返回。大多數(shù)情況下，這些函數(shù)調(diào)用都會調(diào)用“失敗”，并返回WSAEWOULDBLOCK錯誤代碼。說明請求的操作在調(diào)用期間內(nèi)沒有時間完成。通常，應用程序需要重復調(diào)用該函數(shù)，直到獲得成功返回代碼。

需要說明的是并非所有的Windows Sockets API在非阻塞模式下調(diào)用，都會返回WSAEWOULDBLOCK錯誤。例如，以非阻塞模式的套接字為參數(shù)調(diào)用bind()函數(shù)時，就不會返回該錯誤代碼。當然，在調(diào)用WSAStartup()函數(shù)時更不會返回該錯誤代碼，因為該函數(shù)是應用程序第一調(diào)用的函數(shù)，當然不會返回這樣的錯誤代碼。

 要將套接字設置為非阻塞模式，除了使用ioctlsocket()函數(shù)之外，還可以使用WSAAsyncselect()和WSAEventselect()函數(shù)。當調(diào)用該函數(shù)時，套接字會自動地設置為非阻塞方式。

由于使用非阻塞套接字在調(diào)用函數(shù)時，會經(jīng)常返回WSAEWOULDBLOCK錯誤。所以在任何時候，都應仔細檢查返回代碼并作好對“失敗”的準備。應用程序連續(xù)不斷地調(diào)用這個函數(shù)，直到它返回成功指示為止。上面的程序清單中，在While循環(huán)體內(nèi)不斷地調(diào)用recv()函數(shù)，以讀入1024個字節(jié)的數(shù)據(jù)。這種做法很浪費系統(tǒng)資源。

要完成這樣的操作，有人使用MSG_PEEK標志調(diào)用recv()函數(shù)查看緩沖區(qū)中是否有數(shù)據(jù)可讀。同樣，這種方法也不好。因為該做法對系統(tǒng)造成的開銷是很大的，并且應用程序至少要調(diào)用recv()函數(shù)兩次，才能實際地讀入數(shù)據(jù)。較好的做法是，使用套接字的“I/O模型”來判斷非阻塞套接字是否可讀可寫。

非阻塞模式套接字與阻塞模式套接字相比，不容易使用。使用非阻塞模式套接字，需要編寫更多的代碼，以便在每個Windows Sockets API函數(shù)調(diào)用中，對收到的WSAEWOULDBLOCK錯誤進行處理。因此，非阻塞套接字便顯得有些難于使用。

但是，非阻塞套接字在控制建立的多個連接，在數(shù)據(jù)的收發(fā)量不均，時間不定時，明顯具有優(yōu)勢。這種套接字在使用上存在一定難度，但只要排除了這些困難，它在功能上還是非常強大的。通常情況下，可考慮使用套接字的“I/O模型”，它有助于應用程序通過異步方式，同時對一個或多個套接字的通信加以管理。

IO復用模型：

簡介：主要是select和epoll；對一個IO端口，兩次調(diào)用，兩次返回，比阻塞IO并沒有什么優(yōu)越性；關鍵是能實現(xiàn)同時對多個IO端口進行監(jiān)聽；

I/O復用模型會用到select、poll、epoll函數(shù)，這幾個函數(shù)也會使進程阻塞，但是和阻塞I/O所不同的的，這兩個函數(shù)可以同時阻塞多個I/O操作。而且可以同時對多個讀操作，多個寫操作的I/O函數(shù)進行檢測，直到有數(shù)據(jù)可讀或可寫時，才真正調(diào)用I/O操作函數(shù)。

信號驅(qū)動IO

簡介：兩次調(diào)用，兩次返回；

首先我們允許套接口進行信號驅(qū)動I/O,并安裝一個信號處理函數(shù)，進程繼續(xù)運行并不阻塞。當數(shù)據(jù)準備好時，進程會收到一個SIGIO信號，可以在信號處理函數(shù)中調(diào)用I/O操作函數(shù)處理數(shù)據(jù)。

異步IO模型

簡介：數(shù)據(jù)拷貝的時候進程無需阻塞。

當一個異步過程調(diào)用發(fā)出后，調(diào)用者不能立刻得到結(jié)果。實際處理這個調(diào)用的部件在完成后，通過狀態(tài)、通知和回調(diào)來通知調(diào)用者的輸入輸出操作

同步IO引起進程阻塞，直至IO操作完成。

異步IO不會引起進程阻塞。

IO復用是先通過select調(diào)用阻塞。

5個I/O模型的比較：

3. select、poll、epoll簡介

epoll跟select都能提供多路I/O復用的解決方案。在現(xiàn)在的Linux內(nèi)核里有都能夠支持，其中epoll是Linux所特有，而select則應該是POSIX所規(guī)定，一般操作系統(tǒng)均有實現(xiàn)

select：

select本質(zhì)上是通過設置或者檢查存放fd標志位的數(shù)據(jù)結(jié)構(gòu)來進行下一步處理。這樣所帶來的缺點是：

1、 單個進程可監(jiān)視的fd數(shù)量被限制，即能監(jiān)聽端口的大小有限。

一般來說這個數(shù)目和系統(tǒng)內(nèi)存關系很大，具體數(shù)目可以cat /proc/sys/fs/file-max察看。32位機默認是1024個。64位機默認是2048.

2、 對socket進行掃描時是線性掃描，即采用輪詢的方法，效率較低：

當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調(diào)度,不管哪個Socket是活躍的,都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調(diào)函數(shù)，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll與kqueue做的。

3、需要維護一個用來存放大量fd的數(shù)據(jù)結(jié)構(gòu)，這樣會使得用戶空間和內(nèi)核空間在傳遞該結(jié)構(gòu)時復制開銷大

poll：

poll本質(zhì)上和select沒有區(qū)別，它將用戶傳入的數(shù)組拷貝到內(nèi)核空間，然后查詢每個fd對應的設備狀態(tài)，如果設備就緒則在設備等待隊列中加入一項并繼續(xù)遍歷，如果遍歷完所有fd后沒有發(fā)現(xiàn)就緒設備，則掛起當前進程，直到設備就緒或者主動超時，被喚醒后它又要再次遍歷fd。這個過程經(jīng)歷了多次無謂的遍歷。

它沒有最大連接數(shù)的限制，原因是它是基于鏈表來存儲的，但是同樣有一個缺點：

1、大量的fd的數(shù)組被整體復制于用戶態(tài)和內(nèi)核地址空間之間，而不管這樣的復制是不是有意義。                                                                                                                                      2、poll還有一個特點是“水平觸發(fā)”，如果報告了fd后，沒有被處理，那么下次poll時會再次報告該fd。

epoll:

epoll支持水平觸發(fā)和邊緣觸發(fā)，最大的特點在于邊緣觸發(fā)，它只告訴進程哪些fd剛剛變?yōu)榫托钁B(tài)，并且只會通知一次。還有一個特點是，epoll使用“事件”的就緒通知方式，通過epoll_ctl注冊fd，一旦該fd就緒，內(nèi)核就會采用類似callback的回調(diào)機制來激活該fd，epoll_wait便可以收到通知

epoll的優(yōu)點：

1、沒有最大并發(fā)連接的限制，能打開的FD的上限遠大于1024（1G的內(nèi)存上能監(jiān)聽約10萬個端口）；

2、效率提升，不是輪詢的方式，不會隨著FD數(shù)目的增加效率下降。只有活躍可用的FD才會調(diào)用callback函數(shù)；
      即Epoll最大的優(yōu)點就在于它只管你“活躍”的連接，而跟連接總數(shù)無關，因此在實際的網(wǎng)絡環(huán)境中，Epoll的效率就會遠遠高于select和poll。

3、 內(nèi)存拷貝，利用mmap()文件映射內(nèi)存加速與內(nèi)核空間的消息傳遞；即epoll使用mmap減少復制開銷。

select、poll、epoll 區(qū)別總結(jié)：

1、支持一個進程所能打開的最大連接數(shù)

2、FD劇增后帶來的IO效率問題

3、 消息傳遞方式

總結(jié)：

綜上，在選擇select，poll，epoll時要根據(jù)具體的使用場合以及這三種方式的自身特點。

1、表面上看epoll的性能最好，但是在連接數(shù)少并且連接都十分活躍的情況下，select和poll的性能可能比epoll好，畢竟epoll的通知機制需要很多函數(shù)回調(diào)。

2、select低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善

同步/異步與阻塞/非阻塞經(jīng)?？吹绞浅蓪Τ霈F(xiàn)：同步阻塞,異步非阻塞,同步非阻塞

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論