java - 在普通 FileChannel 上使用 MappedByteBuffer 按顺序写入长文件是否有性能优势？

Question

我试图了解使用 16k 缓冲区短时间连续调用 FileChannel.write 和映射多个附加大小为 16k 的 ByteBuffer 之间的区别，如下所述:https://stackoverflow.com/a/7367952/962872

我认为映射字节缓冲区方法会在每次追加后丢弃 MappedByteBuffers 时产生大量垃圾。而且我不确定它是否更快。而且你仍然需要做一堆映射操作......(每个追加一个)。

或者您应该映射一个巨大的 ByteBuffer(尽可能大)并继续写入此 MappedByteBuffer？

我正在使用 FileChannel.write 方法和 Java 端 16kb 缓冲区作为写入文件的“快速”方式，但我想确保我没有遗漏更快/更好的东西。

任何人都可以开灯吗？

Answer 1

I would think that the mapped bytebuffer approach produces a lot of garbage as you discard the MappedByteBuffers after each append.

如果您创建了 16 KB 的缓冲区，它就会这样做。如果您创建了 1 GB 的缓冲区，则不需要那么多，并且这样做几乎没有损失(假设您有一个 64 位 JVM)

I am using the FileChannel.write approach with a Java-side 16kb buffer as a "fast" way to write a file but I want to make sure I am not missing something faster/better.

我会检查你的写作速度是否已经快于你的驱动器可以写的速度。内存映射文件为您提供的主要优势是低得多的典型延迟。您可以写入的吞吐量将受到驱动器速度的限制。如果您有一个典型的 SSD，您的 CPU 写出数据的速度仍然比它消耗的速度快，如果您使用 HDD，那么您做什么都可能无关紧要，因为驱动器要慢得多。

典型的写入吞吐量

• 现代 CPU:2,000 - 6,000 MB/秒
• 固态硬盘:300 - 1,200 MB/秒
• 磁盘 Controller :200 - 600 MB/秒
• HDD:20 -60 MB/秒。

通常当 CPU 不是瓶颈时，您在软件中所做的事情对应用程序的性能影响很小。

在延迟方面，典型的延迟

• FileChannel.write():10 - 40 微秒，但可以超过 1 毫秒。
• 写入内存映射文件:一条短消息需要 100 纳秒，但在需要新的内存映射时可能会激增至 100 毫秒。