为什么这个循环会毁掉我的记忆？

我在我的MMF类中有这个function

void Clear() { int size = SizeB(); int iter = size / sysInfo.granB; for (int i = 0; i < iter; i++) { auto v = (char*)MapViewOfFile(hMmf, FILE_MAP_READ | (write ? FILE_MAP_WRITE : 0), 0, i * sysInfo.granB, sysInfo.granB); std::memset(v, 0, sysInfo.granB); UnmapViewOfFile(v); } }

所以它所做的是以最小的可寻址块（本例中为64k）遍历整个文件，映射视图，写入0，取消映射，重复。它工作正常，非常快，但是当我使用它时，有一些幻像内存使用正在进行。

根据Windows任务pipe理器，这个过程本身只用了几兆字节，但是当我在较大的文件上使用它时，“物理内存使用量”会大大增加。例如，在一个2GB的文件上使用这个function足以让我的笔记本电脑昏迷几分钟，物理内存使用率达到99％，任务pipe理器中的所有内容都疯狂地减less了内存，一切都冻结了一段时间。

我试图在64k块中这样做的全部原因是为了保持内存使用率下降，但是在这种情况下块大小并不重要，任何大小的块* n来覆盖文件都是一样的。

我尝试过的一些事情：

在unmapping之前刷新视图 – 这使事情非常缓慢，做任何大小的块2GB文件需要10分钟的分钟。
在循环中添加一个硬编码的延迟 – 它实际上工作非常好，它仍然在几秒钟内完成，内存使用保持下来，但我真的不喜欢任何循环中的硬编码延迟的概念
写0到文件的末尾 – 我实际上并不需要清除文件，只是强迫它准备好使用。我的意思是 – 当我创build一个新的文件，并开始我的随机IO，我最好是〜1MB /秒。如果我打开一个现有的文件或强制在新的文件中写0，我得到更好的速度。我不完全确定这是为什么，但是另一个线程中的用户build议在设置文件指针之后将文件写到文件的最后，与清除相同的效果，但是从testing中，这是不正确的。

所以目前我试图从清除文件的angular度解决这个问题，而不破坏计算机的内存。有谁知道如何适当地限制这个循环？

所以这是事情。当你MapViewOfFile ，它分配相关的内存范围，但可能会标记为换出（例如，如果它尚未被读入内存）。如果是这样的话，那么当你第一次访问它的时候就会出现页面错误（这会导致操作系统读取它）。

然后，当您使用UnmapViewOfFile ，操作系统将获取关联的内存范围的所有权，并将现在不可访问的用户空间数据写回到磁盘（当然，假设您已经写入了该数据，将页面标记为“肮脏“，否则直接解除分配）。引用文档（我要求你阅读评论）： modified pages are written "lazily" to disk; that is, modifications may be cached in memory and written to disk at a later time. modified pages are written "lazily" to disk; that is, modifications may be cached in memory and written to disk at a later time.

取消映射文件视图不保证“取消提交”并将数据写入磁盘 。而且，即使CloseHandle也不提供这种担保。它只是关闭了它的句柄。由于缓存机制，如果您不调用FlushViewOfFile ，则操作系统完全可以在自己的时间将数据写回到磁盘。即使重新打开相同的文件也可能只是将数据从缓存而不是从磁盘中取出。

最终的问题是

你记忆映射一个文件
你写的内存映射
写入内存映射的地址范围会导致文件的映射从磁盘读入
你取消映射该文件
解开文件“lazily”将数据写回磁盘
操作系统可能会遇到内存压力，看到有一些未写入的数据，现在可以写入磁盘，并迫使它发生恢复物理内存的新分配; 顺便说一句，由于操作系统懒惰冲洗，您的IO不再顺序，并导致主轴磁盘延迟急剧增加

当你睡觉的时候，你会看到更好的性能，因为你让操作系统有机会说“嘿，我没有做任何事情……让我们继续并刷新缓存”，这迫使磁盘IO大致顺序。