[轉]關於Blocking IO, Non-Blocking IO 和 Asynchronous I/O的理解

---恢復內容開始---

關於Blocking IO, Non-Blocking IO 和 Asynchronous I/O的理解

歸納來講，一個IO操做能夠分爲兩個部分：發出請求、結果完成。若是從發出請求到結果返回，一直Block，那就是Blocking IO；若是發出請求就能夠返回（結果完成不考慮），就是non-blocking IO；若是發出請求就返回，結果返回是Block在select或者poll上的，則其只能稱爲IO multiplexing；若是發出請求就返回，結果返回經過Call Back的方式被處理，就是AIO。

文[2]中圖畫的不錯，說的也比較清楚借來用一下。

 

Blocking IO

這個最好理解了，在Blocking IO模式下，函數調用只有在操做完成後纔會返回。下圖是它調用過程的圖示：

 

重點解釋下上圖，下面例子都會講到。首先application調用 recvfrom()轉入kernel，注意kernel有2個過程，wait for data和copy data from kernel to user。直到最後copy complete後，recvfrom()才返回。此過程一直是阻塞的。

 

Non-Blocking IO

Non-Blocking 是Blocking的反，也就是說，即便操做沒有完成，函數也能夠返回。調用過程以下：

 

能夠看見，若是直接操做它，那就是個輪詢。。直到內核緩衝區有數據

AIO也是這樣啊？對！這是Non-Blocking IO 和AIO的共同點。其實從概念層面來講Non-Blocking IO 就是AIO，他們沒有什麼區別。可是Non-Blocking IO是對文件描述符（*nix）或者Handle（Windows）的設置，在執行操做時不須要特殊的數據結構。Non-Blocking IO提交請求後只能經過提交的操做函數來查詢操做是否完成，這是一個很大的限制。而AIO每每會提供多種通知或者查詢機制，也就是說用Non-Blocking IO時只能輪詢，而AIO有更多選擇。因此是否支持輪詢外的其餘機制是AIO和Non-Blocking IO的區別。

Non-Blocking IO和Blocking IO的區別僅僅在操做是否可以馬上完成，若是可以馬上完成，IO函數的行爲是同樣的；若是不能馬上完成，Non-Blocking IO會返回EAGAIN或者EWOULDBLOCK，而Blocking IO會一直阻塞。

I/O multiplexing (select and poll)
最多見的I/O複用模型，select。

 

select先阻塞，有活動套接字才返回。與blocking I/O相比，select會有兩次系統調用，可是select能處理多個套接字。

signal driven I/O (SIGIO)
只有UNIX系統支持，感興趣的課查閱相關資料

 

與I/O multiplexing (select and poll)相比，它的優點是，免去了select的阻塞與輪詢，當有活躍套接字時，由註冊的handler處理。

 

Asynchronous I/O （the POSIX aio_functions）

不多有*nix系統支持，windows的IOCP則是此模型。

The POSIX asynchronous I/O (AIO) interface allows applications to initiate one or more I/O operations that are performed asynchronously (i.e., in the background). The application can elect to be notified of completion of the I/O operation in a variety of ways: by delivery of a signal, by instantiation of a thread, or no notification at all.

AIO讓應用發起一個操做請求，讓這個請求被異步地執行。應用能夠選擇在操做完成時被通知到或者不被通知。因此通知機制並非AIO的核心，可是須要提供幾種選擇。在Windows上，Overlapped IO是AIO的實現，IOCP在Overlapped IO的基礎上提供了高效的通知機制。

 

 

徹底異步的I/O複用機制，由於縱觀上面其它四種模型，至少都會在由kernel copy data to application時阻塞。而該模型是當copy完成後才通知application，可見是純異步的。好像只有windows的完成端口是這個模型，效率也很出色。

下面是以上五種模型的比較

 

能夠看出，越日後，阻塞越少，理論上效率也是最優。

 

下面能夠把select,epoll,iocp,kqueue按號入座。

select和iocp分別對應第3種與第5種模型，那麼epoll與kqueue呢？其實也於select屬於同一種模型，只是更高級一些，能夠看做有了第4種模型的某些特性，如callback機制。

那麼，爲何epoll,kqueue比select高級？ 

答案是，他們無輪詢。由於他們用callback取代了。想一想看，當套接字比較多的時候，每次select()都要經過遍歷FD_SETSIZE個Socket來完成調度,無論哪一個Socket是活躍的,都遍歷一遍。這會浪費不少CPU時間。若是能給套接字註冊某個回調函數，當他們活躍時，自動完成相關操做，那就避免了輪詢，這正是epoll與kqueue作的。

windows or *nix （IOCP or kqueue/epoll）？

誠然，Windows的IOCP很是出色，目前不多有支持asynchronous I/O的系統，可是因爲其系統自己的侷限性，大型服務器仍是在UNIX下。並且正如上面所述，kqueue/epoll 與 IOCP相比，就是多了一層從內核copy數據到應用層的阻塞，從而不能算做asynchronous I/O類。可是，這層小小的阻塞無足輕重，kqueue與epoll已經作得很優秀了。

提供一致的接口，IO Design Patterns

實際上，不論是哪一種模型，均可以抽象一層出來，提供一致的接口，廣爲人知的有ACE,Libevent這些，他們都是跨平臺的，並且他們自動選擇最優的I/O複用機制，用戶只需調用接口便可。說到這裏又得說說2個設計模式，Reactor and Proactor。有一篇經典文章http://www.artima.com/articles/io_design_patterns.html值得閱讀，Libevent是Reactor模型，ACE提供Proactor模型。實際都是對各類I/O複用機制的封裝。

Java nio包是什麼I/O機制？

我曾天真的認爲java nio封裝的是IOCP。。如今能夠肯定，目前的java本質是select()模型，能夠檢查/jre/bin/nio.dll得知。至於java服務器爲何效率還不錯。。我也不得而知，多是設計得比較好吧。。-_-。

=====================分割線==================================

總結一些重點：

只有IOCP是asynchronous I/O，其餘機制或多或少都會有一點阻塞。 select低效是由於每次它都須要輪詢。但低效也是相對的，視狀況而定，也可經過良好的設計改善 epoll, kqueue是Reacor模式，IOCP是Proactor模式。 java nio包是select模型。。

 

Reference:

1. http://www.artima.com/articles/io_design_patterns.html

2. http://hi.baidu.com/ailuoli/blog/item/f9fe370f0dee7bf1ab6457e7.html

 

 

---恢復內容結束---

關於Blocking IO, Non-Blocking IO 和 Asynchronous I/O的理解

歸納來講，一個IO操做能夠分爲兩個部分：發出請求、結果完成。若是從發出請求到結果返回，一直Block，那就是Blocking IO；若是發出請求就能夠返回（結果完成不考慮），就是non-blocking IO；若是發出請求就返回，結果返回是Block在select或者poll上的，則其只能稱爲IO multiplexing；若是發出請求就返回，結果返回經過Call Back的方式被處理，就是AIO。

文[2]中圖畫的不錯，說的也比較清楚借來用一下。

 

Blocking IO

這個最好理解了，在Blocking IO模式下，函數調用只有在操做完成後纔會返回。下圖是它調用過程的圖示：

 

重點解釋下上圖，下面例子都會講到。首先application調用 recvfrom()轉入kernel，注意kernel有2個過程，wait for data和copy data from kernel to user。直到最後copy complete後，recvfrom()才返回。此過程一直是阻塞的。

 

Non-Blocking IO

Non-Blocking 是Blocking的反，也就是說，即便操做沒有完成，函數也能夠返回。調用過程以下：

 

能夠看見，若是直接操做它，那就是個輪詢。。直到內核緩衝區有數據

AIO也是這樣啊？對！這是Non-Blocking IO 和AIO的共同點。其實從概念層面來講Non-Blocking IO 就是AIO，他們沒有什麼區別。可是Non-Blocking IO是對文件描述符（*nix）或者Handle（Windows）的設置，在執行操做時不須要特殊的數據結構。Non-Blocking IO提交請求後只能經過提交的操做函數來查詢操做是否完成，這是一個很大的限制。而AIO每每會提供多種通知或者查詢機制，也就是說用Non-Blocking IO時只能輪詢，而AIO有更多選擇。因此是否支持輪詢外的其餘機制是AIO和Non-Blocking IO的區別。

Non-Blocking IO和Blocking IO的區別僅僅在操做是否可以馬上完成，若是可以馬上完成，IO函數的行爲是同樣的；若是不能馬上完成，Non-Blocking IO會返回EAGAIN或者EWOULDBLOCK，而Blocking IO會一直阻塞。

I/O multiplexing (select and poll)
最多見的I/O複用模型，select。

 

select先阻塞，有活動套接字才返回。與blocking I/O相比，select會有兩次系統調用，可是select能處理多個套接字。

signal driven I/O (SIGIO)
只有UNIX系統支持，感興趣的課查閱相關資料

 

與I/O multiplexing (select and poll)相比，它的優點是，免去了select的阻塞與輪詢，當有活躍套接字時，由註冊的handler處理。

 

Asynchronous I/O （the POSIX aio_functions）

不多有*nix系統支持，windows的IOCP則是此模型。

The POSIX asynchronous I/O (AIO) interface allows applications to initiate one or more I/O operations that are performed asynchronously (i.e., in the background). The application can elect to be notified of completion of the I/O operation in a variety of ways: by delivery of a signal, by instantiation of a thread, or no notification at all.

AIO讓應用發起一個操做請求，讓這個請求被異步地執行。應用能夠選擇在操做完成時被通知到或者不被通知。因此通知機制並非AIO的核心，可是須要提供幾種選擇。在Windows上，Overlapped IO是AIO的實現，IOCP在Overlapped IO的基礎上提供了高效的通知機制。

 

 

徹底異步的I/O複用機制，由於縱觀上面其它四種模型，至少都會在由kernel copy data to application時阻塞。而該模型是當copy完成後才通知application，可見是純異步的。好像只有windows的完成端口是這個模型，效率也很出色。

下面是以上五種模型的比較

 

能夠看出，越日後，阻塞越少，理論上效率也是最優。

 

下面能夠把select,epoll,iocp,kqueue按號入座。

select和iocp分別對應第3種與第5種模型，那麼epoll與kqueue呢？其實也於select屬於同一種模型，只是更高級一些，能夠看做有了第4種模型的某些特性，如callback機制。

那麼，爲何epoll,kqueue比select高級？ 

答案是，他們無輪詢。由於他們用callback取代了。想一想看，當套接字比較多的時候，每次select()都要經過遍歷FD_SETSIZE個Socket來完成調度,無論哪一個Socket是活躍的,都遍歷一遍。這會浪費不少CPU時間。若是能給套接字註冊某個回調函數，當他們活躍時，自動完成相關操做，那就避免了輪詢，這正是epoll與kqueue作的。

windows or *nix （IOCP or kqueue/epoll）？

誠然，Windows的IOCP很是出色，目前不多有支持asynchronous I/O的系統，可是因爲其系統自己的侷限性，大型服務器仍是在UNIX下。並且正如上面所述，kqueue/epoll 與 IOCP相比，就是多了一層從內核copy數據到應用層的阻塞，從而不能算做asynchronous I/O類。可是，這層小小的阻塞無足輕重，kqueue與epoll已經作得很優秀了。

提供一致的接口，IO Design Patterns

實際上，不論是哪一種模型，均可以抽象一層出來，提供一致的接口，廣爲人知的有ACE,Libevent這些，他們都是跨平臺的，並且他們自動選擇最優的I/O複用機制，用戶只需調用接口便可。說到這裏又得說說2個設計模式，Reactor and Proactor。有一篇經典文章http://www.artima.com/articles/io_design_patterns.html值得閱讀，Libevent是Reactor模型，ACE提供Proactor模型。實際都是對各類I/O複用機制的封裝。

Java nio包是什麼I/O機制？

我曾天真的認爲java nio封裝的是IOCP。。如今能夠肯定，目前的java本質是select()模型，能夠檢查/jre/bin/nio.dll得知。至於java服務器爲何效率還不錯。。我也不得而知，多是設計得比較好吧。。-_-。

=====================分割線==================================

總結一些重點：

只有IOCP是asynchronous I/O，其餘機制或多或少都會有一點阻塞。 select低效是由於每次它都須要輪詢。但低效也是相對的，視狀況而定，也可經過良好的設計改善 epoll, kqueue是Reacor模式，IOCP是Proactor模式。 java nio包是select模型。。

 

Reference:

1. http://www.artima.com/articles/io_design_patterns.html

2. http://hi.baidu.com/ailuoli/blog/item/f9fe370f0dee7bf1ab6457e7.html