问题标签 [memory-mapped-files]

我有一个应用程序通过网络接收数据块，并将这些数据写入磁盘。一旦收到所有块，就可以将它们解码/重新组合成它们实际代表的单个文件。

我想知道使用内存映射文件是否有用 - 首先用于将单个块写入磁盘，其次用于将所有块都解码到的单个文件。

我自己的感觉是它可能只对第二种情况有用，有人对此有一些想法吗？

编辑：这是一个 C# 应用程序，我只计划一个 x64 版本。（因此遇到“最大的连续可用空间”问题不应该是相关的）

我正在对我正在使用的库进行一些更改。为了减少内存使用，库将其临时数据写入磁盘而不是将其保存在内存中。但是，对于我的使用场景，将其保存在内存中会更有效。它也有一些并发问题，因为它的临时文件具有常量名称，因此不能在不同的线程中同时运行（因为线程会破坏彼此的数据）。

因此，我需要更改库，以便将所有数据保存在内存中。我最初并没有编写这个库，因此我对对代码进行大刀阔斧的改变不是很舒服。因此，我希望通过尽可能少的重构来做到这一点。写入磁盘的代码非常简单。这是一个（有些简化的）示例：

块的读取非常相似（即它使用从 RandomAccessFile 获得的 FileChannel）。

感觉最简单的解决方案是如果我可以使用 FileChannel 的一些实现，它映射到内存中的一个位置而不是文件。我知道我可以使用 FileChannel 的映射方法将文件映射到内存中的某个位置。然而，情况恰恰相反。这给了我一个文件的“内存API”。我想要一个针对一些内存的 FileChannel 接口。有没有可用的实现？

您如何分配与 C 中特定边界对齐的内存（例如，高速缓存行边界）？我正在寻找类似 malloc/free 的实现，它在理想情况下会尽可能地便携——至少在 32 位和 64 位架构之间。

编辑添加：换句话说，我正在寻找一些行为类似于（现在已经过时？）memalign函数，可以使用 free 释放。

我有一个非常大的双精度数组，我使用基于磁盘的文件和 MappedByteBuffers 的分页列表来处理，有关更多背景信息，请参阅此问题。我正在使用 Java 1.5 在 Windows XP 上运行。

这是我的代码的关键部分，它针对文件分配缓冲区...

分配第二个或第三个缓冲区后，出现标题中提到的错误。

我认为这与可用的连续内存有关，因此尝试了不同大小和页数的方法，但总体上没有好处。

“没有足够的存储空间来处理这个命令”到底是什么意思，如果有的话，我能做些什么呢？

我认为 MappedByteBuffers 的重点是能够处理比堆上容纳的更大的结构，并将它们视为在内存中的能力。

有什么线索吗？

编辑：

为了回应下面的答案（@adsk），我更改了我的代码，因此我在任何时候都不会有超过一个活动的 MappedByteBuffer。当我引用当前未映射的文件区域时，我会丢弃现有地图并创建一个新地图。经过大约 3 次地图操作后，我仍然遇到同样的错误。

GC 引用的错误没有收集 MappedByteBuffers 似乎仍然是 JDK 1.5 中的一个问题。

我试图了解 Boost 内存映射文件是如何工作的。以下代码有效，它完成了它应该做的事情，但问题是它生成的文件存储在磁盘上（在可执行文件的同一目录中）而不是内存。也许在某处设置了一个标志，但我找不到它......
提前感谢您提供任何信息！

使用的编译器：gcc 4.2.1
Boost 1.41.0
操作系统：MacOS X 10.6.2

我正在使用 C dll 来挂钩全局 Windows 事件，下一步是将一些事件数据（不是很大）发送到 C# 应用程序。

由于我希望这种通信尽可能快，因此我正在分析两个选项：命名管道和内存映射文件。

我知道 .NET 4 以本机方式带来了 MMF，但我必须以 .NET 2 为目标，因为 Win98 客户端的存在仍然是可能的。我也知道有一些方法可以通过 Windows API 使用 .NET 2 来管理 MMF（有些人甚至为它构建了一些包装器）。

在这种情况下，我想知道：

1. 选择命名管道而不是 MMF 有什么大的缺点（主要是性能）吗？重要的是要记住我不会传输大量数据；
2. NP 或 MMF（针对 .NET 2）是否涉及任何安全问题？
3. 还有比这些更好的选择吗？

我一直在研究使用 Boost.Interprocess 创建磁盘支持的数据结构。Boost 文档 ( http://www.boost.org/doc/libs/1_41_0/doc/html/interprocess.html ) 上的示例都是用于使用共享内存，即使它们提到也可以使用内存映射文件。我想知道这里是否有人使用过内存映射文件？任何公开可用的代码示例（例如，内存映射文件支持的映射或集合）？

我想提出一个看似简单的问题，但我无处可寻。是否有一种用于文件输入和/或输出的FAST现代算法，可以使用所有符合标准的 C++ 编译器进行编译，并且适用于所有操作系统，而无需外部库？

1. 我发现最快的方法是使用内存映射文件，但这不会因为我们希望同一段代码在所有平台上都工作
2. 我们不能使用像 Win32 API 这样的 api，因为这会使其特定于平台
3. 我不想使用 c，如果可行，我希望算法只是带有 stl 的纯 c++ 代码，而不是带有混合 asm hack/trick 的丑陋 c
4. 不应使用不属于标准 c++ 的框架或外部库，如 wxWidgets、Qt、MFC 等。
5. 整个问题的最大重点是该算法尽可能快，类似于使用内存映射文件执行此操作的速度，甚至更快会很棒，但我知道这是不可能的

你有没有见过除了我以外的其他人研究过如此疯狂的东西吗？这样的算法甚至可能吗？

感谢您的任何建议

考虑到磁盘上有一个非常大的文件（可能超过 4GB），我想扫描这个文件并计算特定二进制模式发生的时间。

我的想法是：

1. 使用内存映射文件（CreateFileMap 或 boost mapped_file）将文件加载到虚拟内存。

2. 对于每 100MB 映射内存，创建一个线程来扫描和计算结果。

这可行吗？有更好的方法吗？

更新：
内存映射文件是个不错的选择，扫描一个 1.6GB 的文件可以在 11 秒内完成。

谢谢。

以下 C 代码说明了我在 Linux 2.6.30.5-43.fc11.x86_64 上看到的问题：

这总是失败，remap_file_pages() 返回 -1 并且 errno 设置为 EINVAL。查看内核源代码，我可以看到 remap_file_pages() 中可能失败的所有条件，但它们似乎都不适用于我的示例。这是怎么回事？