在學習 Netty 框架前有一個話題是無法繞過的，就是：網絡編程 IO 模型，聽見 IO 模型有些同學就開始背八股文了，Java 常見 IO 模型有：

• 同步阻塞 BIO
• 同步非阻塞 NIO
• 異步非阻塞 AIO

今天跟大家一起重溫下這些知識點。

Socket 網絡編程

網絡編程中有一個重要的概念就是：Socket，我們簡單了解一下。

在網絡通信中，客戶端和服務端通過一個雙向的通信連接實現數據的交換，連接的任意一端都可稱為一個 Socket。

Talk is cheap， show me the diagram，Socket 網絡通信基本過程如下圖所示：

總結一下流程，可以簡單描述為這四步：

(1)服務端啟動，監聽指定端口，等待客戶端連接;

(2)客戶端嘗試與服務端連接，建立可信數據傳輸通道;

(3)客戶端與服務端進行數據交換;

(4)客戶端或者服務端斷開連接，終止通信;

了解了基本流程，有些小伙伴可能對 Socket 這玩意很感興趣了，Socket 到底是什么東西呢?Socket 中文翻譯過來就是套接字，是網絡通信對象的抽象表達，聽起來還是很模糊，從編碼者視角來看，本質上就是一套編程接口，是對復雜的 TCP/IP 協議進行封裝供上層應用使用，這樣總明白了吧。

那 Socket 對象一般包括什么東西呢?一般包括五種信息：連接使用的協議、本地主機的IP地址、本地進程的協議端口、遠端主機的IP地址、遠端進程的協議端口。從這里可以看到 Socket 包含的信息非常豐富，也就是說拿到一個 Socket 對象就相當于知己知彼了。

傳統 BIO 模式

上面小節從理論角度講解了什么是Socket，現在我們回到開發語言實現層面上來，以 Java 為例，Java 語言從 1.0 版本就已經封裝了 Socket 相關的接口供開發者使用，對這部分代碼感興趣的小伙伴可以出門向左拐，在java.net 包下面查看源碼。

我們嘗試用一個 demo 來演示一下傳統的網絡編程：

服務端代碼：

public static void main(String[] args) throws IOException {
        // 創建一個ServerSocket，監聽端口8888
        ServerSocket ss = new ServerSocket(8888);
        
        // 循環方式監聽客戶端的請求
        while (true) {
            // 這里一直會阻塞，直到客戶端連接上
            Socket socket = ss.accept();

            // 輸入流用于接收消息
            InputStream inputStream = socket.getInputStream();
            BufferedInputStream bufferedInputStream = new BufferedInputStream(inputStream);
            
            // 輸出流用于回復消息
            OutputStream outputStream = socket.getOutputStream();
            final PrintStream printStream = new PrintStream(outputStream);

            // 循環接收并回復客戶端發送的消息
            byte[] bytes = new byte[1024];
            int len;
            while ((len = bufferedInputStream.read(bytes)) != -1) {
                printStream.print("服務端收到：" + new String(bytes, 0, len));
            }
        }
    }

效果演示：

服務端運行起來后，使用 telnet 命令來模擬客戶端發送消息:

telnet 127.0.0.1 8888

客戶端每發送一條消息，服務端都會回復，演示效果如下：

仔細想一下，上面的代碼可能會有問題，如果前面一個客戶端一直不斷開，服務端就不能處理其他客戶端的消息了，也就是說程序不具備并發的能力。

我們稍加改造一下，將前面的處理邏輯代碼全部抽取到一個新的handle()方法， 每當有客戶端連接上就新開一個線程處理：

public static void main(String[] args) throws IOException {
    // 創建一個ServerSocket，監聽端口8888
    ServerSocket ss = new ServerSocket(8888);

    // 循環方式監聽客戶端的請求
    while (true) {
        // 這里一直會阻塞，直到客戶端連接上
        Socket socket = ss.accept();
        // 啟動一個新的線程處理
        new Thread(() -> handle(socket)).start();
    }
}

這里為了演示方便直接新起了一個線程，當然更好的辦法是用線程池，但是也解決不了根本性問題。

看了兩段代碼，先簡單總結一下 BIO 模式的劣勢：

• 如果 BIO 使用單線程接收連接，則會阻塞其他連接，效率較低。
• 如果使用多線程，雖然減弱了單線程帶來的影響，但當有大并發進來時，會導致服務器線程太多，壓力太大而崩潰。
• 就算使用線程池，也只能同時允許有限個數的線程進行連接，如果并發量遠大于線程池設置的數量，還是與單線程無異。
• IO 代碼里 read 操作是阻塞操作，如果連接不做數據讀寫操作會導致線程阻塞，就是說只占用連接，不發送數據，則會浪費資源。比如線程池中 500個連接，只有 100 個是頻繁讀寫的連接，其他占著茅坑不拉屎，浪費資源!
• 另外多線程也會有線程切換帶來的消耗。

綜上所述，BIO 模式不能滿足大并發業務場景，僅適用于連接數目比較小且固定的架構。

同步阻塞 BIO 模式

根據上面的例子我們再畫圖抽象一下 BIO 網絡編程場景：

傳統 BIO 的特點是只要來了一個新客戶端連接，服務端就會開辟一個線程處理客戶端請求，但是客戶端連接后并不是一直都對服務端進行 IO 操作，這樣會導致服務端阻塞，一直占用著線程資源，造成很多非要的開銷。

為了解決這個問題，Java 引入了 NIO，我們接著往下看。

NIO

在 Java 1.4 版本之前 BIO 是開發者唯一的選擇，1.4 版本開始引入了 NIO 框架。

NIO 的 N 有兩層含義，一層是：New IO，另一層是 Non Blocking IO。

「New」是相對于傳統 BIO 來說的，在當時確實挺新的;Non Blocking IO 又被稱為：同步非阻塞 IO，同步非阻塞體現在：

• 同步：調用的結果會在本次調用后返回，不存在異步線程回調之類的。
• 非阻塞：表現為線程不會一直在等待，把連接加入集合后，線程會一直輪詢集合中的連接，有則處理，無則繼續接受請求。

NIO 三大基礎組件

學習 NIO必須得知道下面這三個基礎組件：

(1)Buffer(緩沖區)

IO 是面向流(字節流或者字符流)的，而 NIO 是面向塊的，塊指的是 Buffer 緩沖區。面向塊的方式一次性可以獲取或者寫入一整塊數據，而不需要一個字節一個字節的從流中讀取，這樣處理數據的速度會比流方式更快。

Buffer 緩沖區的底層實現是數組，根據數組類型可以細分為：ByteBuffe、CharBuffer、DoubleBuffer、FloatBuffer、IntBuffer、LongBuffer、ShortBuffer等。

(2)Channel(通道)

Channel 翻譯成中文是通道的意思，作用類似于 IO 中的 Stream 流。但是 Channel 和 Stream 不同之處在于 Channel 是雙向的，Stream 只是在一個方向移動，而且 Channel 可以用于讀、寫或者同時用于讀寫。

常見 Channel 通道類型：

• FileChannel 用于文件操作場景;
• ServerSocketChannel 和 SocketChannel 主要用于 TCP 網絡通信 IO，這是本文的重點;
• DatagramChannel: 從 UDP 網絡中讀取或者寫入數據。

Channel 與 Buffer 之間的關系：

每個 Channel 對應一個 Buffer 緩沖區，永遠無法將數據直接寫入到Channel或者從Channel中讀取數據。需要通過Buffer與Channel交互。

(3)Selector(多路復用器)

NIO 服務端的實現模式是把多個連接(請求)放入集合中，只用一個線程可以處理多個請求(連接)，也就是多路復用，Linux 環境下多路復用底層主要用的是內核函數(select，poll)來實現的，為了提升效率，Java 1.5 版本開始使用 epoll。

關于 select、poll、epoll 之間的對比，感興趣的小伙伴可以自行上網查詢。

在 NIO 中多路復用器我們稱之為：Selector，Channel 會注冊到 Selector 上，由 Selector 根據 Channel 讀寫事件的發生將其交由某個空閑的線程處理。

Buffer、Channel、Selector 這三個組件的之間的關系可以用下面的圖來描述：

基本的工作流程如下：

(1)首先將 Channel 注冊到 Selector 中;

(2)初始化 Selector，調用 select() 方法，select 方法會阻塞直到感興趣的事件來臨;

(3)當某個 Channel 有連接或者讀寫事件時，該 Channel 就會處于就緒狀態;

(4)Selector 開始輪詢所有處于就緒狀態的SelectionKey，通過 SelectionKey 可以獲取對應的Channel 集合;

NIO 比 BIO 好用在哪?

NIO 相對于 BIO 最大的改進就是使用了多路復用技術，用少量線程處理大量客戶端 IO 請求，提高了并發量并減少了資源消耗;

另外NIO 的操作時非阻塞的，比如說，單線程中從通道讀取數據到buffer，同時可以繼續做別的事情，當數據讀取到buffer中后，線程再繼續處理數據。寫數據也是一樣的。

NIO 存在的問題

NIO這么牛了，是不是就是終極解決方案了?其實也不是，NIO 也存在很多問題。

我們來看看 NIO 有哪些問題?

(1)NIO 的 API 使用起來非常麻煩，門檻比較高，開發者需要熟練掌握：Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等類。

(2)NIO 編程涉及到 Reactor 模式，開發者需要對多線程和網絡編程非常熟悉才能寫出高質量的 NIO 程序;

(3)異常場景處理麻煩，比如：客戶端斷連重連、網絡閃斷、拆包粘包、網絡擁塞等等;

(4)NIO 有 bug，不穩定，比如：臭名昭著的 Epoll bug，會導致 Selector 空輪詢，最終導致 CPU 100%。

NIO 問題這么多，有些開發者終于不能忍了，最終 Netty 框架橫空出世。

Netty 框架到底解決了什么問題，有哪些優秀的特性，我們下期接著聊。