我试图弄清楚当我们使用 nio FileChannel 与普通 FileInputStream/FileOuputStream 读取和写入文件时，性能(或优势)是否有任何差异文件系统。我观察到，在我的机器上，两者的性能都一样，而且很多时候 FileChannel 的方式都比较慢。我可以知道比较这两种方法的更多细节吗？这是我使用的代码，我正在测试的文件大约是 350MB。如果我不考虑随机访问或其他此类高级功能，那么将基于 NIO 的类用于文件 I/O 是否是一个不错的选择？

package trialjavaprograms;

import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.nio.ByteBuffer;
import java.nio.channels.FileChannel;

public class JavaNIOTest {
    public static void main(String[] args) throws Exception {
        useNormalIO();
        useFileChannel();
    }

    private static void useNormalIO() throws Exception {
        File file = new File("/home/developer/test.iso");
        File oFile = new File("/home/developer/test2");

        long time1 = System.currentTimeMillis();
        InputStream is = new FileInputStream(file);
        FileOutputStream fos = new FileOutputStream(oFile);
        byte[] buf = new byte[64 * 1024];
        int len = 0;
        while((len = is.read(buf)) != -1) {
            fos.write(buf, 0, len);
        }
        fos.flush();
        fos.close();
        is.close();
        long time2 = System.currentTimeMillis();
        System.out.println("Time taken: "+(time2-time1)+" ms");
    }

    private static void useFileChannel() throws Exception {
        File file = new File("/home/developer/test.iso");
        File oFile = new File("/home/developer/test2");

        long time1 = System.currentTimeMillis();
        FileInputStream is = new FileInputStream(file);
        FileOutputStream fos = new FileOutputStream(oFile);
        FileChannel f = is.getChannel();
        FileChannel f2 = fos.getChannel();

        ByteBuffer buf = ByteBuffer.allocateDirect(64 * 1024);
        long len = 0;
        while((len = f.read(buf)) != -1) {
            buf.flip();
            f2.write(buf);
            buf.clear();
        }

        f2.close();
        f.close();

        long time2 = System.currentTimeMillis();
        System.out.println("Time taken: "+(time2-time1)+" ms");
    }
}

最佳答案

我对较大文件大小的经验是 java.nio 比 java.io 快。 确实更快。就像在 >250% 的范围内。也就是说，我正在消除明显的瓶颈，我建议您的微基准可能会受到影响。潜在的调查领域:

缓冲区大小。你基本上拥有的算法是

• 从磁盘复制到缓冲区
• 从缓冲区复制到磁盘

我自己的经验是，这个缓冲区大小成熟可以进行调整。我已经为我的应用程序的一部分设置了 4KB，另一部分设置为 256KB。我怀疑您的代码正在遭受如此大的缓冲区的影响。使用 1KB、2KB、4KB、8KB、16KB、32KB 和 64KB 的缓冲区运行一些基准测试，向自己证明这一点。

不要执行读取和写入同一磁盘的 Java 基准测试。

如果你这样做了，那么你实际上是在对磁盘进行基准测试，而不是 Java。我还建议，如果您的 CPU 不忙，那么您可能遇到了其他瓶颈。

如果不需要，请勿使用缓冲区。

如果您的目标是另一个磁盘或 NIC，为什么要复制到内存？对于较大的文件，产生的延迟是不小的。

正如其他人所说，使用 FileChannel.transferTo() 或 FileChannel.transferFrom()。这里的关键优势是 JVM 使用操作系统对 DMA (Direct Memory Access) 的访问(如果存在)。 (这取决于实现，但通用 CPU 上的现代 Sun 和 IBM 版本是不错的选择。) 发生的情况是数据直接进出磁盘，到达总线，然后到达目的地...通过 RAM 或 CPU 绕过任何电路。

我日夜工作的 Web 应用程序的 IO 非常繁重。我也做过微观基准和真实世界的基准。结果在我的博客上，看看吧:

• Real world performance metrics: java.io vs. java.nio
• Real world performance metrics: java.io vs. java.nio (The Sequel)

使用生产数据和环境

微基准容易失真。如果可以的话，请努力在您期望的硬件上，以您期望的负载，从您计划做的事情中收集数据。

我的基准测试是可靠的，因为它们发生在生产系统、功能强大的系统、负载下的系统上，并以日志形式收集。 不是我的笔记本电脑的 7200 RPM 2.5"SATA 驱动器，而我则密切注视着 JVM 运行我的硬盘。

你在做什么？这很重要。

关于Java NIO FileChannel 与 FileOutputstream 性能/实用性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1605332/