Java Process.waitFor() 深度解析：阻塞陷阱、緩衝區死鎖與多線程讀取最佳實踐

前言

Java 透過 Runtime.exec() 或 ProcessBuilder.start() 啟動外部程式（如 ffmpeg、notepad.exe、Shell 腳本）時，會回傳 Process 物件。開發者常呼叫 waitFor() 等待子進程結束，但若不當處理標準輸出/錯誤流，極易導致主線程永久阻塞甚至死鎖。本文從原理、陷阱、實測代碼到生產級解法完整剖析。

一、基礎認知：Process 與三條管道

JVM 啟動子進程時，會在父子進程間建立三條管道：

• 標準輸入 (Process.getOutputStream())：父寫、子讀。
• 標準輸出 (Process.getInputStream())：子寫、父讀。
• 標準錯誤 (Process.getErrorStream())：子寫、父讀。

作業系統為每條管道分配有限緩衝區（通常 4KB~64KB）。若子進程大量輸出而父進程不讀取，緩衝區寫滿 → 子進程阻塞於 write() → 父進程阻塞於 waitFor() → 雙向死鎖。

二、waitFor() 行為與 JDK 文檔警示

public abstract int waitFor() throws InterruptedException;

• 導致當前線程阻塞，直到子進程終止。
• 若子進程已結束，立即返回退出碼。
• JDK 明確警告：若不及時讀取輸出/錯誤流，緩衝區滿會導致子進程卡死，進而使 waitFor() 永不返回。

三、實測重現：記事本與 ffmpeg 案例

錯誤示範 1：直接 waitFor()

Process p = Runtime.getRuntime().exec("notepad.exe");
p.waitFor(); // 必須手動關閉記事本才會繼續
System.out.println("我想被列印...");

現象：主線程卡在 waitFor()，直到使用者關閉視窗。若子程式為無介面批次處理（如 ffmpeg），且輸出量大於緩衝區，程式會永久卡死。

錯誤示範 2：同步區塊包裹判斷但未讀流

synchronized (Process.class) {
    if (p == null) p = Runtime.getRuntime().exec(cmd);
}
p.waitFor(); // 依然會死鎖

同步只能解決多線程競態，無法解決管道緩衝區滿的問題。

四、正確解法：雙線程消費輸出流與錯誤流

核心原則：在 waitFor() 前啟動兩條守護線程，持續讀乾輸出流與錯誤流，排空緩衝區。

生產級代碼範本（以 ffmpeg 轉碼為例）

Runtime rt = Runtime.getRuntime();
String command = "cmd /c ffmpeg -loglevel quiet -i " + srcPath 
               + " -ab " + bitrate + "k -acodec libmp3lame " + desFile;

try {
    Process p = rt.exec(command, null, new File("C:\\ffmpeg\\bin"));

    // 1. 取得輸出流與錯誤流
    final InputStream stdout = p.getInputStream();
    final InputStream stderr = p.getErrorStream();

    // 2. 線程 A：消費標準輸出
    new Thread(() -> {
        try (BufferedReader br = new BufferedReader(new InputStreamReader(stdout))) {
            String line;
            while ((line = br.readLine()) != null) {
                // 可選：記錄日誌、解析進度
                // System.out.println("[STDOUT] " + line);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }).start();

    // 3. 線程 B：消費標準錯誤（關鍵！ffmpeg 大量資訊輸出到 stderr）
    new Thread(() -> {
        try (BufferedReader br = new BufferedReader(new InputStreamReader(stderr))) {
            String line;
            while ((line = br.readLine()) != null) {
                // 可選：記錄錯誤、解析進度
                // System.err.println("[STDERR] " + line);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
    }).start();

    // 4. 等待子進程結束
    int exitCode = p.waitFor();
    
    // 5. 可選：強制銷毀（防殭屍進程）
    p.destroy(); 
    
    System.out.println("轉碼完成，exitCode=" + exitCode);
    
} catch (IOException | InterruptedException e) {
    e.printStackTrace();
}

五、關鍵細節與避坑指南

1. 必須同時讀取 stdout 與 stderr：許多 CLI 工具（ffmpeg、maven、gradle）將進度、警告寫入 stderr，忽略 stderr 等同自殺。
2. 使用 try-with-resources (Java 7+)：自動關閉流，防止資源洩漏。
3. 線程設為守護線程：thread.setDaemon(true)，避免主程式結束時這兩條線程阻塞 JVM 退出。
4. 超時控制 (Java 9+)：改用 p.waitFor(timeout, TimeUnit.SECONDS) 避免無限等待。
5. ProcessBuilder 替代 Runtime.exec()：支援環境變數、工作目錄、參數列表傳遞，更安全且可讀性高。

ProcessBuilder 現代寫法

ProcessBuilder pb = new ProcessBuilder("ffmpeg", "-i", srcPath, "-ab", bitrate+"k", desFile);
pb.directory(new File("C:\\ffmpeg\\bin")); // 設定工作目錄
pb.redirectErrorStream(true); // 合併 stderr 到 stdout，單線程即可讀取（簡化場景適用）

Process p = pb.start();
// 單線程讀取合併後的流...
int exitCode = p.waitFor();

六、總結

waitFor() 本身無毒，毒在未被讀取的管道緩衝區。掌握「啟動子進程 → 立即啟動讀取線程排空 stdout/stderr → 再呼叫 waitFor()」這套標準流程，並善用 ProcessBuilder.redirectErrorStream(true) 簡化代碼，即可徹底解決 Java 呼叫外部程式的阻塞與死鎖問題。