我对大型文件的体验java.nio比更快java.io。 确实更快。 例如在> 250％的范围内。也就是说，我正在消除明显的瓶颈，我认为这可能会影响你的微基准测试。调查的潜在领域：
缓冲区大小。 你基本上拥有的算法是
我自己的经验是，此缓冲区大小已经可以调整。我为应用程序的一部分分配了4KB，为另一部分分配了256KB。我怀疑你的代码正在遭受如此大的缓冲区。使用1KB，2KB，4KB，8KB，16KB，32KB和64KB的缓冲区运行一些基准测试以向自己证明。
不要执行读写同一磁盘的Java基准测试。
如果这样做，那么你实际上是在对磁盘进行基准测试，而不是对Java进行基准测试。我还建议，如果你的cpu不忙，那么你可能会遇到其他瓶颈。
如果不需要，请不要使用缓冲区。
如果目标是其他磁盘或NIC，为什么还要复制到内存中？对于较大的文件，确保的延迟是不平凡的。
就像其他人所说的那样，请使用FileChannel.transferTo()或FileChannel.transferFrom()。此处的主要优点是，JVM使用操作系统对DMA（直接内存访问）的访问（如果存在）。（这取决于实现方式，但是可以在通用cpu上使用现代的Sun和IBM版本。） 发生的情况是数据直接往返于磁盘，总线，然后直接到达目标……绕过任何电路RAM或cpu。
我日夜不停地工作的Web应用程序非常繁忙。我也做了微观基准和现实基准。结果在我的博客上，看看：
使用生产数据和环境
微观基准易于失真。如果可以，请根据预期的负载，在预期的硬件上，按照计划要做的事情来收集数据。
我的基准是可靠且可靠的，因为它们是在生产系统，强大的系统，有负载的系统以及日志中收集的。 而不是我笔记本的7200 RPM 2.5英寸SATA驱动器，而当我密切关注JVM在硬盘上工作时。
你在做什么？这很重要。
602392714
清零编程群