Java NIO 是一種非阻塞的、面向塊而非字節的 IO 方式。雖然 Java 的傳統 IO 也進行了一些基于 NIO 的改造，NIO 仍然能夠帶來許多優勢。

面向流的 IO 方便我們一個字節一個字節地處理數據，有利于實現過濾等功能，更加優雅和簡單。相應地，其速度通常比較慢。

Java NIO 的模型由三部分組成。Channel 通道，類似于傳統 IO 中的流，用來實際傳輸數據。

Buffer 緩沖，我們用來讀取和發送數據的位置。

Selector 選擇器，可以在一個線程上綁定多個 Channel 和對應的 Buffer 。

Channel

Channel 和流非常相似。區別是，通道支持異步讀寫，支持雙向讀寫，而且基于緩沖區。相比之下，流通常是單向同步讀寫的。

常用的 Channel 主要包括：FileChannel 文件

DatagramChannel UDP數據報

SocketChannel TCP 套接字

ServerSocketChannel TCP 服務端套接字

Buffer

Java 中的各種基本類型都有其對應的 Buffer ，最常用的是 ByteBuffer ?？梢酝ㄟ^ Channel 或者手動寫入數據。

然后，要從 buffer 中讀取數據，需要首先 flip() 它，變成讀取模式。

需要注意的是，很多 Channel ,如 FileChannel 和非阻塞模式下的 SocketChannel 的 write 方法并不能保證將 buffer 全部寫入文件。因此，要使用循環來處理：

下面是一個簡單的輸出文件內容的示例：

InputStream 和 OutputStream 類也有類似的 getChannel 方法。當然，這樣開啟的通道只能是單向的。下面是一個將輸入內容傳輸到輸出的可復用的代碼片段：

Scatter / Gather

Scatter 和 Gather 可以譯為分散和聚集，指的是向同一個通道寫入和讀出多個 Buffer 的過程。在處理復雜結構的數據，如 Header-Content 時，有利于代碼整潔。Scatter Read 指從一個 Channel 讀取到多個 Buffer ，Gather Write 指從多個 Buffer 寫入到一個 Channel 。關于網絡的內容還會在后面進一步解釋。

網絡和異步 IO

異步 IO 的模式實際上來自于操作系統，如 Linux 的 IO 復用和 Windows 的 IOCP 。因此，類似的編程模式很可能也適用于其他語言。

TCP 異步 IO 的例子

異步 IO 不會阻塞，這也使得它可以處理許多的 IO 連接。在傳統 IO 下，這通常需要通過輪詢或多線程來實現。

首先回顧一下普通的 IO 編程中處理 TCP 連接的方法：ServerSocket 類監聽端口，客戶端的 Socket 類構造時發出連接請求。這時，ServerSocket.accept() 從阻塞中脫離，返回服務端的 Socket 對象。

然后，我們來看異步處理的方法：

這里的 SelectionKey.OP_ACCEPT 是適用于 ServerSocketChannel 的唯一事件，即 TCP 連接建立的事件。

select() 方法會阻塞直到有任何一個連接建立。selectedKeys 返回一個 Set 對象。在異步 IO 的類似處理過程中，由于我們已經通過 select 得到了這個連接信息，就不必再擔心 accept 會阻塞：

可以看到，我們將 accept 得到的結果重新放回了 selector 的監聽列表，并且將監聽事件修改為了 SelectionKey.OP_READ ，即有數據到達的事件。這個過程和傳統 IO 中從 ServerSocket.accept() 獲得 Socket 的過程類似。

然后，在 if 語句的另一個分支，我們來處理接收數據的過程。使用 channel() 方法得到雙向讀寫的通道對象。隨后，我們就可以使用之前熟悉的 buffer 來處理這個連接了。

最后，我們需要把處理結束的連接從 keys 中刪除，以免重復處理。在實際的應用場景中，我們還需要把關閉的連接從 Selector 中去除，并且很有可能使用多線程。

SelectionKey

上面我們見到了 OP_READ 和 OP_ACCEPT 。除此之外，NIO 還有 OP_WRITE 和 OP_CONNECT 兩種事件?？梢哉J為每個事件代表“就緒”：例如當連接另一方傳來數據時，連接處于“讀就緒”狀態，對應事件 OP_READ 。因此，寫就緒和連接就緒這兩種事件并不常用。

四種事件的值分別為 1、2、8、16，因此可以使用位操作來處理這些事件。例如：

相應地，SelecttionKey 也提供了一些處理這些信息的方法。

還可以為每個 SectionKey 附加一個對象，以方便識別類似的對象。

Selector

除了 select() 方法外，Selector 類同樣提供了帶有超時的阻塞方法和非阻塞，允許返回 0 的方法。

如果在阻塞期間調用 Selector 的 wakeUp() 方法(當然，是在另一個線程里)，線程會立刻放棄阻塞。在操作結束之后，需要使用 Selector.close() 方法。這將會使所有的 SelectionKey 都無效，但并不會關閉 Channel 。

異步 IO 設計

概述

阻塞 IO 和異步 IO 的區別是顯而易見的。阻塞 IO 是一種成功的設計，它能夠保證 IO 的可靠和簡單。但在這種模式下，每個 IO 都需要單獨的一個線程來處理。在 JVM 的默認參數下，32 bit 系統的一個棧為 320kB ，64 bit 下更達到了 1MB ，在高并發情況下這是完全無法接受的。線程池是解決這個問題的一種途徑，但當我們面臨大量低速長鏈接的時候，問題仍然沒有被徹底解決。而這正是大規模互聯網應用的常態。因此，異步 IO 成為了必然的選擇。異步 IO 的最典型特征是，每一次檢查不再是阻塞或獲得整塊數據，而是0或數據。這雖然解決了多線程的問題，卻帶來了另外一些需要解決的問題。

異步 IO 首先要解決的問題是，怎樣用一個線程處理許多連接。于是，我們有了 Selector ，使用一個 Selector 來處理許多連接，以實現“阻塞直到有一個”的效果，而不需要去處理那些尚未讀到數據的連接。于是，線程資源被充分地利用起來。

第二個問題是，由于所有的操作都被立即返回，異步 IO 下讀到的數據不總是完整的。甚至，在連續傳輸的情況下，幾乎總是不完整的。于是，我們需要做兩件事：判斷當前的數據是否是完整的

將不完整的數據暫存起來，以備下一次傳輸時拼合起來。

于是，我們在 Selector 與 Channel 之間加入一個 Message Reader，用來處理這些工作。在工程化的實踐中，我們可能希望這套系統能夠處理各種不同的協議。因此，可能會接收一個 Message Reader 的工廠作為參數，以進行依賴注入。

Message Reader 的實現

前面我們看到，Message Reader 需要能夠在內部的一個 Buffer 中存儲不完整的 Message 。顯而易見，這個 buffer 的大小應該等于消息的最大值。但這時我們又遇到了之前說的內存不足的問題：百萬級別的 1 MB buffer 意味著 1 TB 的 RAM 空間。因此，我們需要在這里使用可伸縮的(flexible)buffer 。

拷貝擴容

一種常見的方法是熟悉的拷貝擴容，也就是當 buffer 已滿后將所有內容復制到一個更大的數組中去。在這種方式下， threshold 的 選取就是一個重要的問題。例如，假設一個系統的請求消息不大于 4 kB ，傳輸的文件通常不大于 128 kB ，更大的文件則沒有規律性。那么，我們就會將 threshold 設置為 4kB 和 128 kB ，將最終的內存占用控制在 GB 級別。

追加擴容

另一種常見的方式是追加(append)擴容，方法是用一個列表將所有小的 buffer 片段集合起來，或者將一個大的數組分片，再用列表來管理分片。后者在內存模型上會更有利一些，但需要對并發量的準確判斷。追加擴容的缺點也很明顯，維護和讀取都比較復雜。

使用 TLV 消息

許多協議，包括 HTTP/2 在內，開始使用 TLV 格式的消息。TLV 指的是 Type-Length-Value 的元組。對于這類消息，我們可以在一開始就知道消息的長度，并為其開辟好內存空間，避免了上面的方式中對內存資源的浪費。

當然，TLV 格式也有其缺點。對于很長的 TLV 消息，我們就需要很大的內存空間的預開辟，這也為 DoS 攻擊提供了空間。一種解決方案是使用分段 TLV 的消息格式，但這并不能徹底解決問題。另一種方式是為消息設置超時時間。這樣，服務器至少能夠在一段時間的無響應后恢復。

寫不完整的消息

前面已經提到，非阻塞模式的通道并不能對一次 write() 實際寫入的數據量做出保證，而是將寫入的數據的字節數返回給調用者。于是，為了進一步解耦和提高效率，我們還需要在數據處理者和 Channel 同樣準備一個 Message Writer ，用來處理這個不穩定的輸出過程。

回過頭來想，我們在這里并不想為每個連接都維護一個線程。因此，我們只希望對有消息可寫的 Writer 進行處理。因此，我們使用這樣一個過程：

當 Message Writer 有消息可寫時，才將其對應的 Channel 注冊到 Selector 。然后，服務器在空閑時檢查 Selector 來獲取可寫的 Channel ，并尋找其對應的 Writer 以寫入數據。在 Writer 已經沒有數據可寫時，將 Channel 從 Selector 上解綁。

集成

現在我們已經理清了輸入和輸出兩個部分，現在我們從整個服務器的角度來思考。總的來說，一個服務器會執行這樣一個循環：

從 ServerSocket 中獲取 Socket => Select 讀事件 => 將接受的數據交給 Reader 來處理 => 在核心部分處理 Reader 傳來的完整數據 => 將處理后的數據交給 Writer => Select 寫事件

當然，這些功能還可以在多個線程內完成。

總結

以上是生活随笔為你收集整理的java nio 对消息分片_Java NIO：应用的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。