Java面試基礎篇——第九篇：BIO，NIO，AIO的區別

如今IO模型主要分三類：BIO(同步阻塞IO),NIO(同步非阻塞IO),AIO()。 先來看看BIO。

1. BIO

服務端接受到請求後，要指派或新建一個線程去處理客戶端的IO請求，直到收到斷開鏈接的指令。這麼作的弊端是什麼呢？當服務端收到大量來自客戶端的IO請求時，須要新建大量線程來處理請求，服務器資源極可能被耗盡，高併發狀況下，致使大量鏈接被掛起，服務器資源嚴重不足。由於BIO是同步阻塞模型，因此針對每一個socket鏈接，服務器都要新建線程，哪怕是使用了線程池，也會形成由於線程上下文切換而形成大量開銷。

NIO

NIO是非阻塞IO,使用Reactor模型。Reactor模型中，NIO只有acceptor的服務線程是堵塞進行的，其它讀寫線程是經過註冊事件的方式，有讀寫事件激活時才調用線程資源去執行，不會一直堵塞等着讀寫操做。Reactor的瓶頸主要是在acceptor的執行，全部的讀寫事件都是在acceptor分發。

AIO

與NIO不一樣，AIO須要一個鏈接註冊讀寫事件和回調方法，當進行讀寫操做時，只須直接調用API的read或write方法便可。這兩種方法均爲異步的，對於讀操做而言，當有流可讀取時，操做系統會將可讀的流傳入read方法的緩衝區，並通知應用程序；對於寫操做而言，當操做系統將write方法傳遞的流寫入完畢時，操做系統主動通知應用程序。總結：用戶發起IO操做當即返回，等IO操做完成後，應用程序會獲得IO操做完成的通知，此時用戶進程只須要對通知進行處理，不須要進行實際的IO操做，由於實際操做已經由操做系統完成了。

BIO、NIO、AIO適用場景分析:

BIO方式適用於鏈接數目比較小且固定的架構，這種方式對服務器資源要求比較高，併發侷限於應用中，JDK1.4之前的惟一選擇，但程序直觀簡單易理解。

NIO方式適用於鏈接數目多且鏈接比較短（輕操做）的架構，好比聊天服務器，併發侷限於應用中，編程比較複雜，JDK1.4開始支持。

AIO方式使用於鏈接數目多且鏈接比較長（重操做）的架構，好比相冊服務器，充分調用OS參與併發操做，編程比較複雜，JDK7開始支持。