網絡編程陷阱：InputStream.read() 在 Socket 中的阻塞行為差異

核心差異

致命陷阱：while ((len = in.read(buf)) != -1) 死循環

// 服務端處理客戶端請求
InputStream in = socket.getInputStream();
byte[] buf = new byte[1024];
int len;
while ((len = in.read(buf)) != -1) { // 陷阱！
    process(buf, len);
}
// 這裡永遠執行不到，除非客戶端關閉連接

**原因**：客戶端發完一個請求後**不關閉連接**（保持長連接等待響應），服務端 `read()` 一直阻塞等待下一個請求或連接關閉，導致無法跳出循環處理業務、發送響應。

正確處理模式

1. 協議幀分隔（推薦）

• **定長頭部**：前 4 字節標示消息體長度
• **分隔符**：換行符 `\n`、自定義分隔符
• **序列化框架**：Protobuf、Thrift、Kryo 自帶幀解碼

// 伪代碼：長度前綴協議
DataInputStream dis = new DataInputStream(socket.getInputStream());
while (true) {
    int length = dis.readInt(); // 讀取 4 字節長度
    byte[] body = new byte[length];
    dis.readFully(body);        // 精確讀取消息體
    process(body);
    sendResponse();
}

2. 單請求單連接（短連接）

• 客戶端發送請求 → `shutdownOutput()` → 服務端讀到 -1 → 處理 → 響應 → 雙方關閉
• 缺點：連接建立開銷大，不適合高頻交互

3. 非阻塞 I/O (NIO) + Selector

• 註冊 `OP_READ`，有數據時回調處理
• Netty/Mina 等框架已封裝完善，生產環境首選

圖解對比

總結

**Socket 流無 EOF 概念**，`read()` 返回 -1 **唯一條件是對端關閉輸出**。長連接場景下，**必須引入應用層協議幀**界定消息邊界，否則業務邏輯將永遠卡在讀取循環中。這是從文件 IO 轉向網絡編程時最核心的認知重構。