原來(lái)你是這樣的 IO 模型
在學(xué)習(xí) Netty 框架前有一個(gè)話(huà)題是無(wú)法繞過(guò)的，就是：網(wǎng)絡(luò)編程 IO 模型，聽(tīng)見(jiàn) IO 模型有些同學(xué)就開(kāi)始背八股文了，Java 常見(jiàn) IO 模型有：
同步阻塞 BIO 同步非阻塞 NIO 異步非阻塞 AIO
今天跟大家一起重溫下這些知識(shí)點(diǎn)。
Socket 網(wǎng)絡(luò)編程
網(wǎng)絡(luò)編程中有一個(gè)重要的概念就是：Socket，我們簡(jiǎn)單了解一下。
在網(wǎng)絡(luò)通信中，客戶(hù)端和服務(wù)端通過(guò)一個(gè)雙向的通信連接實(shí)現(xiàn)數(shù)據(jù)的交換，連接的任意一端都可稱(chēng)為一個(gè) Socket。
Talk is cheap， show me the diagram，Socket 網(wǎng)絡(luò)通信基本過(guò)程如下圖所示：
總結(jié)一下流程，可以簡(jiǎn)單描述為這四步：
（1）服務(wù)端啟動(dòng)，監(jiān)聽(tīng)指定端口，等待客戶(hù)端連接；
（2）客戶(hù)端嘗試與服務(wù)端連接，建立可信數(shù)據(jù)傳輸通道；
（3）客戶(hù)端與服務(wù)端進(jìn)行數(shù)據(jù)交換；
（4）客戶(hù)端或者服務(wù)端斷開(kāi)連接，終止通信；
了解了基本流程，有些小伙伴可能對(duì) Socket 這玩意很感興趣了，Socket 到底是什么東西呢？Socket 中文翻譯過(guò)來(lái)就是套接字，是網(wǎng)絡(luò)通信對(duì)象的抽象表達(dá)，聽(tīng)起來(lái)還是很模糊，從編碼者視角來(lái)看，本質(zhì)上就是一套編程接口，是對(duì)復(fù)雜的 TCP/IP 協(xié)議進(jìn)行封裝供上層應(yīng)用使用，這樣總明白了吧。
那 Socket 對(duì)象一般包括什么東西呢？一般包括五種信息：連接使用的協(xié)議、本地主機(jī)的IP地址、本地進(jìn)程的協(xié)議端口、遠(yuǎn)端主機(jī)的IP地址、遠(yuǎn)端進(jìn)程的協(xié)議端口。從這里可以看到 Socket 包含的信息非常豐富，也就是說(shuō)拿到一個(gè) Socket 對(duì)象就相當(dāng)于知己知彼了。
傳統(tǒng) BIO 模式
上面小節(jié)從理論角度講解了什么是Socket，現(xiàn)在我們回到開(kāi)發(fā)語(yǔ)言實(shí)現(xiàn)層面上來(lái)，以 Java 為例，Java 語(yǔ)言從 1.0 版本就已經(jīng)封裝了 Socket 相關(guān)的接口供開(kāi)發(fā)者使用，對(duì)這部分代碼感興趣的小伙伴可以出門(mén)向左拐，在java.net 包下面查看源碼。
我們嘗試用一個(gè) demo 來(lái)演示一下傳統(tǒng)的網(wǎng)絡(luò)編程：
服務(wù)端代碼：
public?static?void?main(String[]?args)?throws?IOException?{
????????//?創(chuàng)建一個(gè)ServerSocket，監(jiān)聽(tīng)端口8888
????????ServerSocket?ss?=?new?ServerSocket(8888);
????????
????????//?循環(huán)方式監(jiān)聽(tīng)客戶(hù)端的請(qǐng)求
????????while?(true)?{
????????????//?這里一直會(huì)阻塞，直到客戶(hù)端連接上
????????????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ù)客戶(hù)端發(fā)送的消息
????????????byte[]?bytes?=?new?byte[1024];
????????????int?len;
????????????while?((len?=?bufferedInputStream.read(bytes))?!=?-1)?{
????????????????printStream.print("服務(wù)端收到："?+?new?String(bytes,?0,?len));
????????????}
????????}
????}
效果演示：
服務(wù)端運(yùn)行起來(lái)后，使用 telnet 命令來(lái)模擬客戶(hù)端發(fā)送消息:
telnet?127.0.0.1?8888
客戶(hù)端每發(fā)送一條消息，服務(wù)端都會(huì)回復(fù)，演示效果如下：
仔細(xì)想一下，上面的代碼可能會(huì)有問(wèn)題，如果前面一個(gè)客戶(hù)端一直不斷開(kāi)，服務(wù)端就不能處理其他客戶(hù)端的消息了，也就是說(shuō)程序不具備并發(fā)的能力。
我們稍加改造一下，將前面的處理邏輯代碼全部抽取到一個(gè)新的handle()方法， 每當(dāng)有客戶(hù)端連接上就新開(kāi)一個(gè)線(xiàn)程處理：
public?static?void?main(String[]?args)?throws?IOException?{
????//?創(chuàng)建一個(gè)ServerSocket，監(jiān)聽(tīng)端口8888
????ServerSocket?ss?=?new?ServerSocket(8888);
????//?循環(huán)方式監(jiān)聽(tīng)客戶(hù)端的請(qǐng)求
????while?(true)?{
????????//?這里一直會(huì)阻塞，直到客戶(hù)端連接上
????????Socket?socket?=?ss.accept();
????????//?啟動(dòng)一個(gè)新的線(xiàn)程處理
????????new?Thread(()?->?handle(socket)).start();
????}
}
這里為了演示方便直接新起了一個(gè)線(xiàn)程，當(dāng)然更好的辦法是用線(xiàn)程池，但是也解決不了根本性問(wèn)題。
看了兩段代碼，先簡(jiǎn)單總結(jié)一下 BIO 模式的劣勢(shì)：
如果 BIO 使用單線(xiàn)程接收連接，則會(huì)阻塞其他連接，效率較低。 如果使用多線(xiàn)程，雖然減弱了單線(xiàn)程帶來(lái)的影響，但當(dāng)有大并發(fā)進(jìn)來(lái)時(shí)，會(huì)導(dǎo)致服務(wù)器線(xiàn)程太多，壓力太大而崩潰。 就算使用線(xiàn)程池，也只能同時(shí)允許有限個(gè)數(shù)的線(xiàn)程進(jìn)行連接，如果并發(fā)量遠(yuǎn)大于線(xiàn)程池設(shè)置的數(shù)量，還是與單線(xiàn)程無(wú)異。 IO 代碼里 read 操作是阻塞操作，如果連接不做數(shù)據(jù)讀寫(xiě)操作會(huì)導(dǎo)致線(xiàn)程阻塞，就是說(shuō)只占用連接，不發(fā)送數(shù)據(jù)，則會(huì)浪費(fèi)資源。比如線(xiàn)程池中 500個(gè)連接，只有 100 個(gè)是頻繁讀寫(xiě)的連接，其他占著茅坑不拉屎，浪費(fèi)資源！ 另外多線(xiàn)程也會(huì)有線(xiàn)程切換帶來(lái)的消耗。
綜上所述，BIO 模式不能滿(mǎn)足大并發(fā)業(yè)務(wù)場(chǎng)景，僅適用于連接數(shù)目比較小且固定的架構(gòu)。
同步阻塞 BIO 模式
根據(jù)上面的例子我們?cè)佼?huà)圖抽象一下 BIO 網(wǎng)絡(luò)編程場(chǎng)景：
傳統(tǒng) BIO 的特點(diǎn)是只要來(lái)了一個(gè)新客戶(hù)端連接，服務(wù)端就會(huì)開(kāi)辟一個(gè)線(xiàn)程處理客戶(hù)端請(qǐng)求，但是客戶(hù)端連接后并不是一直都對(duì)服務(wù)端進(jìn)行 IO 操作，這樣會(huì)導(dǎo)致服務(wù)端阻塞，一直占用著線(xiàn)程資源，造成很多非要的開(kāi)銷(xiāo)。
為了解決這個(gè)問(wèn)題，Java 引入了 NIO，我們接著往下看。
NIO
在 Java 1.4 版本之前 BIO 是開(kāi)發(fā)者唯一的選擇，1.4 版本開(kāi)始引入了 NIO 框架。
NIO 的 N 有兩層含義，一層是：New IO，另一層是 Non Blocking IO。
「New」是相對(duì)于傳統(tǒng) BIO 來(lái)說(shuō)的，在當(dāng)時(shí)確實(shí)挺新的；Non Blocking IO 又被稱(chēng)為：同步非阻塞 IO，同步非阻塞體現(xiàn)在：
同步：調(diào)用的結(jié)果會(huì)在本次調(diào)用后返回，不存在異步線(xiàn)程回調(diào)之類(lèi)的。 非阻塞：表現(xiàn)為線(xiàn)程不會(huì)一直在等待，把連接加入集合后，線(xiàn)程會(huì)一直輪詢(xún)集合中的連接，有則處理，無(wú)則繼續(xù)接受請(qǐng)求。
NIO 三大基礎(chǔ)組件
學(xué)習(xí) NIO必須得知道下面這三個(gè)基礎(chǔ)組件：
（1）Buffer(緩沖區(qū))
IO 是面向流（字節(jié)流或者字符流）的，而 NIO 是面向塊的，塊指的是 Buffer 緩沖區(qū)。面向塊的方式一次性可以獲取或者寫(xiě)入一整塊數(shù)據(jù)，而不需要一個(gè)字節(jié)一個(gè)字節(jié)的從流中讀取，這樣處理數(shù)據(jù)的速度會(huì)比流方式更快。
Buffer 緩沖區(qū)的底層實(shí)現(xiàn)是數(shù)組，根據(jù)數(shù)組類(lèi)型可以細(xì)分為：ByteBuffe、CharBuffer、DoubleBuffer、FloatBuffer、IntBuffer、LongBuffer、ShortBuffer等。
（2）Channel(通道)
Channel 翻譯成中文是通道的意思，作用類(lèi)似于 IO 中的 Stream 流。但是 Channel 和 Stream 不同之處在于 Channel 是雙向的，Stream 只是在一個(gè)方向移動(dòng)，而且 Channel 可以用于讀、寫(xiě)或者同時(shí)用于讀寫(xiě)。
常見(jiàn) Channel 通道類(lèi)型：
FileChannel 用于文件操作場(chǎng)景； ServerSocketChannel 和 SocketChannel 主要用于 TCP 網(wǎng)絡(luò)通信 IO，這是本文的重點(diǎn)； DatagramChannel: 從 UDP 網(wǎng)絡(luò)中讀取或者寫(xiě)入數(shù)據(jù)。
Channel 與 Buffer 之間的關(guān)系：
每個(gè) Channel 對(duì)應(yīng)一個(gè) Buffer 緩沖區(qū)，永遠(yuǎn)無(wú)法將數(shù)據(jù)直接寫(xiě)入到Channel或者從Channel中讀取數(shù)據(jù)。需要通過(guò)Buffer與Channel交互。
（3）Selector(多路復(fù)用器)
NIO 服務(wù)端的實(shí)現(xiàn)模式是把多個(gè)連接(請(qǐng)求)放入集合中，只用一個(gè)線(xiàn)程可以處理多個(gè)請(qǐng)求(連接)，也就是多路復(fù)用，Linux 環(huán)境下多路復(fù)用底層主要用的是內(nèi)核函數(shù)（select，poll）來(lái)實(shí)現(xiàn)的，為了提升效率，Java 1.5 版本開(kāi)始使用 epoll。
關(guān)于 select、poll、epoll 之間的對(duì)比，感興趣的小伙伴可以自行上網(wǎng)查詢(xún)。
在 NIO 中多路復(fù)用器我們稱(chēng)之為：Selector，Channel 會(huì)注冊(cè)到 Selector 上，由 Selector 根據(jù) Channel 讀寫(xiě)事件的發(fā)生將其交由某個(gè)空閑的線(xiàn)程處理。
Buffer、Channel、Selector 這三個(gè)組件的之間的關(guān)系可以用下面的圖來(lái)描述：
基本的工作流程如下：
（1）首先將 Channel 注冊(cè)到 Selector 中；
（2）初始化 Selector，調(diào)用 select() 方法，select 方法會(huì)阻塞直到感興趣的事件來(lái)臨；
（3）當(dāng)某個(gè) Channel 有連接或者讀寫(xiě)事件時(shí)，該 Channel 就會(huì)處于就緒狀態(tài)；
（4）Selector 開(kāi)始輪詢(xún)所有處于就緒狀態(tài)的SelectionKey，通過(guò) SelectionKey 可以獲取對(duì)應(yīng)的Channel 集合；
NIO 比 BIO 好用在哪？
NIO 相對(duì)于 BIO 最大的改進(jìn)就是使用了多路復(fù)用技術(shù)，用少量線(xiàn)程處理大量客戶(hù)端 IO 請(qǐng)求，提高了并發(fā)量并減少了資源消耗；
另外NIO 的操作時(shí)非阻塞的，比如說(shuō)，單線(xiàn)程中從通道讀取數(shù)據(jù)到buffer，同時(shí)可以繼續(xù)做別的事情，當(dāng)數(shù)據(jù)讀取到buffer中后，線(xiàn)程再繼續(xù)處理數(shù)據(jù)。寫(xiě)數(shù)據(jù)也是一樣的。
NIO 存在的問(wèn)題
NIO這么牛了，是不是就是終極解決方案了？其實(shí)也不是，NIO 也存在很多問(wèn)題。
我們來(lái)看看 NIO 有哪些問(wèn)題？
（1）NIO 的 API 使用起來(lái)非常麻煩，門(mén)檻比較高，開(kāi)發(fā)者需要熟練掌握：Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等類(lèi)。
（2）NIO 編程涉及到 Reactor 模式，開(kāi)發(fā)者需要對(duì)多線(xiàn)程和網(wǎng)絡(luò)編程非常熟悉才能寫(xiě)出高質(zhì)量的 NIO 程序；
（3）異常場(chǎng)景處理麻煩，比如：客戶(hù)端斷連重連、網(wǎng)絡(luò)閃斷、拆包粘包、網(wǎng)絡(luò)擁塞等等；
（4）NIO 有 bug，不穩(wěn)定，比如：臭名昭著的 Epoll bug，會(huì)導(dǎo)致 Selector 空輪詢(xún)，最終導(dǎo)致 CPU 100%。
NIO 問(wèn)題這么多，有些開(kāi)發(fā)者終于不能忍了，最終 Netty 框架橫空出世。
Netty 框架到底解決了什么問(wèn)題，有哪些優(yōu)秀的特性，我們下期接著聊。
-- End --
昨天買(mǎi)了一個(gè)電腦支架，終于可以把兩個(gè)筆記本放在一塊了，目前桌面上的線(xiàn)比較凌亂，下一步買(mǎi)個(gè)線(xiàn)盒好好整理下，桌面干凈了，人也開(kāi)心了??
推薦學(xué)習(xí)：
好了，今天的技術(shù)文就到這里了。我是雷小帥，一個(gè)死磕技術(shù)的理工男，如果本文對(duì)你有幫助，麻煩點(diǎn)贊、分享、在看支持一下，非常感謝~