Java 文件複製與緩衝機制：性能瓶頸的深度探測

前言

Windows 檔案複製速度似乎有個「天花板」。本文通過實測對比系統複製與 Java 緩衝流複製，揭示硬體 I/O 才是真正瓶頸，並分析 BufferedInputStream 預設 8KB 緩衝區的設計考量。

一、實測場景與代碼

測試代碼：16KB 緩衝區複製

public void copyByte(String srcFile, String destFile) throws IOException {
    InputStream in = new FileInputStream(srcFile);
    OutputStream out = new FileOutputStream(destFile);
    byte[] buf = new byte[16384]; // 16KB
    int len;
    System.out.println("開始複製....");
    System.out.println(System.currentTimeMillis());
    while ((len = in.read(buf)) != -1) {
        out.write(buf, 0, len); // 關鍵：寫入實際讀取長度
    }
    System.out.println(System.currentTimeMillis());
    System.out.println("複製結束....");
    in.close();
    out.close();
}

修正提示：原文 out.write(buf) 會寫入整個緩衝區導致檔案損壞，必須用 out.write(buf, 0, len)。

二、實測數據對比（860MB 檔案）

三、核心發現：硬體才是瓶頸

1. 演算法無法突破物理極限：無論如何優化複製邏輯，速度上限由「磁碟讀寫速度 + CPU 處理能力 + 總線頻寬」決定。
2. 緩衝區大小有「最佳點」：8KB 太小導致系統調用頻繁；16KB 已飽和磁碟吞吐；再大無增益，反而增加記憶體壓力。
3. 外接高速磁碟（NVMe/RAID）才能提升上限：軟體優化只能逼近硬體極限，不能突破。

四、BufferedInputStream 源碼啟示

private static int defaultBufferSize = 8192; // 8KB

JDK 選擇 8KB 作為預設值，是基於以下權衡：

• **頁面大小對齊**：x86 頁面 4KB，8KB 為 2 頁，利於 OS 預讀。
• **通用性**：適用於網路流、管道、檔案等多種場景，檔案複製可手動調大。
• **記憶體友善**：避免大量併發流佔用過多堆外/堆內記憶體。

五、進階優化方向（突破單流極限）

1. NIO 零拷貝

try (FileChannel in = FileChannel.open(Paths.get(src), StandardOpenOption.READ);
     FileChannel out = FileChannel.open(Paths.get(dest), StandardOpenOption.WRITE, StandardOpenOption.CREATE)) {
    in.transferTo(0, in.size(), out); // OS 級零拷貝，避免用戶態/核心態切換
}

2. 多執行緒分段複製（大檔案）

• 將檔案分割為多段，並行讀寫（需 SSD/RAID 支援並行 I/O）。
• 注意：機械硬碟多執行緒反而因磁頭抖動降低效能。

3. 直接記憶體

ByteBuffer buffer = ByteBuffer.allocateDirect(1024 * 1024); // 1MB 直接緩衝區
// 配合 FileChannel.read/write 使用

六、總結

1. Java 檔案複製速度在 16KB 緩衝區即達到硬體極限，與系統複製持平。
2. BufferedInputStream 8KB 預設值兼顧通用性，高效能檔案複製建議手動調大至 16KB-64KB 或改用 NIO transferTo。
3. 真正的提升來自硬體升級（NVMe、RAID、更大記憶體），而非單純演算法調優。
4. 下次遇到「複製慢」，先跑 dd if=/dev/zero of=test bs=1M count=1024 測磁碟速度，再怪代碼。