java - 内存映射文件的性能/稳定性 - Native 或 MappedByteBuffer - vs. plain ol' FileOutputStream

Question

我支持使用平面文件(纯文本)实现持久性的遗留 Java 应用程序。由于应用程序的性质，这些文件的大小每天可以达到 100 MB，而应用程序性能的限制因素通常是文件 IO。目前，该应用程序使用普通的 java.io.FileOutputStream 将数据写入磁盘。

最近，我们有几位开发人员断言，使用以 native 代码 (C/C++) 实现并通过 JNI 访问的内存映射文件将提供更高的性能。然而，FileOutputStream 已经为其核心方法(即 write(byte[]))使用了本地方法，因此在没有硬数据或至少没有轶事证据的情况下，它似乎是一个脆弱的假设。

我有几个问题:

1. 这个说法是真的吗？内存映射文件总是提供比 Java 更快的 IO文件输出流？

2. 类 MappedByteBuffer从 FileChannel 提供访问与本地相同的功能已访问内存映射文件库通过 JNI？什么是 MappedByteBuffer缺少它可能会导致您使用JNI解决方案？

3. 使用的风险是什么生产中用于磁盘 IO 的内存映射文件应用？也就是说，应用具有连续正常运行时间最少的重启(每月一次，最多)。生产中的真实轶事应用程序(Java 或其他)首选。

问题 #3 很重要——我可以自己部分回答这个问题，方法是编写一个“玩具”应用程序，该应用程序使用上述各种选项对 IO 进行性能测试，但我希望通过发布到 SO以获取真实世界的轶事/数据。

[编辑] 说明 - 每天运行时，应用程序都会创建多个文件，大小从 100MB 到 1 gig。总的来说，应用程序每天可能会写出数 GB 的数据。

Answer 1

内存映射 I/O 不会使您的磁盘运行得更快(!)。对于线性访问，它似乎有点毫无意义。

NIO 映射缓冲区是真实存在的(通常对任何合理的实现提出警告)。

与其他 NIO 直接分配的缓冲区一样，这些缓冲区不是普通内存，不会像 GC 那样有效。如果你创建了很多它们，你可能会发现你用完了内存/地址空间而没有用完 Java 堆。对于长时间运行的进程，这显然是一个问题。