内存映射文件写入卡住_在Java中使用内存映射文件时检测（写入）失败

内存映射文件写入卡住

内存映射文件是一个很好的并且经常被忽视的工具。我不会在这里详细介绍它们的工作方式（使用力 Google Luke！），但我将快速总结其优势：

操作系统提供的延迟加载和写入缓存（您不必自己编写，并且可以确信操作系统的性能良好）
易于读取复杂的二进制数据（例如其中编码有各种相对偏移量的二进制数据）
可用作高性能IPC机制
即使您的进程崩溃（如果操作系统仍然存在）也可以写入磁盘
因为不阻塞（操作系统提供了异步刷新）并且不需要进入内核模式，所以写入速度非常快

但是，由于所有这些异步性，我感到纳闷：如果发生磁盘故障，会发生什么？操作系统如何通知您的进程它无法将写入的内容写入磁盘？

一点点搜索就找到了答案：

在Linux下，当操作系统尝试将内存写回到磁盘但失败时，您的进程将获得SIGBUS 。
在Windows下，您下次尝试在文件句柄上调用OS函数时，会收到EXCEPTION_IN_PAGE_ERROR错误

为了确认信息，我提出了一个快速测试程序，将一个牺牲USB驱动器插入笔记本电脑并进行了一些测试。结论是：

当然，Linux会生成SIGBUS，并且Java（OpenJDK 1.7.0_51-b00）没有针对它的处理程序，从而导致进程崩溃：

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGBUS (0x7) at pc=0x00007f9bb5042396, pid=26654, tid=140306951444224
#
# JRE version: OpenJDK Runtime Environment (7.0_51) (build 1.7.0_51-b00)
# Java VM: OpenJDK 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# v  ~StubRoutines::jlong_disjoint_arraycopy

从好的方面来说，您知道自从您的流程停止以来，出现了严重错误。不利的一面是，您可能不会立即采取行动（除非您已经阅读了这篇文章）

如果您尝试刷新文件，Linux也可以生成更多“传统”错误情况，例如：

Exception in thread "main" java.io.IOException: Input/output errorat sun.nio.ch.FileDispatcherImpl.force0(Native Method)at sun.nio.ch.FileDispatcherImpl.force(FileDispatcherImpl.java:76)at sun.nio.ch.FileChannelImpl.force(FileChannelImpl.java:376)at Main.main(Main.java:84)

Windows仅在再次对文件句柄进行操作时才会生成异常（例如，像在Linux中那样将其分散化，但是在创建新映射时（在Linux中则没有这种体验））：

Exception in thread "main" java.io.IOException: The volume for a file has been externally altered so that the opened file is no longer validat sun.nio.ch.FileDispatcherImpl.size0(Native Method)at sun.nio.ch.FileDispatcherImpl.size(FileDispatcherImpl.java:96)at sun.nio.ch.FileChannelImpl.size(FileChannelImpl.java:307)at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:849)at Main.main(Main.java:64)

结论：内存映射文件很棒–就像一把锋利的刀子一样很棒：您可以非常快速地使用它们来做大事，但是它们也可以使您不胜其烦。如果由于其优点而要使用内存映射文件，则它们具有以下优点：