在大型阵列上使用 VirtualAlloc 保留与提交 + 保留内存的优势

5 winapi memory-management virtualalloc virtual-memory

我正在编写一个 C++ 程序,它基本上适用于非常大的数组。在 Windows 上,我使用 VirtualAlloc 为我的数组分配内存。现在我完全理解了使用 VirutalAlloc 保留和提交内存的区别;但是,我想知道将内存逐页提交到保留区域是否有任何好处。特别是,MSDN ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa366887(v=vs.85).aspx ) 包含对 MEM_COMMIT 选项的以下解释:

除非/直到实际访问虚拟地址,否则不会分配实际的物理页面。

我的实验证实了这一点:我可以保留和提交几 GB 的内存,而不会增加进程的内存使用量(如任务管理器中所示);只有当我实际访问内存时才会分配实际内存。

现在我看到很多例子认为应该保留大部分地址空间,然后逐页提交内存(或在一些更大的块中,取决于应用程序的逻辑)。然而,正如上面所解释的,在访问内存之前似乎并没有提交内存。因此,我想知道逐页提交内存是否有任何真正的好处。事实上,由于许多实际提交内存的系统调用,逐页提交内存实际上可能会减慢我的程序速度。如果我一次提交整个区域,我只需为一次系统调用付费,但内核似乎足够聪明,实际上只分配了我实际使用的内存。

如果有人能向我解释哪种策略更好,我将不胜感激。

jst*_*ine 6

不同之处在于提交“支持”针对页面文件的内存。举个例子:

  1. 给定 2GB 的物理内存和 2GB 的交换空间(为此目的假设交换大小固定)。
  2. 预留 6GB - 好的。
  3. 提交第一个 2GB - 好的。
  4. 提交剩余的 4GB - 失败。
  5. 将交换文件扩展到 8GB
  6. 提交剩余的 4GB - 成功。

使用 MEM_COMMIT 的原因主要是为了抑制运行时错误(应用程序稳定性)。如果您有一个按需提交页面的进程,那么如果超过可用的内存+交换量,那么提交过程中总是有可能失败。当内存得到页面文件的支持后,您就可以强有力地保证,从现在开始直到您释放内存为止,内存都可以使用。

选择一种方式有很多原因,我认为没有任何完美的科学来决定哪种方式。单独MEM_RESERVE仅需要非常大的稀疏数组的场景,例如:它具有至多25-33%的利用率(用于加速哈希表的流行技术等)的多千兆字节数组。

几乎所有其他东西都是灰色区域,您可能可以采用任何一种方式 - 预先 MEM_COMMIT 将使您自己的应用程序更加稳定,并且本质上使其优先于物理内存而不是可能按需分配的竞争应用程序。(如果您先获取 ram,那么当物理内存耗尽时,您的应用程序将是最后剩下的)同时,如果您实际上并未使用所有 ram,那么您最终可能会限制您的多任务处理潜力客户端的机器或通过不断增长的页面文件造成不必要的磁盘空间浪费。