我有一个图形程序，我在其中一遍又一遍地创建和销毁相同的对象。总共有 140 个对象。它们被删除和更新，因此数字永远不会增加 140。这是一个要求，因为它是一个压力测试，即我不能有内存池或虚拟对象。现在我相当确定没有任何内存泄漏。我还使用了一个内存泄漏检测器，它没有报告任何泄漏。
问题在于程序的内存占用不断增加（尽管速度很慢，比对象被销毁/创建的速度慢）。所以我的问题是，内存占用量增加是否是内存泄漏的可靠信号，还是有时会具有欺骗性？
编辑：我正在使用 new/delete 创建/销毁对象
【问题讨论】：
标签： c++ windows memory-leaks
尝试 CRT 中包含的内存分配测试：http://msdn.microsoft.com/en-us/library/e5ewb1h3%28VS.80%29.aspx
他们帮了很多忙。
但我注意到，如果您查看某些因素，应用程序的内存消耗确实会略有不同。 Windows 7 还可能在内存分配中创建额外的填充来修复错误：http://msdn.microsoft.com/en-us/library/dd744764%28VS.85%29.aspx
【讨论】：
这种行为似乎确实可能来自没有泄漏的情况。
您的堆是否有可能获得fragmented？
假设您进行了大量n 大小的分配。您将它们全部释放，这使您的 C 库将这些缓冲区插入到空闲列表中。然后其他一些代码路径使分配小于n，因此空闲列表中的那些块被分块成更小的单元。然后循环的下一次迭代执行另一批大小为n 的分配，空闲列表不再包含该大小的连续内存，malloc 必须向内核请求更多内存。最终，那些“小于n”的分配会像你的“n-sized”一样被释放，但是如果你在存在碎片的地方运行足够多的迭代，我可以看到进程逐渐增加它的内存占用。
避免这种情况的一种方法是一次性分配所有对象，而不是继续分配/释放它们。由于您使用的是 C++，这可能需要 placement new 或类似的东西。由于您使用的是 Windows，我还可能会提到 Win32 在进程中支持having multiple heaps，因此如果您的对象来自与其他分配不同的堆，您可以避免这种情况。
【讨论】：
如果您的应用程序的进程占用量增加到超出合理限制，这取决于您的应用程序及其功能，并且继续增加直到最终您（将）用完虚拟内存，那么您肯定存在内存泄漏。
【讨论】：
这取决于您是在 CLR（或具有垃圾收集器的虚拟机）下还是仍处于旧模式（如 C++、MFC 等...）
当你有一个 GC 时 - 你真的无法判断，只有当你测试它足够长的时间。 GC 可以决定暂时不清理你的对象......（有一种方法可以强制它）
在本机应用程序中，是的，占用空间增加可能意味着泄漏。
有一些用于 c++ 的工具（非常好的工具）可以找到这些漏洞（google devpartner 或 boundschecker）
我猜也有一些适用于 c# 和 Java 的工具。
【讨论】：