如何使用工具（如Valgrind）来检测C++程序的内存泄漏

P粉602998670

发布时间：2025-09-07 10:15:02

471人浏览过

来源于php中文网

原创

使用Valgrind检测C++内存泄漏，需先安装工具并运行valgrind --leak-check=full --show-leak-kinds=all ./可执行文件，其输出会分类显示definitely lost、possibly lost等泄漏类型，应优先处理definitely lost并结合调用栈定位未释放内存的代码，同时在大型项目中应聚焦关键模块测试以降低性能开销。

如何使用工具（如valgrind）来检测c++程序的内存泄漏

检测C++程序的内存泄漏，Valgrind无疑是一个非常强大且常用的工具。它能帮助我们找出那些被分配却未被释放的内存，以及其他一系列内存相关的错误。用它来排查问题，通常能省下大量手动调试的时间，尤其是在面对复杂的代码库时。

解决方案

使用Valgrind检测C++内存泄漏，核心步骤其实并不复杂，但理解其输出和背后的原理，才是真正能高效解决问题的关键。

你需要确保Valgrind已经安装在你的系统上。在大多数Linux发行版上，这通常就是一条简单的

sudo apt install valgrind

或

sudo yum install valgrind

命令。安装好之后，我们就可以开始使用了。

最基本的用法是：

valgrind --leak-check=full --show-leak-kinds=all ./你的可执行文件 [你的程序参数]

这里面有一些关键的选项：

立即学习“C++免费学习笔记（深入）”；

```
--leak-check=full
```
: 这是告诉Valgrind，不仅要检测内存泄漏，还要进行详尽的泄漏报告，包括泄漏的来源和大小。
```
--show-leak-kinds=all
```
: 这个选项会显示所有类型的内存泄漏，包括“definitely lost”、“indirectly lost”、“possibly lost”和“still reachable”。这对于全面理解内存状况非常重要。
```
./你的可执行文件
```
: 就是你编译好的C++程序。
```
[你的程序参数]
```
: 如果你的程序需要命令行参数，就在这里传入。

运行之后，Valgrind会模拟CPU执行你的程序，并在这个过程中监控所有的内存操作。当程序结束时，它会输出一份详细的报告。这份报告会告诉你哪些内存块被分配了，但在程序结束时却没有被释放。

我个人在使用Valgrind时，经常会遇到一个场景：程序在运行过程中看起来一切正常，但Valgrind一跑，就跳出一堆“possibly lost”或者“still reachable”。“definitely lost”是最明确的泄漏，必须修复。而“possibly lost”则需要你深入代码去判断，这块内存是否真的应该被释放，或者它是否被某个指针意外地覆盖了。“still reachable”通常意味着内存还在被某个全局变量或静态变量引用，程序结束时理论上操作系统会回收，但在某些特定场景下，比如插件系统或者长生命周期的服务中，这可能也是一个需要关注的点，因为它可能预示着设计上的缺陷，或者在程序生命周期内累积起来会成为问题。

处理Valgrind的输出，需要一点耐心。它会告诉你内存是在哪个文件、哪一行代码被分配的。通常，我会从

definitely lost

开始着手，因为那是板上钉钉的泄漏。然后，我会顺着调用栈回溯，找到分配这块内存的代码路径，检查对应的

delete

或者

free

是否缺失，或者是否在某个异常路径下被跳过了。有时候，这不仅仅是忘记释放的问题，可能是智能指针使用不当，或者容器的深拷贝/浅拷贝问题。

举个简单的例子：

MCP官网

Model Context Protocol（模型上下文协议）

下载

#include 

void allocateMemory() {
    int* data = new int[10];
    // 忘记 delete[] data;
}

int main() {
    allocateMemory();
    std::cout << "Program finished." << std::endl;
    return 0;
}

编译并运行

valgrind --leak-check=full ./a.out

，你就会看到明确的内存泄漏报告，指向

allocateMemory

函数中的

new int[10]

。这就是Valgrind最直接的价值所在。

Valgrind报告中的错误信息应该如何解读？

Valgrind的报告初看起来可能有点吓人，因为它输出的信息量很大。但只要掌握了几个关键点，就能快速定位问题。

最常见的错误类型，也是我们最关心的，就是内存泄漏（Memory Leak）。Valgrind会将内存泄漏分为几类：

definitely lost
(明确丢失): 这是最严重的，也是最需要优先解决的。它表示你的程序分配了一块内存，但在程序结束时，没有任何指针指向这块内存，也没有被释放。这意味着这块内存彻底无法访问，也无法回收，是经典的内存泄漏。Valgrind会告诉你这块内存是在哪里被分配的，以及它的大小。
indirectly lost
(间接丢失): 当一个指针指向一块
```
definitely lost
```
的内存，而这个指针本身也被
```
definitely lost
```
时，这块内存就被认为是
```
indirectly lost
```
。这通常意味着你丢失了指向一个数据结构头部的指针，导致整个数据结构都无法被释放。
possibly lost
(可能丢失): 这类错误比较微妙。它表示有一块内存，在程序结束时，仍然有指针指向它，但这些指针本身也是在栈上或者在其他可能被回收的地方。Valgrind不能确定这块内存是否会被正确释放。这通常发生在，例如，你有一个指针指向一块堆内存，但这个指针本身是一个局部变量，在函数返回后就失效了，而这块堆内存却没有被
```
delete
```
。需要仔细检查这些情况，它们很可能也是真正的泄漏。
still reachable
(仍可达): 这表示有一块内存，在程序结束时仍然有指针指向它，并且这些指针本身是全局的、静态的，或者通过其他方式在程序结束时仍然有效。从技术上讲，操作系统在程序结束后会回收所有资源，所以严格来说这不是“泄漏”。但它可能暗示着你的程序设计中存在一些问题，比如全局缓存没有清理，或者生命周期管理不当。在长期运行的服务中，
```
still reachable
```
累积起来也可能成为问题。

除了内存泄漏，Valgrind还会报告其他类型的内存错误，比如：

Invalid read/write
(非法读写): 尝试读取或写入未分配的内存，或者已释放的内存，或者数组越界。这通常会导致程序崩溃或者产生未定义行为。Valgrind会精确指出发生错误的位置。
Use of uninitialised value
(使用未初始化值):: 尝试使用一个没有被初始化过的变量的值。这在C++中非常常见，而且可能导致难以追踪的bug。
Invalid free()
/
delete
(非法释放): 尝试
```
free
```
或
```
delete
```
一块没有通过
```
malloc
```
或
```
new
```
分配的内存，或者多次释放同一块内存。