從實踐角度從新理解BIO和NIO

時間 2020-05-20

標籤實踐角度從新理解 bio nio 欄目 Netty 简体版

原文原文鏈接

前言

這段時間本身在看一些Java中BIO和NIO之類的東西，看了不少博客，發現各類關於NIO的概念說的天花亂墜頭頭是道，能夠說是很是的完整，可是整個看下來以後，本身對NIO仍是隻知其一;不知其二的狀態，因此這篇文章不會提到不少的概念，而是站在一個實踐的角度，寫一些我本身關於NIO的看法，站在實踐事後的高度下再回去看概念，應該對概念會有一個更好的理解。linux

實現一個簡易單線程服務器

要講明白BIO和NIO，首先咱們應該本身實現一個簡易的服務器，不用太複雜，單線程便可。編程

爲何使用單線程做爲演示

由於在單線程環境下能夠很好地對比出BIO和NIO的一個區別，固然我也會演示在實際環境中BIO的所謂一個請求對應一個線程的情況。windows

服務端

public class Server { public static void main(String[] args) { byte[] buffer = new byte[1024]; try { ServerSocket serverSocket = new ServerSocket(8080); System.out.println("服務器已啓動並監聽8080端口"); while (true) { System.out.println(); System.out.println("服務器正在等待鏈接..."); Socket socket = serverSocket.accept(); System.out.println("服務器已接收到鏈接請求..."); System.out.println(); System.out.println("服務器正在等待數據..."); socket.getInputStream().read(buffer); System.out.println("服務器已經接收到數據"); System.out.println(); String content = new String(buffer); System.out.println("接收到的數據:" + content); } } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

客戶端

public class Consumer { public static void main(String[] args) { try { Socket socket = new Socket("127.0.0.1",8080); socket.getOutputStream().write("向服務器發數據".getBytes()); socket.close(); } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

代碼解析

咱們首先建立了一個服務端類，在類中實現實例化了一個SocketServer並綁定了8080端口。以後調用accept方法來接收鏈接請求，而且調用read方法來接收客戶端發送的數據。最後將接收到的數據打印。數組

完成了服務端的設計後，咱們來實現一個客戶端，首先實例化Socket對象，而且綁定ip爲127.0.0.1（本機），端口號爲8080，調用write方法向服務器發送數據。緩存

運行結果

當咱們啓動服務器，但客戶端尚未向服務器發起鏈接時，控制檯結果以下：服務器

當客戶端啓動並向服務器發送數據後，控制檯結果以下：數據結構

結論

從上面的運行結果，首先咱們至少能夠看到，在服務器啓動後，客戶端尚未鏈接服務器時，服務器因爲調用了accept方法，將一直阻塞，直到有客戶端請求鏈接服務器。多線程

對客戶端功能進行擴展

在上文中，咱們實現的客戶端的邏輯主要是，創建Socket --> 鏈接服務器 --> 發送數據，咱們的數據是在鏈接服務器以後就當即發送的，如今咱們來對客戶端進行一次擴展，當咱們鏈接服務器後，不當即發送數據，而是等待控制檯手動輸入數據後，再發送給服務端。（服務端代碼保持不變）架構

代碼

public class Consumer { public static void main(String[] args) { try { Socket socket = new Socket("127.0.0.1",8080); String message = null; Scanner sc = new Scanner(System.in); message = sc.next(); socket.getOutputStream().write(message.getBytes()); socket.close(); sc.close(); } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

測試

當服務端啓動，客戶端尚未請求鏈接服務器時，控制檯結果以下：併發

當服務端啓動，客戶端鏈接服務端，但沒有發送數據時，控制檯結果以下：

當服務端啓動，客戶端鏈接服務端，而且發送數據時，控制檯結果以下：

結論

從上文的運行結果中咱們能夠看到，服務器端在啓動後，首先須要等待客戶端的鏈接請求（第一次阻塞），若是沒有客戶端鏈接，服務端將一直阻塞等待，而後當客戶端鏈接後，服務器會等待客戶端發送數據（第二次阻塞），若是客戶端沒有發送數據，那麼服務端將會一直阻塞等待客戶端發送數據。

服務端從啓動到收到客戶端數據的這個過程，將會有兩次阻塞的過程。這就是BIO的很是重要的一個特色，BIO會產生兩次阻塞，第一次在等待鏈接時阻塞，第二次在等待數據時阻塞。

BIO

在單線程條件下BIO的弱點

在上文中，咱們實現了一個簡易的服務器，這個簡易的服務器是以單線程運行的，其實咱們不難看出，當咱們的服務器接收到一個鏈接後，而且沒有接收到客戶端發送的數據時，是會阻塞在read()方法中的，那麼此時若是再來一個客戶端的請求，服務端是沒法進行響應的。換言之，在不考慮多線程的狀況下，BIO是沒法處理多個客戶端請求的。

BIO如何處理併發

在剛纔的服務器實現中，咱們實現的是單線程版的BIO服務器，不難看出，單線程版的BIO並不能處理多個客戶端的請求，那麼如何能使BIO處理多個客戶端請求呢。

其實不難想到，咱們只須要在每個鏈接請求到來時，建立一個線程去執行這個鏈接請求，就能夠在BIO中處理多個客戶端請求了，這也就是爲何BIO的其中一條概念是服務器實現模式爲一個鏈接一個線程，即客戶端有鏈接請求時服務器端就須要啓動一個線程進行處理。

多線程BIO服務器簡易實現

public class Server { public static void main(String[] args) { byte[] buffer = new byte[1024]; try { ServerSocket serverSocket = new ServerSocket(8080); System.out.println("服務器已啓動並監聽8080端口"); while (true) { System.out.println(); System.out.println("服務器正在等待鏈接..."); Socket socket = serverSocket.accept(); new Thread(new Runnable() { @Override public void run() { System.out.println("服務器已接收到鏈接請求..."); System.out.println(); System.out.println("服務器正在等待數據..."); try { socket.getInputStream().read(buffer); } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } System.out.println("服務器已經接收到數據"); System.out.println(); String content = new String(buffer); System.out.println("接收到的數據:" + content); } }).start(); } } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

運行結果

很明顯，如今咱們的服務器的狀態就是一個線程對應一個請求，換言之，服務器爲每個鏈接請求都建立了一個線程來處理。

多線程BIO服務器的弊端

多線程BIO服務器雖然解決了單線程BIO沒法處理併發的弱點，可是也帶來一個問題：若是有大量的請求鏈接到咱們的服務器上，可是卻不發送消息，那麼咱們的服務器也會爲這些不發送消息的請求建立一個單獨的線程，那麼若是鏈接數少還好，鏈接數一多就會對服務端形成極大的壓力。因此若是這種不活躍的線程比較多，咱們應該採起單線程的一個解決方案，可是單線程又沒法處理併發，這就陷入了一種很矛盾的狀態，因而就有了NIO。

NIO

NIO的引入

咱們先來看看單線程模式下BIO服務器的代碼，其實NIO須要解決的最根本的問題就是存在於BIO中的兩個阻塞，分別是等待鏈接時的阻塞和等待數據時的阻塞。

public class Server { public static void main(String[] args) { byte[] buffer = new byte[1024]; try { ServerSocket serverSocket = new ServerSocket(8080); System.out.println("服務器已啓動並監聽8080端口"); while (true) { System.out.println(); System.out.println("服務器正在等待鏈接..."); //阻塞1：等待鏈接時阻塞
                Socket socket = serverSocket.accept(); System.out.println("服務器已接收到鏈接請求..."); System.out.println(); System.out.println("服務器正在等待數據..."); //阻塞2：等待數據時阻塞
 socket.getInputStream().read(buffer); System.out.println("服務器已經接收到數據"); System.out.println(); String content = new String(buffer); System.out.println("接收到的數據:" + content); } } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

咱們須要再老調重談的一點是，若是單線程服務器在等待數據時阻塞，那麼第二個鏈接請求到來時，服務器是沒法響應的。若是是多線程服務器，那麼又會有爲大量空閒請求產生新線程從而形成線程佔用系統資源，線程浪費的狀況。

那麼咱們的問題就轉移到，如何讓單線程服務器在等待客戶端數據到來時，依舊能夠接收新的客戶端鏈接請求。

模擬NIO解決方案

若是要解決上文中提到的單線程服務器接收數據時阻塞，而沒法接收新請求的問題，那麼其實可讓服務器在等待數據時不進入阻塞狀態，問題不就迎刃而解了嗎？

第一種解決方案（等待鏈接時和等待數據時不阻塞）

public class Server { public static void main(String[] args) throws InterruptedException { ByteBuffer byteBuffer = ByteBuffer.allocate(1024); try { //Java爲非阻塞設置的類
            ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.bind(new InetSocketAddress(8080)); //設置爲非阻塞
            serverSocketChannel.configureBlocking(false); while(true) { SocketChannel socketChannel = serverSocketChannel.accept(); if(socketChannel==null) { //表示沒人鏈接
                    System.out.println("正在等待客戶端請求鏈接..."); Thread.sleep(5000); }else { System.out.println("當前接收到客戶端請求鏈接..."); } if(socketChannel!=null) { //設置爲非阻塞
                    socketChannel.configureBlocking(false); byteBuffer.flip();//切換模式 寫-->讀
                    int effective = socketChannel.read(byteBuffer); if(effective!=0) { String content = Charset.forName("utf-8").decode(byteBuffer).toString(); System.out.println(content); }else { System.out.println("當前未收到客戶端消息"); } } } } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

運行結果

不難看出，在這種解決方案下，雖然在接收客戶端消息時不會阻塞，可是又開始從新接收服務器請求，用戶根原本不及輸入消息，服務器就轉向接收別的客戶端請求了，換言之，服務器弄丟了當前客戶端的請求。

解決方案二（緩存Socket，輪詢數據是否準備好）

public class Server { public static void main(String[] args) throws InterruptedException { ByteBuffer byteBuffer = ByteBuffer.allocate(1024); List<SocketChannel> socketList = new ArrayList<SocketChannel>(); try { //Java爲非阻塞設置的類
            ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.bind(new InetSocketAddress(8080)); //設置爲非阻塞
            serverSocketChannel.configureBlocking(false); while(true) { SocketChannel socketChannel = serverSocketChannel.accept(); if(socketChannel==null) { //表示沒人鏈接
                    System.out.println("正在等待客戶端請求鏈接..."); Thread.sleep(5000); }else { System.out.println("當前接收到客戶端請求鏈接..."); socketList.add(socketChannel); } for(SocketChannel socket:socketList) { socket.configureBlocking(false); int effective = socket.read(byteBuffer); if(effective!=0) { byteBuffer.flip();//切換模式 寫-->讀
                        String content = Charset.forName("UTF-8").decode(byteBuffer).toString(); System.out.println("接收到消息:"+content); byteBuffer.clear(); }else { System.out.println("當前未收到客戶端消息"); } } } } catch (IOException e) { // TODO Auto-generated catch block
 e.printStackTrace(); } } }

運行結果

代碼解析

在解決方案一中，咱們採用了非阻塞方式，可是發現一旦非阻塞，等待客戶端發送消息時就不會再阻塞了，而是直接從新去獲取新客戶端的鏈接請求，這就會形成客戶端鏈接丟失，而在解決方案二中，咱們將鏈接存儲在一個list集合中，每次等待客戶端消息時都去輪詢，看看消息是否準備好，若是準備好則直接打印消息。

能夠看到，從頭至尾咱們一直沒有開啓第二個線程，而是一直採用單線程來處理多個客戶端的鏈接，這樣的一個模式能夠很完美地解決BIO在單線程模式下沒法處理多客戶端請求的問題，而且解決了非阻塞狀態下鏈接丟失的問題。

存在的問題（解決方案二）

從剛纔的運行結果中其實能夠看出，消息沒有丟失，程序也沒有阻塞。可是，在接收消息的方式上可能有些許不妥，咱們採用了一個輪詢的方式來接收消息，每次都輪詢全部的鏈接，看消息是否準備好，測試用例中只是三個鏈接，因此看不出什麼問題來，可是咱們假設有1000萬鏈接，甚至更多，採用這種輪詢的方式效率是極低的。

另外，1000萬鏈接中，咱們可能只會有100萬會有消息，剩下的900萬並不會發送任何消息，那麼這些鏈接程序依舊要每次都去輪詢，這顯然是不合適的。

真實NIO中如何解決

在真實NIO中，並不會在Java層上來進行一個輪詢，而是將輪詢的這個步驟交給咱們的操做系統來進行，他將輪詢的那部分代碼改成操做系統級別的系統調用（select函數，在linux環境中爲epoll），在操做系統級別上調用select函數，主動地去感知有數據的socket。

關於使用select/epoll和直接在應用層作輪詢的區別

咱們在以前實現了一個使用Java作多個客戶端鏈接輪詢的邏輯，可是在真正的NIO源碼中其實並非這麼實現的，NIO使用了操做系統底層的輪詢系統調用 select/epoll(windows:select,linux:epoll)，那麼爲何不直接實現而要去調用系統來作輪詢呢？

select底層邏輯

假設有A、B、C、D、E五個鏈接同時鏈接服務器，那麼根據咱們上文中的設計，程序將會遍歷這五個鏈接，輪詢每一個鏈接，獲取各自數據準備狀況，那麼和咱們本身寫的程序有什麼區別呢？

首先，咱們寫的Java程序其本質在輪詢每一個Socket的時候也須要去調用系統函數，那麼輪詢一次調用一次，會形成沒必要要的上下文切換開銷。

而Select會將五個請求從用戶態空間全量複製一份到內核態空間，在內核態空間來判斷每一個請求是否準備好數據，徹底避免頻繁的上下文切換。因此效率是比咱們直接在應用層寫輪詢要高的。

若是select沒有查詢到到有數據的請求，那麼將會一直阻塞（是的，select是一個阻塞函數）。若是有一個或者多個請求已經準備好數據了，那麼select將會先將有數據的文件描述符置位，而後select返回。返回後經過遍歷查看哪一個請求有數據。

select的缺點：

底層存儲依賴bitmap，處理的請求是有上限的，爲1024。
文件描述符是會置位的，因此若是當被置位的文件描述符須要從新使用時，是須要從新賦空值的。
fd（文件描述符）從用戶態拷貝到內核態仍然有一筆開銷。
select返回後還要再次遍歷，來獲知是哪個請求有數據。

poll函數底層邏輯

poll的工做原理和select很像，先來看一段poll內部使用的一個結構體。

struct pollfd{ int fd; short events; short revents; }

poll一樣會將全部的請求拷貝到內核態，和select同樣，poll一樣是一個阻塞函數，當一個或多個請求有數據的時候，也一樣會進行置位，可是它置位的是結構體pollfd中的events或者revents置位，而不是對fd自己進行置位，因此在下一次使用的時候不須要再進行從新賦空值的操做。poll內部存儲不依賴bitmap，而是使用pollfd數組的這樣一個數據結構，數組的大小確定是大於1024的。解決了select 一、2兩點的缺點。

epoll

epoll是最新的一種多路IO複用的函數。這裏只說說它的特色。

epoll和上述兩個函數最大的不一樣是，它的fd是共享在用戶態和內核態之間的，因此能夠沒必要進行從用戶態到內核態的一個拷貝，這樣能夠節約系統資源；另外，在select和poll中，若是某個請求的數據已經準備好，它們會將全部的請求都返回，供程序去遍歷查看哪一個請求存在數據，可是epoll只會返回存在數據的請求，這是由於epoll在發現某個請求存在數據時，首先會進行一個重排操做，將全部有數據的fd放到最前面的位置，而後返回（返回值爲存在數據請求的個數N），那麼咱們的上層程序就能夠沒必要將全部請求都輪詢，而是直接遍歷epoll返回的前N個請求，這些請求都是有數據的請求。

Java中BIO和NIO的概念

一般一些文章都是在開頭放上概念，可是我此次選擇將概念放在結尾，由於經過上面的實操，相信你們對Java中BIO和NIO都有了本身的一些理解，這時候再來看概念應該會更好理解一些了。

概念整理於：

https://blog.csdn.net/guanghuichenshao/article/details/79375967

先來個例子理解一下概念，以銀行取款爲例：

同步： 本身親自出馬持銀行卡到銀行取錢（使用同步IO時，Java本身處理IO讀寫）。

異步： 委託一小弟拿銀行卡到銀行取錢，而後給你（使用異步IO時，Java將IO讀寫委託給OS處理，須要將數據緩衝區地址和大小傳給OS(銀行卡和密碼)，OS須要支持異步IO操做API）。

阻塞： ATM排隊取款，你只能等待（使用阻塞IO時，Java調用會一直阻塞到讀寫完成才返回）。

非阻塞： 櫃檯取款，取個號，而後坐在椅子上作其它事，等號廣播會通知你辦理，沒到號你就不能去，你能夠不斷問大堂經理排到了沒有，大堂經理若是說還沒到你就不能去（使用非阻塞IO時，若是不能讀寫Java調用會立刻返回，當IO事件分發器會通知可讀寫時再繼續進行讀寫，不斷循環直到讀寫完成）。

Java對BIO、NIO的支持：

Java BIO (blocking I/O)： 同步並阻塞，服務器實現模式爲一個鏈接一個線程，即客戶端有鏈接請求時服務器端就須要啓動一個線程進行處理，若是這個鏈接不作任何事情會形成沒必要要的線程開銷，固然能夠經過線程池機制改善。

Java NIO (non-blocking I/O)： 同步非阻塞，服務器實現模式爲一個請求一個線程，即客戶端發送的鏈接請求都會註冊到多路複用器上，多路複用器輪詢到鏈接有I/O請求時才啓動一個線程進行處理。

BIO、NIO適用場景分析:

BIO方式適用於鏈接數目比較小且固定的架構，這種方式對服務器資源要求比較高，併發侷限於應用中，JDK1.4之前的惟一選擇，但程序直觀簡單易理解。

NIO方式適用於鏈接數目多且鏈接比較短（輕操做）的架構，好比聊天服務器，併發侷限於應用中，編程比較複雜，JDK1.4開始支持。