本文會從傳統的BIO到NIO再到AIO自淺至深介紹，并附上完整的代碼講解。
下面代碼中會使用這樣一個例子：用戶端發送一段算式的字元串到伺服器，伺服器計算後傳回結果到用戶端。
代碼的所有說明，都直接作為注釋，嵌入到代碼中，看代碼時就能更容易了解，代碼中會用到一個計算結果的工具類，見文章代碼部分。
相關的基礎知識文章推薦：
網絡程式設計的基本模型是C/S模型，即兩個程序間的通信。
服務端提供IP和監聽端口，用戶端通過連接配接操作想服務端監聽的位址發起連接配接請求，通過三次握手連接配接，如果連接配接成功建立，雙方就可以通過套接字進行通信。
傳統的同步阻塞模型開發中，ServerSocket負責綁定IP位址，啟動監聽端口；Socket負責發起連接配接操作。連接配接成功後，雙方通過輸入和輸出流進行同步阻塞式通信。
簡單的描述一下BIO的服務端通信模型：采用BIO通信模型的服務端，通常由一個獨立的Acceptor線程負責監聽用戶端的連接配接，它接收到用戶端連接配接請求之後為每個用戶端建立一個新的線程進行鍊路處理沒處理完成後，通過輸出流傳回應答給用戶端，線程銷毀。即典型的一請求一應答通宵模型。
傳統BIO通信模型圖：
同步阻塞式I/O建立的Server源碼：
用戶端消息處理線程ServerHandler源碼：
同步阻塞式I/O建立的Client源碼：
測試代碼，為了友善在控制台看輸出結果，放到同一個程式（jvm）中運作：
其中一次的運作結果：
伺服器已啟動，端口号：12345
算術表達式為：4-2
伺服器收到消息：4-2
___結果為：2
算術表達式為：5-10
伺服器收到消息：5-10
___結果為：-5
算術表達式為：0-9
伺服器收到消息：0-9
___結果為：-9
算術表達式為：0+6
伺服器收到消息：0+6
___結果為：6
算術表達式為：1/6
伺服器收到消息：1/6
___結果為：0.16666666666666666
...
從以上代碼，很容易看出，BIO主要的問題在于每當有一個新的用戶端請求接入時，服務端必須建立一個新的線程來處理這條鍊路，在需要滿足高性能、高并發的場景是沒法應用的（大量建立新的線程會嚴重影響伺服器性能，甚至罷工）。
為了改進這種一連接配接一線程的模型，我們可以使用線程池來管理這些線程（需要了解更多請參考前面提供的文章），實作1個或多個線程處理N個用戶端的模型（但是底層還是使用的同步阻塞I/O），通常被稱為“僞異步I/O模型“。
僞異步I/O模型圖：
實作很簡單，我們隻需要将建立線程的地方，交給線程池管理即可，隻需要改動剛剛的Server代碼即可：
測試運作結果是一樣的。
我們知道，如果使用CachedThreadPool線程池（不限制線程數量，如果不清楚請參考文首提供的文章），其實除了能自動幫我們管理線程（複用），看起來也就像是1:1的用戶端：線程數模型，而使用FixedThreadPool我們就有效的控制了線程的最大數量，保證了系統有限的資源的控制，實作了N:M的僞異步I/O模型。
但是，正因為限制了線程數量，如果發生大量并發請求，超過最大數量的線程就隻能等待，直到線程池中的有空閑的線程可以被複用。而對Socket的輸入流就行讀取時，會一直阻塞，直到發生：
有資料可讀
可用資料以及讀取完畢
發生空指針或I/O異常
是以在讀取資料較慢時（比如資料量大、網絡傳輸慢等），大量并發的情況下，其他接入的消息，隻能一直等待，這就是最大的弊端。
而後面即将介紹的NIO，就能解決這個難題。
JDK 1.4中的java.nio.*包中引入新的Java I/O庫，其目的是提高速度。實際上，“舊”的I/O包已經使用NIO重新實作過，即使我們不顯式的使用NIO程式設計，也能從中受益。速度的提高在檔案I/O和網絡I/O中都可能會發生，但本文隻讨論後者。
NIO我們一般認為是New I/O（也是官方的叫法），因為它是相對于老的I/O類庫新增的（其實在JDK 1.4中就已經被引入了，但這個名詞還會繼續用很久，即使它們在現在看來已經是“舊”的了，是以也提示我們在命名時，需要好好考慮），做了很大的改變。但民間跟多人稱之為Non-block I/O，即非阻塞I/O，因為這樣叫，更能展現它的特點。而下文中的NIO，不是指整個新的I/O庫，而是非阻塞I/O。
NIO提供了與傳統BIO模型中的Socket和ServerSocket相對應的SocketChannel和ServerSocketChannel兩種不同的套接字通道實作。
新增的着兩種通道都支援阻塞和非阻塞兩種模式。
阻塞模式使用就像傳統中的支援一樣，比較簡單，但是性能和可靠性都不好；非阻塞模式正好與之相反。
對于低負載、低并發的應用程式，可以使用同步阻塞I/O來提升開發速率和更好的維護性；對于高負載、高并發的（網絡）應用，應使用NIO的非阻塞模式來開發。
下面會先對基礎知識進行介紹。
Buffer是一個對象，包含一些要寫入或者讀出的資料。
在NIO庫中，所有資料都是用緩沖區處理的。在讀取資料時，它是直接讀到緩沖區中的；在寫入資料時，也是寫入到緩沖區中。任何時候通路NIO中的資料，都是通過緩沖區進行操作。
具體的緩存區有這些：ByteBuffe、CharBuffer、 ShortBuffer、IntBuffer、LongBuffer、FloatBuffer、DoubleBuffer。他們實作了相同的接口：Buffer。
我們對資料的讀取和寫入要通過Channel，它就像水管一樣，是一個通道。通道不同于流的地方就是通道是雙向的，可以用于讀、寫和同時讀寫操作。
底層的作業系統的通道一般都是全雙工的，是以全雙工的Channel比流能更好的映射底層作業系統的API。
Channel主要分兩大類：
SelectableChannel：使用者網絡讀寫
FileChannel：用于檔案操作
後面代碼會涉及的ServerSocketChannel和SocketChannel都是SelectableChannel的子類。
Selector是Java NIO 程式設計的基礎。
Selector提供選擇已經就緒的任務的能力：Selector會不斷輪詢注冊在其上的Channel，如果某個Channel上面發生讀或者寫事件，這個Channel就處于就緒狀态，會被Selector輪詢出來，然後通過SelectionKey可以擷取就緒Channel的集合，進行後續的I/O操作。
一個Selector可以同時輪詢多個Channel，因為JDK使用了epoll()代替傳統的select實作，是以沒有最大連接配接句柄1024/2048的限制。是以，隻需要一個線程負責Selector的輪詢，就可以接入成千上萬的用戶端。
代碼比傳統的Socket程式設計看起來要複雜不少。
直接貼代碼吧，以注釋的形式給出代碼說明。
NIO建立的Server源碼：
ServerHandle：
可以看到，建立NIO服務端的主要步驟如下：
打開ServerSocketChannel，監聽用戶端連接配接 綁定監聽端口，設定連接配接為非阻塞模式 建立Reactor線程，建立多路複用器并啟動線程 将ServerSocketChannel注冊到Reactor線程中的Selector上，監聽ACCEPT事件 Selector輪詢準備就緒的key Selector監聽到新的用戶端接入，處理新的接入請求，完成TCP三向交握，履歷實體鍊路 設定用戶端鍊路為非阻塞模式 将新接入的用戶端連接配接注冊到Reactor線程的Selector上，監聽讀操作，讀取用戶端發送的網絡消息 異步讀取用戶端消息到緩沖區 對Buffer編解碼，處理半包消息，将解碼成功的消息封裝成Task 将應答消息編碼為Buffer，調用SocketChannel的write将消息異步發送給用戶端
因為應答消息的發送，SocketChannel也是異步非阻塞的，是以不能保證一次能吧需要發送的資料發送完，此時就會出現寫半包的問題。我們需要注冊寫操作，不斷輪詢Selector将沒有發送完的消息發送完畢，然後通過Buffer的hasRemain()方法判斷消息是否發送完成。
還是直接上代碼吧，過程也不需要太多解釋了，跟服務端代碼有點類似。
Client：
ClientHandle：
首先運作伺服器，順便也運作一個用戶端：
我們也可以單獨運作用戶端，效果都是一樣的。
一次測試的結果：
1+2+3+4+5+6
伺服器收到消息：1+2+3+4+5+6
用戶端收到消息：21
1*2/3-4+5*6/7-8
伺服器收到消息：1*2/3-4+5*6/7-8
用戶端收到消息：-7.0476190476190474
運作多個用戶端，都是沒有問題的。
NIO 2.0引入了新的異步通道的概念，并提供了異步檔案通道和異步套接字通道的實作。
異步的套接字通道時真正的異步非阻塞I/O，對應于UNIX網絡程式設計中的事件驅動I/O（AIO）。他不需要過多的Selector對注冊的通道進行輪詢即可實作異步讀寫，進而簡化了NIO的程式設計模型。
直接上代碼吧。
Server：
AsyncServerHandler：
AcceptHandler：
ReadHandler：
OK，這樣就已經完成了，其實說起來也簡單，雖然代碼感覺很多，但是API比NIO的使用起來真的簡單多了，主要就是監聽、讀、寫等各種CompletionHandler。此處本應有一個WriteHandler的，确實，我們在ReadHandler中，以一個匿名内部類實作了它。
下面看用戶端代碼。
Client：
AsyncClientHandler：
WriteHandler：
這個API使用起來真的是很順手。
Test：
我們可以在控制台輸入我們需要計算的算數字元串，伺服器就會傳回結果，當然，我們也可以運作大量的用戶端，都是沒有問題的，以為此處設計為單例用戶端，是以也就沒有示範大量用戶端并發。
讀者可以自己修改Client類，然後開辟大量線程，并使用構造方法建立很多的用戶端測試。
下面是其中一次參數的輸出：
請輸入請求消息：
用戶端成功連接配接到伺服器...
連接配接的用戶端數：1
123456+789+456
伺服器收到消息: 123456+789+456
用戶端收到結果:124701
9526*56
伺服器收到消息: 9526*56
用戶端收到結果:533456
AIO是真正的異步非阻塞的，是以，在面對超級大量的用戶端，更能得心應手。
下面就比較一下，幾種I/O程式設計的優缺點。
先以一張表來直覺的對比一下：
具體選擇什麼樣的模型或者NIO架構，完全基于業務的實際應用場景和性能需求，如果用戶端很少，伺服器負荷不重，就沒有必要選擇開發起來相對不那麼簡單的NIO做服務端；相反，就應考慮使用NIO或者相關的架構了。
上文中服務端使用到的用于計算的工具類：
package com.anxpp.utils;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;
public final class Calculator {
private final static ScriptEngine jse = new ScriptEngineManager().getEngineByName("JavaScript");
public static Object cal(String expression) throws ScriptException{
return jse.eval(expression);
}
後續會寫一篇NIO架構Netty的教程，不過這段時間有一點小忙。