我已通过valgrind运行我的代码并获得以下结果：
== 4492 == Memcheck，内存错误检测器
== 4492 ==版权所有（C）2002-2009，以及Julian Seward等人的GNU GPL'd。 == 4492 ==使用Valgrind-3.5.0和LibVEX;用-h重新运行版权信息
== 4492 ==命令：./ mem
== 4492 ==父PID：4455
== == 4492
== == 4492
== 4492 == HEAP SUMMARY：
== 4492 ==在退出时使用：0块中的0字节
== 4492 ==总堆使用量：19,595,342个分配，19,595,342个释放，分配27,194,270个字节 == == 4492
== 4492 ==所有堆块都被释放 - 没有泄漏是可能的 == == 4492
== 4492 ==对于检测到的和抑制的错误计数，请重新运行：-v
== 4492 ==错误摘要：0个上下文中的0个错误（被抑制：4个中的4个）
然而，当代码运行时，我看到程序使用的内存小幅稳定增加。我对这个结果有多确定？
我使用
运行valgrind
valgrind --track-origins=yes --leak-check=yes
--tool=memcheck --read-var-info=yes --log-file=error.txt`
我使用-g和-march=core2代码编译程序。
答案 0 :(得分：8)
您需要区分内存泄漏（已分配的内存，但丢失了所有引用）和内存占用（已分配的内存，您保留引用，但忘记取消分配）。
valgrind无法检测到后者，因为valgrind不知道你不想再使用它了。
要获得有关程序内存使用情况的一些统计信息，可以使用valgrind的massif工具，它将更详细地向您显示内存的分配位置。这可能有助于寻找记忆力。
答案 1 :(得分：4)
内存使用量的小幅增加不一定要担心需要担心的事情 - 可能是您的程序正在加速并且会在某个时刻达到峰值。在不知道该应用程序的逻辑的情况下，很难说清楚。但是，坚持认为所有已分配的块都已释放，而且通常非常好。
您可能需要考虑让它运行更长时间，增加它必须以某种方式执行的工作（这又取决于应用程序），以查看它是否曾经达到峰值或持续上升（或者直到它耗尽虚拟内存） ，无论如何）。
我还会看最后两行：
==4492== For counts of detected and suppressed errors, rerun with: -v
==4492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
您可能希望使用-v运行它，以检查这些抑制是什么。它们可能只是一无所知，但它并没有受到影响。
答案 2 :(得分：0)
你是否看到使用顶级工具增加内存使用量？根据程序的行为，如果不断分配和释放内存，可能会引入碎片，导致地址空间增长。如果你让这个过程运行得足够长，它可能会稳定并停止增长。
答案 3 :(得分：0)
valgrind可以检测内存泄漏，但内存使用率不高。你的代码中的错误可能会在没有明显原因的情况下不断分配内存，然后无论如何防御代码都会清理它。
那就是说，我不相信你的机制来确定你的进程的内存使用情况。幕后有很多内容：缓存，一个。
我称之为“不确定”。