释放不会释放 Windows/C++ 应用程序中的内存答案

【问题标题】：Deallocation doesn't free memory in Windows/C++ Application释放不会释放 Windows/C++ 应用程序中的内存
【发布时间】：2010-09-26 22:56:45
【问题描述】：

我的 Windows/C++ 应用程序使用运算符 new 在内存中分配约 1Gb 的数据并处理这些数据。处理后数据被删除。

我注意到，如果我在不退出应用程序的情况下再次运行处理，则对 operatornew 的第二次调用以分配 ~1Gb 的数据会失败。

我希望 Windows 能够将内存返回。这可以通过其他一些 Win32 调用等以更好的方式进行管理吗？

【问题讨论】：

标签： c++ windows winapi memory-management memory-leaks

【解决方案1】：

我认为这不是 Windows 问题。检查您是否正确使用了 delete 或 delete[]。如果您发布分配/释放内存的代码，也许会有所帮助。

【讨论】：

【解决方案2】：

在大多数运行时环境中，从操作系统分配给应用程序的内存保留在应用程序中，并且很少返回给操作系统。释放内存块允许您在应用程序内重用该块，但不会将其释放到操作系统以使其可供其他应用程序使用。

Microsoft 的 C 运行时库尝试通过让 _heapmin_region 调用 _heap_free_region 或 _free_partial_region 来将内存返回给操作系统，它们调用 VirtualFree 将数据释放到操作系统。但是，如果相应区域中的整个页面不为空，则它们不会被释放。造成这种情况的一个常见原因是 C++ 容器的簿记信息和存储缓存。

【讨论】：

Java 可能是这种情况，但 Windows 标准 C/C++ 库肯定不是这种情况，至少对于大于内存页的任何东西都不是。试一试，自己看看。
你是对的。我已经编辑了答案以描述 Microsoft C 如何处理释放。
你在哪里可以肯定地阅读到这样的细节？ MS 或印刷书籍参考会很棒。我真的不知道去哪里找，甚至怀疑没有地方可以找，人们通过实验发现了这些东西——我希望不是这样！
你可以在源代码中找到这些细节！我就是这样找到它的，而且这通常是唯一确定的事实来源。

【解决方案3】：

这可能是由于内存碎片（实际上是地址空间碎片）造成的，其中各种因素导致您的程序地址空间没有可用的 1gb 连续孔。实际上，我怀疑您的内存管理存在错误（抱歉） - 您是否通过泄漏检测运行代码？

【讨论】：

我已经确保每个新的指针也被删除了。我的调试打印日志至少显示了这一点。 VS2003 中是否有任何工具或独立工具可以帮助我查找漏洞？
阅读msdn.microsoft.com/en-us/library/x98tx3cf(VS.80).aspx，这可能会有所帮助。您还应该检查分配资源的新对象是否必须在其析构函数中释放，并且任何 new[] 是否与 delete[] 匹配。
我在想 delete[] 已经过时了，删除就足够了。
delete[] 在使用 new[] 分配数据时是必需的。
是的，不使用 delete[] 很可能是您的问题。我想我应该在回答中更清楚地说明这一点。

【解决方案4】：

由于您使用非常大的内存块，您应该考虑使用VirtualAlloc() 和VirtualFree()，因为它们允许您直接分配和释放页面，而无需与堆管理器交互的开销（内存和时间） .

由于您使用的是 C++，因此值得注意的是，您可以使用 placement new 在您分配的内存中构造 C++ 对象。

【讨论】：

【解决方案5】：

这个问题几乎可以肯定是内存碎片。在 32 位 Windows 上，您可以分配的最大连续区域约为 1.1GB（因为 EXE 中的各种 DLL 会阻止更大的连续区域可用）。如果在解除分配内存分配（或 DLL 加载，或内存映射文件）后，最终位于您之前的 1GB 区域的中间，那么将不再有 1GB 区域可供您下次调用 new 分配 1GB。因此它会失败。

您可以使用VM Validator 可视化此过程。

【讨论】：