有没有人对此进行基准测试？我想尽可能快地写入磁盘，最大限度地减少写入调用的延迟。我想知道写入内存映射缓冲区（通过 buffer.put()）是否比仅在 Java 端缓冲内容并在缓冲区已满后仅刷新到 fileChannel 更快。这样，一旦缓冲区已满，我将只进行系统调用（FileChannel.write）。我不确定当我将一些字节写入 MappedByteBuffer 时会发生什么，换句话说，是否完成了系统调用。
使用缓冲方法，我将能够以 16,32 或 64k 的块写入磁盘，我认为这是最佳的。缓冲的缺点是，如果应用程序崩溃，您必须有一个关闭挂钩来刷新内容。还有一层额外的复制到缓冲区，而不是直接写入文件通道。如果你拖尾文件，你可能看不到你想要的，因为内容被缓冲了。如果您跟踪内存映射文件，我也不知道会发生什么。
任何有经验的灵魂可以在这里提供帮助吗？
If you are trying to minimise latency, I have found writing to MemoryMappedFiles to be faster because it avoids the need to make a system call. This assumes you don't need to force the data to disk and are happy for the OS to do this on a best effort basis.
The typical latency for writing to a MemoryMappedFile is the same as writing to memory, so i don't believe you will get faster. As the file grows you need to perform an additional memory mapped regions and this can take 50 to 100 micro-seconds which is significant but should be rare enough that it doesn't matter.
Writing to IO via a system call takes in the order of 5 to 10 micro-seconds which is fast enough for more applications, but relatively much slower if it matters.
If you have a need to see the data as it is written with a low latency, I suggest you look at my library Java Chronicle which supports reading data with a typical latency of 100 ns from the time it is written.
Note: While memory mapped files can reduce latency of individual writes it doesn't increase the write throughput of your disk subsystem. This means that if you have a slow disk sub-system, your memory will soon become exhausted (even if you have many GBs) and this will be the performance bottleneck regardless of which approach you take.
For example if you have SATA or fibre, you might have a limit of 500 MB/s which is easy to exceed in which case once you hit you memory limit, this will slow you down regardless of what you chose.