Java I/O 讀寫單位為何用 int 而非 byte/char？JVM 預設運算單元與歷史緣由

現象

InputStream.read()  // 回傳 int (0-255 或 -1)
OutputStream.write(int b) // 參數 int，僅取低 8 位
Reader.read()     // 回傳 int (0-65535 或 -1)
Writer.write(int c) // 參數 int，僅取低 16 位

但批次讀寫卻用 byte[]/char[]。

核心原因

1. JVM 預設整數運算為 int：Java 虛擬機規範規定，byte、short、char 參與運算時會**自動提升為 int** 進行運算，結果再截斷回原類型。I/O 方法回傳/參數直接用 int，避免呼叫端額外轉型與提升開銷。
2. 歷史硬體架構：早期 32 位 CPU 自然字長為 32 位（int），單次載入/運算 32 位最高效。byte/char 需額外指令擴展/截斷。
3. 特殊值表示：-1 表示「流結束」（EOF），若回傳 byte（-128~127）或 char（無符號 0~65535）無法同時表示有效資料與 EOF，int 完美涵蓋 -1 與所有合法位元組/字元值。

批次讀寫為何用陣列？

• 效能：單次系統呼叫傳輸大塊資料，減少 JNI/系統呼叫開銷。
• 記憶體局部性：連續陣列利於 CPU 快取預取。
• API 設計一致性：read(byte[]) 回傳實際讀取位元組數（int），write(byte[]) 無回傳值，語意清晰。

程式碼示範：單位元轉型

int b = in.read();
if (b != -1) {
    byte actualByte = (byte) b; // 安全轉型，因 b 在 0-255 範圍
    out.write(actualByte);      // 自動提升為 int 傳遞
}

總結

單位元介面用 int：承載 EOF(-1) 與完整值域、符合 JVM 運算習慣、歷史效能考量。
批次介面用陣列：追求吞吐量、減少呼叫開銷。
此設計兼顧正確性、效能與跨平台一致性，是 Java I/O 經典 API 設計智慧的體現。