Java NIO FileChannel 与 FileOutputstream 性能/实用性

Question

我试图弄清楚当我们使用 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");
    }
}

Answer 1

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

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

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

我自己的经验是，这个缓冲区大小是成熟< /em> 用于调整。我已确定应用程序的一部分为 4KB，另一部分为 256KB。我怀疑你的代码正在遭受如此大的缓冲区的困扰。使用 1KB、2KB、4KB、8KB、16KB、32KB 和 64KB 的缓冲区运行一些基准测试来向自己证明这一点。

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

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

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

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

就像其他人所说的那样，使用 FileChannel.transferTo() 或 FileChannel.transferFrom() 。这里的主要优点是 JVM 使用操作系统对 DMA 的访问（直接内存访问），如果展示。 （这取决于实现，但通用 CPU 上的现代 Sun 和 IBM 版本已经很不错了。） 发生的情况是数据直接往返于磁盘、总线，然后到达目的地...通过 RAM 或 CPU 绕过任何电路。

我日以继夜开发的网络应用程序的 IO 量非常大。我也做过微观基准测试和现实世界基准测试。结果在我的博客上，看看：

• 现实世界性能指标：java.io 与 java.nio
• 真实世界性能指标：java.io vs. java.nio（续集）

使用生产数据和环境

微基准测试容易失真。如果可以的话，请努力从您计划执行的操作、您期望的负载、您期望的硬件上收集数据。

我的基准测试是可靠的，因为它们是在生产系统上进行的，一个强大的系统，一个负载下的系统，收集在日志中。 不是我的笔记本电脑的 7200 RPM 2.5" SATA 驱动器，而我密切关注 JVM 运行我的硬盘。

您在运行什么？这很重要。

Answer 2

如果您想要比较的是文件复制的性能，那么对于通道测试，您应该这样做：

final FileInputStream inputStream = new FileInputStream(src);
final FileOutputStream outputStream = new FileOutputStream(dest);
final FileChannel inChannel = inputStream.getChannel();
final FileChannel outChannel = outputStream.getChannel();
inChannel.transferTo(0, inChannel.size(), outChannel);
inChannel.close();
outChannel.close();
inputStream.close();
outputStream.close();

这不会比从一个通道缓冲到另一个通道慢，并且可能会快得多。根据 Javadoc：

许多操作系统可以将字节直接从文件系统缓存传输到目标通道，而无需实际复制它们。

Answer 3

回答问题的“有用性”部分：

在 FileOutputStream 上使用 FileChannel 的一个相当微妙的问题是执行其任何阻塞操作（例如 read()< /code> 或 write()) 来自 中断状态将导致通道突然关闭 java.nio.channels.ClosedByInterruptException。

现在，如果 FileChannel 的用途是线程主函数的一部分，并且设计考虑到了这一点，那么这可能是一件好事。

但如果由某些辅助功能（例如日志记录功能）使用，它也可能会很麻烦。例如，如果日志记录函数恰好被也被中断的线程调用，您可能会发现日志输出突然关闭。

不幸的是，这非常微妙，因为不考虑这一点可能会导致影响写入完整性的错误。^[1][2]

• ^[1] https://bugs.openjdk.java.net/browse/JDK-4469683
• ^{[2]< /sup> http://bugs.java.com/bugdatabase/view_bug.do? bug_id=6608965}

Answer 4

根据我的测试（Win7 64位，6GB RAM，Java6），NIO TransferFrom仅在处理小文件时速度很快，而在处理较大文件时变得非常慢。 NIO 数据缓冲区翻转始终优于标准 IO。

• 正在复制 1000x2MB

  1. NIO（传输）~2300ms
  2. NIO（直接datababuffer 5000b翻转）~3500ms
  3. 标准 IO（缓冲区 5000b）~6000ms

• 复制 100x20mb

  1. NIO（直接datababuffer 5000b翻转）~4000ms
  2. NIO（传输）~5000ms
  3. 标准 IO（缓冲区 5000b）~6500ms

• 复制 1x1000mb

  1. NIO（直接datababuffer 5000b翻转）~4500s
  2. 标准 IO（缓冲区 5000b）~7000ms
  3. NIO（传输）~8000ms

TransferTo() 方法适用于文件块；并不是作为高级文件复制方法：
如何在 Windows XP 中复制大文件？

Answer 5

我测试了 FileInputStream 与 FileChannel 解码 Base64 编码文件的性能。根据我的经验，我测试了相当大的文件，传统 io 总是比 nio 快一点。

由于几个 io 相关类的同步开销，FileChannel 在早期版本的 jvm 中可能具有优势，但现代 jvm 非常擅长删除不需要的锁。

Answer 6

如果您不使用transferTo 功能或非阻塞功能，您将不会注意到传统IO 和NIO(2) 之间的差异，因为传统IO 映射到NIO。

但是，如果您可以使用 NIO 功能（例如 TransferFrom/To）或想要使用 Buffer，那么 NIO 当然是最佳选择。

（需要注意的是，在某些情况下，传统的阻塞 IO 表现更好，其中一些是由错误引起的，另一些是因为开销较小或不同的缓冲假设，所以比较总是好的）。

Answer 7

我的经验是，NIO 对于小文件要快得多。但当涉及到大文件时，FileInputStream/FileOutputStream 的速度要快得多。