引言

BIO和NIO是兩種不同的網路通訊模型，現如今NIO已經大量應用在Jetty、ZooKeeper、Netty等開源框架中。

一個面向流、一個面向緩衝區

一個是阻塞式的、一個非阻塞

一個沒有io多路複用器、一個有

下面通過一個例子解釋兩者區別：

假設當前服務端程式需要同時從與多個客戶端建立的連線讀取資料。

使用BIO

如果採用阻塞式IO，單執行緒情況下，處理者執行緒可能阻塞在其中一個套接字的read上，導致另一個套接字即使準備好了資料也無法處理，這個時候解決的方法就是針對每一個套接字，都新建一個執行緒處理其資料讀取。

所以說，在BIO工作模式下，服務端程式要想同時處理多個套接字的資料讀取，在等待接收連線請求的主執行緒之外，還要為每一個建立好的連線分配一個新的執行緒進行處理。

使用NIO

輪詢方式

如果將套接字讀操作換成非阻塞的，那麼只需要一個執行緒就可以同時處理套接字，每次檢查一個套接字，有資料則讀取，沒有則檢查下一個，因為是非阻塞的，所以執行read操作時若沒有資料準備好則立即返回，不會發生阻塞。

I/O多路複用

這種輪詢的方式缺點是浪費CPU資源，大部分時間可能都是無資料可讀的，不必仍不間斷的反覆執行read操作，I/O多路複用（IOmultiplexing）是一種更好的方法，呼叫select函式時，其內部會維護一張監聽的套接字的列表，其會一直阻塞直到其中某一個套接字有資料準備好才返回，並告訴是哪個套接字可讀，這時再呼叫該套接字的read函式效率更高。

所以基本可以認為 “NIO = I/O多路複用 + 非阻塞式I/O”，大部分情況下是單執行緒，但也有超過一個執行緒實現NIO的情況

NIO三種模型

上面所講到的只需要一個執行緒就可以同時處理多個套接字，這只是其中的一種單執行緒模型，是一種較為極端的情況，NIO主要包含三種執行緒模型：

1) Reactor單執行緒模型

2) Reactor多執行緒模型

3)主從Reactor多執行緒模型

Reactor單執行緒模型：

單個執行緒完成所有事情包括接收客戶端的TCP連線請求，讀取和寫入套接字資料等。

對於一些小容量應用場景，可以使用單執行緒模型。但是對於高負載、大併發的應用卻不合適，主要原因如下：

1) 一個NIO執行緒同時處理成百上千的鏈路，效能上無法支撐，即便NIO執行緒的CPU負荷達到100%，也無法滿足海量訊息的編碼、解碼、讀取和傳送；

2) 當NIO執行緒負載過重之後，處理速度將變慢，這會導致大量客戶端連線超時，超時之後往往會進行重發，這更加重了NIO執行緒的負載，最終會導致大量訊息積壓和處理超時，NIO執行緒會成為系統的效能瓶頸；

3) 可靠性問題：一旦NIO執行緒意外跑飛，或者進入死迴圈，會導致整個系統通訊模組不可用，不能接收和處理外部訊息，造成節點故障。

為了解決這些問題，演進出了Reactor多執行緒模型。

Reactor多執行緒模型：

Rector多執行緒模型與單執行緒模型最大的區別就是有一組NIO執行緒處理真實的IO操作。

Reactor多執行緒模型的特點：

1) 有專門一個NIO執行緒-Acceptor執行緒用於監聽服務端，接收客戶端的TCP連線請求；

2) 網路IO操作-讀、寫等由一個NIO執行緒池負責，執行緒池可以採用標準的JDK執行緒池實現，它包含一個任務佇列和N個可用的執行緒，由這些NIO執行緒負責訊息的讀取、解碼、編碼和傳送；

3) 1個NIO執行緒可以同時處理N條鏈路，但是1個鏈路只對應1個NIO執行緒，防止發生併發操作問題。

在絕大多數場景下，Reactor多執行緒模型都可以滿足效能需求；但是，在極特殊應用場景中，一個NIO執行緒負責監聽和處理所有的客戶端連線可能會存在效能問題。例如百萬客戶端併發連線，或者服務端需要對客戶端的握手訊息進行安全認證，認證本身非常損耗效能。在這類場景下，單獨一個Acceptor執行緒可能會存在效能不足問題，為了解決效能問題，產生了第三種Reactor執行緒模型-主從Reactor多執行緒模型。

即從單執行緒中由一個執行緒即監聽連線事件、讀寫事件、由完成資料讀寫，拆分為由一個執行緒專門監聽各種事件，再由專門的執行緒池負責處理真正的IO資料讀寫。

主從Reactor多執行緒模型

主從Reactor執行緒模型與Reactor多執行緒模型的最大區別就是有一組NIO執行緒處理連線、讀寫事件。

主從Reactor執行緒模型的特點是：服務端用於接收客戶端連線的不再是個1個單獨的NIO執行緒，而是一個獨立的NIO執行緒池。Acceptor接收到客戶端TCP連線請求處理完成後（可能包含接入認證等），將新建立的SocketChannel註冊到IO執行緒池（sub reactor執行緒池）的某個IO執行緒上，由它負責SocketChannel的讀寫和編解碼工作。Acceptor執行緒池僅僅只用於客戶端的登陸、握手和安全認證，一旦鏈路建立成功，就將鏈路註冊到後端subReactor執行緒池的IO執行緒上，由IO執行緒負責後續的IO操作。

即從多執行緒模型中由一個執行緒來監聽連線事件和資料讀寫事件，拆分為一個執行緒監聽連線事件，執行緒池的多個執行緒監聽已經建立連線的套接字的資料讀寫事件，另外和多執行緒模型一樣有專門的執行緒池處理真正的IO操作。

各自適用場景

NIO適用場景

伺服器需要支援超大量的長時間連線。比如10000個連線以上，並且每個客戶端並不會頻繁地傳送太多資料。例如總公司的一箇中心伺服器需要收集全國便利店各個收銀機的交易資訊，只需要少量執行緒按需處理維護的大量長期連線。

Jetty、Mina、Netty、ZooKeeper等都是基於NIO方式實現。

BIO適用場景

適用於連線數目比較小，並且一次傳送大量資料的場景，這種方式對伺服器資源要求比較高，併發侷限於應用中。

下面一個例子是我看過的一個講述的很貼切的例子：   

一輛從 A 開往 B 的公共汽車上，路上有很多點可能會有人下車。司機不知道哪些點會有哪些人會下車，對於需要下車的人，如何處理更好？   

1. 司機過程中定時詢問每個乘客是否到達目的地，若有人說到了，那麼司機停車，乘客下車。 ( 類似阻塞式 )   

2. 每個人告訴售票員自己的目的地，然後睡覺，司機只和售票員互動，到了某個點由售票員通知乘客下車。 ( 類似非阻塞 )     

很顯然，每個人要到達某個目的地可以認為是一個執行緒，司機可以認為是 CPU 。在阻塞式裡面，每個執行緒需要不斷的輪詢，上下文切換，以達到找到目的地的結果。而在非阻塞方式裡，每個乘客 ( 執行緒 ) 都在睡覺 ( 休眠 ) ，只在真正外部環境準備好了才喚醒，這樣的喚醒肯定不會阻塞。