Java IO流实战：用字节缓冲流复制大文件，效率提升300%的秘诀-CSDN博客

Java IO流实战：用字节缓冲流复制大文件，效率提升300%的秘诀

如果你曾经用Java处理过几百兆甚至几个G的大文件，大概率经历过那种“看着进度条缓慢蠕动”的煎熬。普通的FileInputStream和FileOutputStream在应对小文件时还算顺手，一旦数据量上来，性能瓶颈立刻暴露无遗。我印象很深，之前有个项目需要定期同步几个GB的日志文件，最初用最基础的字节流，复制一个文件要等上好几分钟，CPU占用还不低。后来经过一系列调优，特别是引入了字节缓冲流并调整了策略，最终将耗时缩短到了原来的四分之一，效率提升实实在在超过了300%。这不仅仅是换一个类那么简单，背后涉及到缓冲区的工作原理、JVM的I/O模型以及操作系统的交互机制。这篇文章，我就结合真实的测试数据和踩过的坑，跟你聊聊怎么让Java文件复制飞起来。

1. 为什么普通字节流在大文件面前如此“乏力”？

要理解缓冲流为什么快，首先得明白为什么不用缓冲会慢。Java的I/O操作，最终都要通过JVM调用操作系统的原生接口。当你调用inputStream.read()读取一个字节时，看似简单的一行代码，底层却发生了一系列昂贵的操作：从用户态切换到内核态，触发一次系统调用，操作系统从磁盘读取数据（即使只读一个字节，磁盘也是按块读取的），再将数据从内核缓冲区拷贝到用户空间（即你的Java程序内存）。这个过程，我们称之为一次上下文切换和数据拷贝。

关键问题在于，如果逐字节读写，那么处理一个1GB的文件，就需要进行大约10亿次（1GB / 1 Byte）这样的完整流程。每一次系统调用的开销，相对于实际的数据传输时间来说，都是巨大的浪费。这就像你每次只从仓库搬一粒米到厨房，绝大部分时间都花在了来回跑的路上，而不是在搬运本身。

我们可以用一个简单的测试来直观感受一下这种差异。下面是一个对比普通字节流和缓冲流复制文件的代码框架：

public class IOBenchmark {

    public static void copyWithBasicStream(File source, File target) throws IOException {
        try (FileInputStream fis = new FileInputStream(source);
             FileOutputStream fos = new FileOutputStream(target)) {
            int byteRead;
            while ((byteRead = fis.read()) != -1) { // 逐字节读取
                fos.write(byteRead);
            }
        }
    }

    public static void copyWithBufferedStream(File source, File target) throws IOException {
        try (BufferedInputStream bis = new BufferedInputStream(new FileInputStream(source));
             BufferedOutputStream bos = new BufferedOutputStream(new FileOutputStream(target))) {
            int byteRead;
            while ((byteRead = bis.read()) != -1) { // 注意：这里依然是逐字节读取，但底层已缓冲
                bos.write(byteRead);
            }
        }
    }
}

注意：上面copyWithBufferedStream方法中，虽然我们写的循环是逐字节read()和write()，但BufferedInputStream内部已经维护了一个缓冲区（默认8KB）。它的read()方法会尝试先从缓冲区取数据，缓冲区空了才会进行一次大的系统调用填充8KB数据。写入操作同理。这才是性能提升的关键，编程接口的简洁性被保留，而底层实现了批量化操作。

为了更量化地看清差距，我找了一个512MB的测试文件，在相同的硬件环境下运行，得到如下结果：