IO複用,AIO,BIO,NIO,同步，異步，阻塞和非阻塞 區別

時間  2019-11-13
標籤 aio bio nio 同步 異步 阻塞 區別 欄目 Java 简体版
原文   原文鏈接

若是面試問到IO操做，這篇文章提到的問題，基本是必問，百度的面試官問我三個問題html

(1)什麼是NIO(Non-blocked IO),AIO,BIOjava

(2) java IO 與 NIO(New IO)的區別linux

(3)select 與 epoll,poll區別面試

我胡亂說了一氣，本身邊說邊以爲完蛋了。果真，二面沒過，很簡單的問題，回來後趕忙做了總結：編程

1、什麼是socket？什麼是I/O操做？

咱們都知道unix(like)世界裏，一切皆文件，而文件是什麼呢？文件就是一串二進制流而已，無論socket,仍是FIFO、管道、終端，對咱們來講，一切都是文件，一切都是流。在信息 交換的過程當中，咱們都是對這些流進行數據的收發操做，簡稱爲I/O操做(input and output)，往流中讀出數據，系統調用read，寫入數據，系統調用write。不過話說回來了 ，計算機裏有這麼多的流，我怎麼知道要操做哪一個流呢？對，就是文件描述符，即一般所說的fd，一個fd就是一個整數，因此，對這個整數的操做，就是對這個文件（流）的操做。咱們建立一個socket,經過系統調用會返回一個文件描述符，那麼剩下對socket的操做就會轉化爲對這個描述符的操做。不能不說這又是一種分層和抽象的思想。設計模式

2、同步異步，阻塞非阻塞區別聯繫緩存

    實際上同步與異步是針對應用程序與內核的交互而言的。同步過程當中進程觸發IO操做並等待(也就是咱們說的阻塞)或者輪詢的去查看IO操做(也就是咱們說的非阻塞)是否完成。 異步過程當中進程觸發IO操做之後，直接返回，作本身的事情，IO交給內核來處理，完成後內核通知進程IO完成。bash

同步和異步針對應用程序來，關注的是程序中間的協做關係；阻塞與非阻塞更關注的是單個進程的執行狀態。服務器

同步有阻塞和非阻塞之分，異步沒有，它必定是非阻塞的。網絡

阻塞、非阻塞、多路IO複用，都是同步IO，異步一定是非阻塞的，因此不存在異步阻塞和異步非阻塞的說法。真正的異步IO須要CPU的深度參與。換句話說，只有用戶線程在操做IO的時候根本不去考慮IO的執行所有都交給CPU去完成，而本身只等待一個完成信號的時候，纔是真正的異步IO。因此，拉一個子線程去輪詢、去死循環，或者使用select、poll、epool，都不是異步。

同步：執行一個操做以後，進程觸發IO操做並等待(也就是咱們說的阻塞)或者輪詢的去查看IO操做(也就是咱們說的非阻塞)是否完成，等待結果，而後才繼續執行後續的操做。

異步：執行一個操做後，能夠去執行其餘的操做，而後等待通知再回來執行剛纔沒執行完的操做。

阻塞：進程給CPU傳達一個任務以後，一直等待CPU處理完成，而後才執行後面的操做。

非阻塞：進程給CPU傳達任我後，繼續處理後續的操做，隔斷時間再來詢問以前的操做是否完成。這樣的過程其實也叫輪詢。

我認爲， 同步與異步的根本區別是：

(1) 這是 BIO，同步阻塞的模型，下面也有，

 

 

 

 

 

 

 

 

 

 

 

由上面的圖能夠看出，IO讀分爲兩部分，(a)是數據經過網關到達內核，內核準備好數據，(b)數據從內核緩存寫入用戶緩存。

同步：無論是BIO,NIO,仍是IO多路複用，第二步數據從內核緩存寫入用戶緩存必定是由 用戶線程自行讀取數據，處理數據。

異步：第二步數據是內核寫入的，並放在了用戶線程指定的緩存區，寫入完畢後通知用戶線程。

2、阻塞？

什麼是程序的阻塞呢？想象這種情形，好比你等快遞，但快遞一直沒來，你會怎麼作？有兩種方式：

  • 快遞沒來，我能夠先去睡覺，而後快遞來了給我打電話叫我去取就好了。
  • 快遞沒來，我就不停的給快遞打電話說：擦，怎麼還沒來，給老子快點，直到快遞來。

很顯然，你沒法忍受第二種方式，不只耽擱本身的時間，也會讓快遞很想打你。
而在計算機世界，這兩種情形就對應阻塞和非阻塞忙輪詢。

  • 非阻塞忙輪詢：數據沒來，進程就不停的去檢測數據，直到數據來。
  • 阻塞：數據沒來，啥都不作，直到數據來了，才進行下一步的處理。

先說說阻塞，由於一個線程只能處理一個套接字的I/O事件，若是想同時處理多個，能夠利用非阻塞忙輪詢的方式,僞代碼以下：

while true  
{  
    for i in stream[]  
    {  
        if i has data  
        read until unavailable  
    }  
}

咱們只要把全部流從頭至尾查詢一遍，就能夠處理多個流了，但這樣作很很差，由於若是全部的流都沒有I/O事件，白白浪費CPU時間片。正若有一位科學家所說，計算機全部的問題均可以增長一箇中間層來解決，一樣，爲了不這裏cpu的空轉，咱們不讓這個線程親自去檢查流中是否有事件，而是引進了一個代理(一開始是select,後來是poll)，這個代理很牛，它能夠同時觀察許多流的I/O事件，若是沒有事件，代理就阻塞，線程就不會挨個挨個去輪詢了，僞代碼以下： 

while true  
{  
    select(streams[]) //這一步死在這裏，知道有一個流有I/O事件時，才往下執行  
    for i in streams[]  
    {  
        if i has data  
        read until unavailable  
    }  
}

 可是依然有個問題，咱們從select那裏僅僅知道了，有I/O事件發生了，卻並不知道是哪那幾個流（可能有一個，多個，甚至所有），咱們只能無差異輪詢全部流，找出能讀出數據，或者寫入數據的流，對他們進行操做。因此select具備O(n)的無差異輪詢複雜度，同時處理的流越多，無差異輪詢時間就越長。

epoll能夠理解爲event poll，不一樣於忙輪詢和無差異輪詢，epoll會把哪一個流發生了怎樣的I/O事件通知咱們。因此咱們說epoll其實是事件驅動（每一個事件關聯上fd）的，此時咱們對這些流的操做都是有意義的。（複雜度下降到了O(1)）僞代碼以下：

while true  
{  
    active_stream[] = epoll_wait(epollfd)  
    for i in active_stream[]  
    {  
        read or write till  
    }  
}

能夠看到，select和epoll最大的區別就是：select只是告訴你必定數目的流有事件了，至於哪一個流有事件，還得你一個一個地去輪詢，而epoll會把發生的事件告訴你，經過發生的事件，就天然而然定位到哪一個流了。不能不說epoll跟select相比，是質的飛躍，我以爲這也是一種犧牲空間，換取時間的思想，畢竟如今硬件愈來愈便宜了。

更詳細的Select,poll,epoll 請參考：select、poll、epoll之間的區別(搜狗面試)

3、I/O多路複用

好了，咱們講了這麼多，再來總結一下，到底什麼是I/O多路複用。
先講一下I/O模型：
首先，輸入操做通常包含兩個步驟：

  1. 等待數據準備好（waiting for data to be ready）。對於一個套接口上的操做，這一步驟關係到數據從網絡到達，並將其複製到內核的某個緩衝區。
  2. 將數據從內核緩衝區複製到進程緩衝區（copying the data from the kernel to the process）。

其次瞭解一下經常使用的3種I/O模型：

一、阻塞I/O模型(BIO)

最普遍的模型是阻塞I/O模型，默認狀況下，全部套接口都是阻塞的。 進程調用recvfrom系統調用，整個過程是阻塞的，直到數據複製到進程緩衝區時才返回（固然，系統調用被中斷也會返回）。

 

 

 

 

 

 

 

 

 

二、非阻塞I/O模型(NIO)

當咱們把一個套接口設置爲非阻塞時，就是在告訴內核，當請求的I/O操做沒法完成時，不要將進程睡眠，而是返回一個錯誤。當數據沒有準備好時，內核當即返回EWOULDBLOCK錯誤，第四次調用系統調用時，數據已經存在，這時將數據複製到進程緩衝區中。這其中有一個操做時輪詢（polling）。

 

 

 

 

 

 

 

 

 

 

三、I/O複用模型

此模型用到select和poll函數，這兩個函數也會使進程阻塞，select先阻塞，有活動套接字才返回，可是和阻塞I/O不一樣的是，這兩個函數能夠同時阻塞多個I/O操做，並且能夠同時對多個讀操做，多個寫操做的I/O函數進行檢測，直到有數據可讀或可寫（就是監聽多個socket）。select被調用後，進程會被阻塞，內核監視全部select負責的socket，當有任何一個socket的數據準備好了，select就會返回套接字可讀，咱們就能夠調用recvfrom處理數據。

正由於阻塞I/O只能阻塞一個I/O操做，而I/O複用模型可以阻塞多個I/O操做，因此才叫作多路複用。

 

 

 

 

 

 

 

 

 

四、信號驅動I/O模型（signal driven I/O， SIGIO）

　　首先咱們容許套接口進行信號驅動I/O,並安裝一個信號處理函數，進程繼續運行並不阻塞。當數據準備好時，進程會收到一個SIGIO信號，能夠在信號處理函數中調用I/O操做函數處理數據。當數據報準備好讀取時，內核就爲該進程產生一個SIGIO信號。咱們隨後既能夠在信號處理函數中調用recvfrom讀取數據報，並通知主循環數據已準備好待處理，也能夠當即通知主循環，讓它來讀取數據報。不管如何處理SIGIO信號，這種模型的優點在於等待數據報到達(第一階段)期間，進程能夠繼續執行，不被阻塞。免去了select的阻塞與輪詢，當有活躍套接字時，由註冊的handler處理。

 

 

 

 

 

 

 

 

 

 

五、異步I/O模型(AIO, asynchronous I/O)

　　進程發起read操做以後，馬上就能夠開始去作其它的事。而另外一方面，從kernel的角度，當它受到一個asynchronous read以後，首先它會馬上返回，因此不會對用戶進程產生任何block。而後，kernel會等待數據準備完成，而後將數據拷貝到用戶內存，當這一切都完成以後，kernel會給用戶進程發送一個signal，告訴它read操做完成了。

　　這個模型工做機制是：告訴內核啓動某個操做，並讓內核在整個操做(包括第二階段，即將數據從內核拷貝到進程緩衝區中)完成後通知咱們。

這種模型和前一種模型區別在於：信號驅動I/O是由內核通知咱們什麼時候能夠啓動一個I/O操做，而異步I/O模型是由內核通知咱們I/O操做什麼時候完成。

 

 

 

 

 

 

 

 

 

高性能IO模型淺析 

 

服務器端編程常常須要構造高性能的IO模型，常見的IO模型有四種：

（1）同步阻塞IO（Blocking IO）：即傳統的IO模型。

（2）同步非阻塞IO（Non-blocking IO）：默認建立的socket都是阻塞的，非阻塞IO要求socket被設置爲NONBLOCK。注意這裏所說的NIO並不是Java的NIO（New IO）庫。

（3）IO多路複用（IO Multiplexing）：即經典的Reactor設計模式，Java中的Selector和Linux中的epoll都是這種模型。

（4）異步IO（Asynchronous IO）：即經典的Proactor設計模式，也稱爲異步非阻塞IO。 

爲了方便描述，咱們統一使用IO的讀操做做爲示例。

1、同步阻塞IO

同步阻塞IO模型是最簡單的IO模型，用戶線程在內核進行IO操做時被阻塞。

圖1 同步阻塞IO

如圖1所示，用戶線程經過系統調用read發起IO讀操做，由用戶空間轉到內核空間。內核等到數據包到達後，而後將接收的數據拷貝到用戶空間，完成read操做。

用戶線程使用同步阻塞IO模型的僞代碼描述爲：

{

read(socket, buffer);

process(buffer);

}

即用戶須要等待read將socket中的數據讀取到buffer後，才繼續處理接收的數據。整個IO請求的過程當中，用戶線程是被阻塞的，這致使用戶在發起IO請求時，不能作任何事情，對CPU的資源利用率不夠。

2、同步非阻塞IO

同步非阻塞IO是在同步阻塞IO的基礎上，將socket設置爲NONBLOCK。這樣作用戶線程能夠在發起IO請求後能夠當即返回。

圖2 同步非阻塞IO

如圖2所示，因爲socket是非阻塞的方式，所以用戶線程發起IO請求時當即返回。但並未讀取到任何數據，用戶線程須要不斷地發起IO請求，直到數據到達後，才真正讀取到數據，繼續執行。

用戶線程使用同步非阻塞IO模型的僞代碼描述爲：

{

while(read(socket, buffer) != SUCCESS)

;

process(buffer);

}

即用戶須要不斷地調用read，嘗試讀取socket中的數據，直到讀取成功後，才繼續處理接收的數據。整個IO請求的過程當中，雖然用戶線程每次發起IO請求後能夠當即返回，可是爲了等到數據，仍須要不斷地輪詢、重複請求，消耗了大量的CPU的資源。通常不多直接使用這種模型，而是在其餘IO模型中使用非阻塞IO這一特性。

3、IO多路複用

IO多路複用模型是創建在內核提供的多路分離函數select基礎之上的，使用select函數能夠避免同步非阻塞IO模型中輪詢等待的問題。

圖3 多路分離函數select

如圖3所示，用戶首先將須要進行IO操做的socket添加到select中，而後阻塞等待select系統調用返回。當數據到達時，socket被激活，select函數返回。用戶線程正式發起read請求，讀取數據並繼續執行。

從流程上來看，使用select函數進行IO請求和同步阻塞模型沒有太大的區別，甚至還多了添加監視socket，以及調用select函數的額外操做，效率更差。可是，使用select之後最大的優點是用戶能夠在一個線程內同時處理多個socket的IO請求。用戶能夠註冊多個socket，而後不斷地調用select讀取被激活的socket，便可達到在同一個線程內同時處理多個IO請求的目的。而在同步阻塞模型中，必須經過多線程的方式才能達到這個目的。

用戶線程使用select函數的僞代碼描述爲：

{

select(socket);

while(1) {

  sockets = select();

  for(socket in sockets) {

   if(can_read(socket)) {

      read(socket, buffer);

      process(buffer);

    }

   }

  }

}

其中while循環前將socket添加到select監視中，而後在while內一直調用select獲取被激活的socket，一旦socket可讀，便調用read函數將socket中的數據讀取出來。

 

然而，使用select函數的優勢並不只限於此。雖然上述方式容許單線程內處理多個IO請求，可是每一個IO請求的過程仍是阻塞的（在select函數上阻塞），平均時間甚至比同步阻塞IO模型還要長。若是用戶線程只註冊本身感興趣的socket或者IO請求，而後去作本身的事情，等到數據到來時再進行處理，則能夠提升CPU的利用率。

IO多路複用模型使用了Reactor設計模式實現了這一機制。

圖4 Reactor設計模式

如圖4所示，EventHandler抽象類表示IO事件處理器，它擁有IO文件句柄Handle（經過get_handle獲取），以及對Handle的操做handle_event（讀/寫等）。繼承於EventHandler的子類能夠對事件處理器的行爲進行定製。Reactor類用於管理EventHandler（註冊、刪除等），並使用handle_events實現事件循環，不斷調用同步事件多路分離器（通常是內核）的多路分離函數select，只要某個文件句柄被激活（可讀/寫等），select就返回（阻塞），handle_events就會調用與文件句柄關聯的事件處理器的handle_event進行相關操做。

圖5 IO多路複用

如圖5所示，經過Reactor的方式，能夠將用戶線程輪詢IO操做狀態的工做統一交給handle_events事件循環進行處理。用戶線程註冊事件處理器以後能夠繼續執行作其餘的工做（異步），而Reactor線程負責調用內核的select函數檢查socket狀態。當有socket被激活時，則通知相應的用戶線程（或執行用戶線程的回調函數），執行handle_event進行數據讀取、處理的工做。因爲select函數是阻塞的，所以多路IO複用模型也被稱爲異步阻塞IO模型。注意，這裏的所說的阻塞是指select函數執行時線程被阻塞，而不是指socket。通常在使用IO多路複用模型時，socket都是設置爲NONBLOCK的，不過這並不會產生影響，由於用戶發起IO請求時，數據已經到達了，用戶線程必定不會被阻塞。

用戶線程使用IO多路複用模型的僞代碼描述爲：

void UserEventHandler::handle_event() {

    if(can_read(socket)) {

           read(socket, buffer);

           process(buffer);

    }

}

{
    Reactor.register(new UserEventHandler(socket));
}

用戶須要重寫EventHandler的handle_event函數進行讀取數據、處理數據的工做，用戶線程只須要將本身的EventHandler註冊到Reactor便可。Reactor中handle_events事件循環的僞代碼大體以下。

Reactor::handle_events() {

        while(1) {
        sockets = select();
         for(socket in sockets) {
            get_event_handler(socket).handle_event();
          }
       }
}

事件循環不斷地調用select獲取被激活的socket，而後根據獲取socket對應的EventHandler，執行器handle_event函數便可。

IO多路複用是最常使用的IO模型，可是其異步程度還不夠「完全」，由於它使用了會阻塞線程的select系統調用。所以IO多路複用只能稱爲異步阻塞IO，而非真正的異步IO。

4、異步IO

「真正」的異步IO須要操做系統更強的支持。在IO多路複用模型中，事件循環將文件句柄的狀態事件通知給用戶線程，由用戶線程自行讀取數據、處理數據。而在異步IO模型中，當用戶線程收到通知時，數據已經被內核讀取完畢，並放在了用戶線程指定的緩衝區內，內核在IO完成後通知用戶線程直接使用便可。

異步IO模型使用了Proactor設計模式實現了這一機制。

圖6 Proactor設計模式

如圖6，Proactor模式和Reactor模式在結構上比較類似，不過在用戶（Client）使用方式上差異較大。Reactor模式中，用戶線程經過向Reactor對象註冊感興趣的事件監聽，而後事件觸發時調用事件處理函數。而Proactor模式中，用戶線程將AsynchronousOperation（讀/寫等）、Proactor以及操做完成時的CompletionHandler註冊到AsynchronousOperationProcessor。AsynchronousOperationProcessor使用Facade模式提供了一組異步操做API（讀/寫等）供用戶使用，當用戶線程調用異步API後，便繼續執行本身的任務。AsynchronousOperationProcessor 會開啓獨立的內核線程執行異步操做，實現真正的異步。當異步IO操做完成時，AsynchronousOperationProcessor將用戶線程與AsynchronousOperation一塊兒註冊的Proactor和CompletionHandler取出，而後將CompletionHandler與IO操做的結果數據一塊兒轉發給Proactor，Proactor負責回調每個異步操做的事件完成處理函數handle_event。雖然Proactor模式中每一個異步操做均可以綁定一個Proactor對象，可是通常在操做系統中，Proactor被實現爲Singleton模式，以便於集中化分發操做完成事件

圖7 異步IO

如圖7所示，異步IO模型中，用戶線程直接使用內核提供的異步IO API發起read請求，且發起後當即返回，繼續執行用戶線程代碼。不過此時用戶線程已經將調用的AsynchronousOperation和CompletionHandler註冊到內核，而後操做系統開啓獨立的內核線程去處理IO操做。當read請求的數據到達時，由內核負責讀取socket中的數據，並寫入用戶指定的緩衝區中。最後內核將read的數據和用戶線程註冊的CompletionHandler分發給內部Proactor，Proactor將IO完成的信息通知給用戶線程（通常經過調用用戶線程註冊的完成事件處理函數），完成異步IO。

用戶線程使用異步IO模型的僞代碼描述爲：

void UserCompletionHandler::handle_event(buffer) {

     process(buffer);

     }
{

aio_read(socket, new UserCompletionHandler);

}

用戶須要重寫CompletionHandler的handle_event函數進行處理數據的工做，參數buffer表示Proactor已經準備好的數據，用戶線程直接調用內核提供的異步IO API，並將重寫的CompletionHandler註冊便可。

相比於IO多路複用模型，異步IO並不十分經常使用，很多高性能併發服務程序使用IO多路複用模型+多線程任務處理的架構基本能夠知足需求。何況目前操做系統對異步IO的支持並不是特別完善，更多的是採用IO多路複用模型模擬異步IO的方式（IO事件觸發時不直接通知用戶線程，而是將數據讀寫完畢後放到用戶指定的緩衝區中）。Java7以後已經支持了異步IO，感興趣的讀者能夠嘗試使用。

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程