问题标签 [memory-mapped-files]

我正在使用将文件（“sample.txt”）映射到内存FileChannel.map()，然后使用fc.close(). 之后，当我使用 FileOutputStream 写入文件时，出现以下错误：

java.io.FileNotFoundException: sample.txt（请求的操作不能在用户映射部分打开的文件上执行）

我认为这可能是由于文件仍然映射到内存，即使在我关闭FileChannel. 我对吗？。如果是这样，我怎样才能从内存中“取消映射”文件？（我在 API 中找不到任何方法）。谢谢。

编辑：看起来它（添加一个取消映射方法）作为 RFE 提交给 sun 一段时间： http ://bugs.sun.com/view_bug.do?bug_id=4724038

这个函数会影响内存映射文件的性能吗？

这是我需要解决的问题：

我有两个竞争磁盘访问的应用程序：“reader”和“updater”。整个系统在 Windows Server 2008 R2 x64 上运行

“更新程序”不断以线性方式访问磁盘，更新数据。他们的系统是这样设置的，即更新程序总是有无限的数据要更新。考虑到它不断逼近占用整个 2TB 磁盘驱动器的大量方程的解。Updater 使用 ReadFile 和 WriteFile 以线性方式处理数据。

用户偶尔会调用“阅读器”来获取一些数据。通常用户会从驱动器读取几个 4kb 块并停止。有时用户需要顺序读取多达 100mb。在特殊情况下高达数 GB。Reader 将文件映射到内存以获取所需的数据。

我想要实现的是让“读者”拥有绝对优先权，以便“更新程序”在需要时完全停止，以便“读者”能够尽快获得用户需要的数据。

使用 SetPriorityClass 和 SetFileBandwidthReservation 调用是否可以解决此问题？

我真的很讨厌将同步登录放在“阅读器”和“更新器”中，而是让操作系统处理优先级。

有没有办法扩展 Java 内存映射字节缓冲区，以便将新大小反映回磁盘上的映射文件？

我使用 .net 4 的 MemoryMappedFile.CreateNew(mapName, capacity) 创建了一个内存映射文件

我可以通过 cpython 的 mapName 访问这个 mmf 吗？

我尝试如下。

但它返回 WindowsError [错误 87] 说参数不正确。

我正在使用Windows Vista。

我正在尝试实现一种文件存储机制，该机制在单个文件中保存许多大小可变的记录，并保证即使系统在硬件级别出现故障，记录集也始终可以恢复到一致的状态。

到目前为止，我提出的每个方案都以顺序写入数据为中心。一些数据将附加到每条记录的末尾，以确认写入成功。但是，如果数据在刷新时不一定按顺序写入磁盘，那么确认数据可以在内容数据之前写入。

有两种明显的方法可以解决这个问题，但都是不可取的：

1. 刷新内容，然后写入确认并刷新。添加额外的刷新可能会降低性能。
2. 在确认中包含校验和（需要阅读内容以确认其有效）。

我在 Windows（32 位和 64 位）和 .Net 4.0 的内存映射文件实现上使用 C#

我想将 QImage 绑定到 MMF 文件以操作图像，而无需直接在磁盘上占用内存。不幸的是，我的代码在内存中创建了一个副本。

我的程序需要处理非常大的图像。

我正在尝试找出如何在 Mac 上重新映射内存映射文件（当我想扩展可用空间时）。

我看到我们在 Linux 世界的朋友有，mremap但我在我的 Mac 上的标题中找不到这样的功能。/Developer/SDKs/MacOSX10.6.sdk/usr/include/sys/mman.h具有以下内容：

• mmap
• mprotect
• msync
• munlock
• munmap
• 但不是mremap

man mremap证实了我的恐惧。

我目前必须munmap并且mmmap如果我想调整映射文件的大小，这涉及使所有加载的页面无效。肯定有更好的办法。一定？

我正在尝试编写适用于 Mac OS X 和 Linux 的代码。如果必须，我可以选择一个宏来在每种情况下使用最好的功能，但我宁愿正确地做到这一点。

我想使用一个使用文件描述符作为访问其数据的基本手段的库。出于性能原因，我不想在使用这个库的函数之前都将文件提交到磁盘。

我想动态创建（大）数据块，并调用库将它们发送到服务器。就目前而言，我必须将文件写入磁盘，打开它，将 FD 传递给库，等待它完成，然后删除磁盘上的文件。由于我可以按需重新创建 blob（并且它们不会太大以至于导致过多的虚拟内存分页），因此将它们保存到磁盘对我没有任何好处，并且会导致很大的性能损失。

是否可以将 FD 分配给仅作为内存映射实体驻留的数据块？

我正在尝试渲染存储在一个大文件（大约 50Mb）中的顶点。文件布局经过优化，因此我可以截取一个切片并将其提供给 opengl 以直接渲染三角带。

这在模拟器中有效，但是当我在我的魔法（android 1.5）中运行相同的代码时，它会在 libhgl.so 中与 SIGBUS 一起崩溃。听起来像驱动程序问题？

我试图手动将顶点复制到本地缓冲区（非内存映射），但它需要 300-600 毫秒的时间。

有人有经验吗？

我需要按顺序读取（扫描）文件并处理其内容。文件大小可以从非常小（一些 KB）到非常大（一些 GB）。

我在 Windows 7 64 位上使用 VC10/VS2010 尝试了两种技术：

1. Win32 内存映射文件（即 CreateFile、CreateFileMapping、MapViewOfFile 等）
2. fopen 和 fread 从 CRT。

我认为内存映射文件技术可能比 CRT 函数更快，但一些测试表明两种情况下的速度几乎相同。

以下 C++ 语句用于 MMF：

文件被顺序读取，逐块读取；每个块SYSTEM_INFO.dwAllocationGranularity的大小。

考虑到 MMF 和 CRT 的速度几乎相同，我会使用 CRT 函数，因为它们更简单且多平台。但我很好奇：我是否正确使用了 MMF 技术？在这种顺序扫描文件的情况下，MMF 性能与 CRT 相同是否正常？

谢谢。