一、 Java I/O 模型演進史：從阻塞到事件驅動
網路 I/O 本質上是作業系統核心與硬體網卡之間的資料搬移。Java 經歷了三次重大變革：

1. BIO（Blocking I/O，傳統阻塞型）

• 模型：ServerSocket.accept() 與 InputStream.read() 皆為阻塞呼叫。
• 架構：典型的 One Thread Per Connection（一個連線配置一個執行緒）。
• 致命瓶頸：當用戶端連線建立後若未發送資料，服務端執行緒只能死等，造成昂貴的執行緒資源被閒置佔用
  面對萬級併發（C10K 問題），系統會因建立過多 OS 執行緒而爆發記憶體耗盡（OOM）與劇烈的 Context Switch 崩潰。

2. NIO（Non-blocking I/O / New I/O，JDK 1.4+）

• 模型：基於多路複用（I/O Multiplexing）與緩衝區驅動。
• 核心哲學：由「執行緒死等資料」轉化為「事件通知機制」。少數幾個執行緒即可監控成千上萬個網路連線的讀寫狀態。

3. AIO（Asynchronous I/O，NIO.2 / JDK 7+）

• 模型：真正的非同步非阻塞，基於作業系統的 Proactor 模式。
• 現狀：在 Linux 底層缺乏如 Windows IOCP 般高效成熟的非同步核心機制（Linux 仍依賴 epoll 模擬），因此在主流 Java 生態中，高效能網路通訊（如 Netty）仍全面以 NIO + epoll 為絕對核心。

二、 Java 原生 NIO 三大基石架構

1. Channel（雙向通道）

• 類似傳統的 Stream，但 Stream 是單向的（只能 Read 或 Write），而 Channel 是全雙工的（雙向可讀可寫）。
• 常見實作：SocketChannel（TCP 客戶端）、ServerSocketChannel（TCP 服務端）、FileChannel（檔案操作）。

2. Buffer（資料緩衝區）

• 所有資料的讀寫都必須經過Buffer，其本質是一塊記憶體陣列，搭配三個核心指標維護狀態：
  • capacity：緩衝區最大容量，配置後不可變更。
  • position：下一個即將被讀取或寫入的元素索引位置。
  • limit：當前允許操作的邊界上限（寫入模式下等於 capacity，讀取模式下等於實際寫入的資料量）。
• 讀寫切換關鍵方法：flip()：
  • 將limit設為當前position，並將position重置歸零（position = 0），使 Buffer 從「寫入模式」切換為「讀取模式」。

3. Selector（多路複用選擇器）

• 利用單一執行緒持續輪詢（Polling）註冊在其上的多個Channel。
• Channel透過位元遮罩向 Selector 註冊感興趣的事件：
  • SelectionKey.OP_ACCEPT（連線到達）
  • SelectionKey.OP_CONNECT（連線建立成功）
  • SelectionKey.OP_READ（資料可讀）
  • SelectionKey.OP_WRITE（緩衝區可寫）
• 當某個Channel發生事件時，Selector才會喚醒工作執行緒處理，徹底擺脫BIO執行緒無效空轉的困境。

三、為什麼生產環境不直接寫原生 Java NIO？
幾乎所有分散式中介軟體（Dubbo、RocketMQ、Elasticsearch、Spark）的網路層都放棄了Java原生 NIO，原因如下：
API 極其繁複且不易維護：ByteBuffer的flip()、compact()、clear() 指針轉換極易出錯；黏包與半包（Packet Fragmentation）需開發者完全手動處理。
斷線重連與心跳機制繁重：網路閃斷、慢速連線、半關閉狀態等邊界異常處理極度複雜。
臭名昭著的JDK Epoll Bug（CPU 100% 死迴圈）：
在特定Linux核心條件下，即使沒有任何就緒事件，Selector.select() 也會被異常喚醒，導致輪詢迴圈瘋狂空轉，CPU 瞬間打滿至 100%。

四、 Netty 核心架構解析與極致效能密碼
Netty 是基於 Java NIO 封裝的非同步事件驅動網路通訊框架，它在底層進行了大量的工業級工程最佳化：

1. 主從 Reactor 執行緒模型
   • BossGroup：專門負責監聽端口，接收客戶端連線並生成SocketChannel。
   • WorkerGroup：接收BossGroup移交的Channel，負責資料解碼、業務處理與編碼寫回，二者職責徹底分離。
2. ChannelPipeline 與 ChannelHandler 責任鏈架構
   • 每個連線對應一個ChannelPipeline，內部由一條雙向鏈結串列組成。
   • 資料進入時依序通過ChannelInboundHandler（解碼、權限驗證、業務處理）。
   • 資料寫出時依序通過ChannelOutboundHandler（業務包裝、編碼、壓縮、實體發送）。
3. 解決JDK Epoll空輪詢Bug
   • Netty內部維護一個計數器：若在預設短時間內select()連續被空喚醒超過閥值（預設 512 次）。
   • Netty會自動重新建立一個全新的Selector，將原selector上所有的Channel重新註冊搬遷過去，並關閉舊的Selector，無縫化解CPU 100%危機。
4. 零拷貝（Zero-Copy）工程實踐
   • Netty的零拷貝不單指作業系統層級的 sendfile，還包含框架層級的記憶體最佳化：
   • ByteBuf取代ByteBuffer：讀寫指標獨立分離，免除flip() 切換痛苦，且支援自動動態擴容。
   • Direct Buffer：直接在作業系統記憶體配置緩衝區，資料發送時無需再經過JVM Heap往Direct Buffer的二次拷貝。
   • CompositeByteBuf（組合緩衝區）：將多個不同的Buffer在邏輯上合併成單一視圖，避免因封裝 Header 與 Body 產生記憶體合併拷貝。
   • FileRegion系統級零拷貝：透過 FileChannel.transferTo()直接利用作業系統的DMA引擎將磁碟檔案搬移至網卡，完全繞過CPU與使用者態記憶體。