Java System.in 輸入流阻塞機制深度解析

問題背景

在 Java 開發中，處理標準輸入流 System.in 時，初學者常會遇到一個疑惑：讀取文件時遇到 EOF 會返回 null 並退出循環，但從控制台讀取時，若不輸入內容，程序究竟阻塞在哪裡？為什麼它不會持續循環調用 readLine()？

核心原因

直接導致阻塞的正是這行代碼：

str = br.readLine();

當你輸入完畢按下回車後，程序會進入第二次等待輸入的狀態。在 BufferedReader 內部，有一個 fill 方法會持續監聽控制台輸入，直到有數據可讀才會返回。這就是為什麼程序會「卡住」等待用戶輸入，而不是像讀取文件那樣直接結束。

深入理解

System.in 是一個輸入流，默認連接到鍵盤。與文件輸入流不同，控制台輸入流沒有明確的「文件結尾」標記（除非用戶主動發送 EOF 信號，如 Windows 下的 Ctrl+Z 或 Linux/Mac 下的 Ctrl+D）。因此 readLine() 會一直阻塞，直到讀到換行符或 EOF。

圖示說明

最佳實踐建議

• 使用多線程處理控制台輸入，避免阻塞主線程
• 在需要退出循環時，提供明確的退出命令（如輸入 "exit"）
• 理解 BufferedReader 的緩衝機制，合理設置緩衝區大小