Java I/O 效能深度解析 (上)：從阻塞 I/O 到 NIO 的架構演進

前言：為什麼需要新的 I/O 模型？

在 Java 1.4 之前，標準 I/O (java.io) 採用阻塞模型：每個連線佔用一條執行緒。當連線數增長至數百上千，執行緒上下文切換、記憶體佔用 (每條約 512KB~1MB 棧空間) 成為系統瓶頸。Web 伺服器若採用「一連線一執行緒」，極易因執行緒耗盡而拒絕服務。JDK 1.4 引入 java.nio (New I/O)，以 Channel (通道)、Buffer (緩衝區)、Selector (選擇器) 三大核心組件，實現非阻塞、多路複用，讓少量執行緒即可處理大量並發連線。

傳統阻塞式 HTTP 伺服器架構 (Httpd)

核心邏輯

// 主迴圈：每個執行緒獨立運行
while (true) {
    Socket socket = serverSocket.accept(); // 阻塞等待連線
    handleRequest(socket);                 // 完整處理請求/回應
    socket.close();
}

特點與缺陷

• 優點：程式碼直觀、邏輯線性、除錯容易、無共享資源同步問題。
• 缺點：可擴展性差。連線數 = 執行緒數。大量閒置連線 (Keep-Alive) 或慢速客戶端會佔住執行緒，導致新連線無法受理。

NIO 非阻塞式 HTTP 伺服器架構 (NIOHttpd)

採用 Reactor 模式，拆分為四大角色協作：

關鍵協作流程

1. Acceptor 接收新連線：

   while (running) {
       SocketChannel sc = serverSocketChannel.accept(); // 非阻塞模式下可能返回 null
       if (sc != null) {
           sc.configureBlocking(false);
           connectionSelector.queue(new Connection(sc));
       }
   }

2. ConnectionSelector 事件迴圈：

   while (running) {
       int ready = selector.select(); // 阻塞直到有事件或 wakeup()
       registerQueuedConnections();   // 從佇列註冊新連線 (OP_READ)
       Set keys = selector.selectedKeys();
       for (SelectionKey key : keys) {
           Connection conn = (Connection) key.attachment();
           if (key.isReadable())  conn.readRequest();
           else if (key.isWritable()) conn.writeResponse();
       }
       keys.clear();
   }

3. Connection 狀態流轉：
   • 初始：註冊 OP_READ，分配請求緩衝區 (512 bytes)。
   • 讀取請求：socketChannel.read(buffer)，若未讀完整行 → 返回等待下次事件；若讀完 → 解析 HTTP → 若合法開啟 FileChannel 準備檔案 → 切換 key.interestOps(OP_WRITE) + selector.wakeup()。
   • 寫入回應：先寫入 HTTP 標頭 (responseLineBuffer)，再用 fileChannel.transferTo() 零拷貝傳送檔案內容 (上限 64KB/次 確保公平)。
   • 完成：key.cancel()、關閉 Channel。

架構比較總結

潛在優化點

• 多 Acceptor/Selector 組：利用多核 CPU，避免單 Selector 成為瓶頸。
• 無鎖佇列：替換 synchronized(queue) 為 ConcurrentLinkedQueue 或 LMAX Disruptor。
• Direct Buffer 複用：透過物件池減少 ByteBuffer.allocateDirect() 分配/GC 壓力。
• 零拷貝優化：transferTo() 依賴 OS `sendfile`，大檔案傳輸極高效。

下篇預告

下一篇將以數學模型量化分析兩者在不同並發數、檔案大小、客戶端頻寬下的處理時間差異，並給出具體倍數比較表格。