是什么导致内存提交大小增加？答案

【问题标题】：What causes increasing Memory Commit Size?是什么导致内存提交大小增加？
【发布时间】：2022-06-20 18:23:41
【问题描述】：

我有一个在 Windows 10 上运行的 C++ 程序。Windows 任务管理器告诉我提交大小随着时间的推移而迅速增加。而工作集似乎是恒定的。

Screenshot of Task Manager, my program in first line, commit size ~37GB

代码已经被不同的开发者多次检查内存泄漏，我们找不到任何明显的泄漏。

该程序是一个图形和内存密集型应用程序，利用 MFC 实例化多个窗口。我们用 OpenGL 来渲染。由于我们正在处理多个摄像头的图像，因此在运行时会进行大量数据复制。

问题是，大约 10-15 天后，当提交大小耗尽系统的可用总内存（包括分页）（不是物理 RAM）时，要么： a) 程序会崩溃到桌面 b) 显示驱动程序与 GPU 断开连接。迎接我们的只是黑屏。

到目前为止我所尝试的：

在代码中查找内存泄漏
更新图形驱动程序
更新 windows 10

什么样的泄漏只会导致提交大小增加？如何防止此问题发生？

【问题讨论】：

操作系统显示的内容并不反映程序实际使用的内存大小。标准库倾向于保持由代码释放的内存（不要将其返回给系统），希望在不久的将来会需要它。向系统请求和返回内存非常昂贵，因此这是一种优化。
尝试检查图形资源（画笔、画布...）是否被应用程序释放。在 Windows 中，您必须手动释放它们
这是教科书式的内存泄漏。它只会增加提交大小而不是工作内存，因为操作系统可以将其换出。
代码已经被不同的开发者多次检查过内存泄漏 怎么样？他们是如何“检查是否有泄漏”的（有办法……）。
您和多个开发人员可能没有发现泄漏，但您描述的症状与资源泄漏（内存泄漏或其他一些系统资源如句柄或文件的泄漏）非常一致通常是手动创建但需要手动释放的描述符）。在内存密集型程序中，内存泄漏是一种明显的可能性——但只有一种可能性。在图形密集型程序中，图形资源泄漏（画笔、字体、窗口句柄等）是一种明显的可能性。

标签： c++ windows memory

【解决方案1】：

什么，MFC 还在吗？除非您真正需要 MFC，否则您可能应该使用 glfw 之类的东西。

过去，除了使用外部内存泄漏检测器之外，您还可以使用 Visual Studio 的 c runtime 中的堆调试支持。您需要在代码中定义以下内容。

#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>

并添加

_CrtDumpMemoryLeaks();

主要处理之后和程序退出之前的某个地方。

这将用调试版本替换正常的 malloc 和 free。您还可以修改 new/delete 以获取更多信息。这些覆盖应该捕获大多数标准库分配器。该链接中有很多信息（可能比这里更多）

在换出内存处理程序后，您将运行您的程序，并在它泄漏一点后将其关闭。小心优雅地关闭它（不要终止进程），否则比实际泄漏更多的东西将被视为泄漏。一旦您致电_CrtDumpMemoryLeaks，它将转储有关所有未释放的信息。有时泄漏可能很难找到，因为转储可能不包括源/行（特别是如果您不覆盖新/删除）。它只是分配索引、大小和数据信息，但文档告诉您如何使用分配断点跟踪它。默认情况下，信息将转储到 VS 的输出窗口，因此通常最好从 VS 运行应用程序。还有其他应用程序可以挂起OutputDebugMessage 调用，您也可以自己重定向它，但同样 VS 是最简单的。您需要运行调试版本才能使其正常工作。分配器的调试版本会变慢并增加分配的大小，但在这种情况下（而且是暂时的）付出的代价很小。

如果您仍然无法定位泄漏点，那么接下来要尝试的是 GFlags - PageHeap，但那是完全不同的话题，那时事情确实出了问题。

【讨论】：

【解决方案2】：

经过大量测试和代码审查，我发现我的应用程序中根本没有内存泄漏。 Windows 报告了这一点，但是，在将 Windows 10 版本从 1909 升级到 21H2 后，所有问题都消失了。不会再增加提交内存，也不会再出现崩溃/黑屏。

【讨论】：