在學(xué)習(xí) Netty 框架前有一個話題是無法繞過的，就是：網(wǎng)絡(luò)編程 IO 模型，聽見 IO 模型有些同學(xué)就開始背八股文了，Java 常見 IO 模型有：

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

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

Socket 網(wǎng)絡(luò)編程

網(wǎng)絡(luò)編程中有一個重要的概念就是：Socket，我們簡單了解一下。

在網(wǎng)絡(luò)通信中，客戶端和服務(wù)端通過一個雙向的通信連接實現(xiàn)數(shù)據(jù)的交換，連接的任意一端都可稱為一個 Socket。

Talk is cheap， show me the diagram，Socket 網(wǎng)絡(luò)通信基本過程如下圖所示：

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

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

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

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

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

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

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

傳統(tǒng) BIO 模式

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

我們嘗試用一個 demo 來演示一下傳統(tǒng)的網(wǎng)絡(luò)編程：

服務(wù)端代碼：

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

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

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

效果演示：

服務(wù)端運行起來后，使用 telnet 命令來模擬客戶端發(fā)送消息:

telnet 127.0.0.1 8888

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

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

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

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

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

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

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

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

綜上所述，BIO 模式不能滿足大并發(fā)業(yè)務(wù)場景，僅適用于連接數(shù)目比較小且固定的架構(gòu)。

同步阻塞 BIO 模式

根據(jù)上面的例子我們再畫圖抽象一下 BIO 網(wǎng)絡(luò)編程場景：

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

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

NIO

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

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

「New」是相對于傳統(tǒng) BIO 來說的，在當(dāng)時確實挺新的;Non Blocking IO 又被稱為：同步非阻塞 IO，同步非阻塞體現(xiàn)在：

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

NIO 三大基礎(chǔ)組件

學(xué)習(xí) NIO必須得知道下面這三個基礎(chǔ)組件：

(1)Buffer(緩沖區(qū))

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

Buffer 緩沖區(qū)的底層實現(xiàn)是數(shù)組，根據(jù)數(shù)組類型可以細(xì)分為：ByteBuffe、CharBuffer、DoubleBuffer、FloatBuffer、IntBuffer、LongBuffer、ShortBuffer等。

(2)Channel(通道)

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

常見 Channel 通道類型：

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

Channel 與 Buffer 之間的關(guān)系：

每個 Channel 對應(yīng)一個 Buffer 緩沖區(qū)，永遠(yuǎn)無法將數(shù)據(jù)直接寫入到Channel或者從Channel中讀取數(shù)據(jù)。需要通過Buffer與Channel交互。

(3)Selector(多路復(fù)用器)

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

關(guān)于 select、poll、epoll 之間的對比，感興趣的小伙伴可以自行上網(wǎng)查詢。

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

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

基本的工作流程如下：

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

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

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

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

NIO 比 BIO 好用在哪?

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

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

NIO 存在的問題

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

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

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

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

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

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

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

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