我支持使用平面文件(纯文本)实现持久性的遗留 Java 应用程序。由于应用程序的性质，这些文件的大小每天可以达到 100 MB，而应用程序性能的限制因素通常是文件 IO。目前，该应用程序使用普通的 java.io.FileOutputStream 将数据写入磁盘。
最近，我们有几位开发人员断言，使用以 native 代码 (C/C++) 实现并通过 JNI 访问的内存映射文件将提供更高的性能。然而，FileOutputStream 已经为其核心方法(即 write(byte[]))使用了本地方法，因此在没有硬数据或至少没有轶事证据的情况下，它似乎是一个脆弱的假设。
我有几个问题:
这个说法是真的吗？ 内存映射文件总是 提供比 Java 更快的 IO 文件输出流？
类 MappedByteBuffer 从 FileChannel 提供访问 与本地相同的功能 已访问内存映射文件库 通过 JNI？什么是 MappedByteBuffer 缺少它可能会导致您使用 JNI解决方案？
使用的风险是什么 生产中用于磁盘 IO 的内存映射文件 应用？也就是说，应用 具有连续正常运行时间 最少的重启(每月一次，最多)。 生产中的真实轶事 应用程序(Java 或其他) 首选。
问题 #3 很重要——我可以自己部分回答这个问题，方法是编写一个“玩具”应用程序，该应用程序使用上述各种选项对 IO 进行性能测试，但我希望通过发布到 SO以获取真实世界的轶事/数据。
[编辑] 说明 - 每天运行时，应用程序都会创建多个文件，大小从 100MB 到 1 gig。总的来说，应用程序每天可能会写出数 GB 的数据。
最佳答案
内存映射 I/O 不会使您的磁盘运行得更快(!)。对于线性访问，它似乎有点毫无意义。
NIO 映射缓冲区是真实存在的(通常对任何合理的实现提出警告)。
与其他 NIO 直接分配的缓冲区一样，这些缓冲区不是普通内存，不会像 GC 那样有效。如果你创建了很多它们，你可能会发现你用完了内存/地址空间而没有用完 Java 堆。对于长时间运行的进程，这显然是一个问题。
关于java - 内存映射文件的性能/稳定性 - Native 或 MappedByteBuffer - vs. plain ol' FileOutputStream，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/537295/