C++ 内存泄漏怎么排查？3 种思路与避坑一次讲清

你在长时间运行的 C++ 服务里发现内存只涨不跌，第一反应往往是哪里漏了。一句话结论：内存泄漏排查有三条主线——用 valgrind 这类工具在本地精准定位未释放的块、用 RAII 加智能指针从代码结构上预防、在 Windows 或无法装工具的环境里重载 new 和 delete 做分配计数自监控。三者定位不同：valgrind 是事后找漏点，RAII 是事前堵漏，重载计数则在不依赖外部工具时给你一手数据。理解这三者的适用边界，能让你在开发期就拦下大部分泄漏，也能在线上出问题时快速定位。下面先用一张表看清三种思路的取舍，再逐一给出可复现的操作与命令。

先看结论

记住一条铁律：根治靠 RAII，定位靠 valgrind；预防永远比事后排查成本更低。

一、内存泄漏到底漏在哪

内存泄漏指的是程序向系统申请了堆内存，却再也找不到释放它的入口，这块内存在进程退出前就一直被占着。C++ 里最常见的原因是 new 和 delete 不成对：某条错误分支提前 return，漏掉了 delete；或者异常抛出，跳过清理代码。栈上的对象会在离开作用域时自动析构，所以泄漏几乎都发生在堆上。要定位泄漏，第一步是先检查进程常驻内存是否只涨不跌，或者复用一个会反复执行的路径后内存曲线是否单调上升。基础排查思路建议先过一遍 C++ 教程。

区分清楚泄漏和碎片化也很关键：碎片化是空闲内存被切得支离破碎、分配大块时失败，但总空闲量其实够；泄漏是总空闲量持续下降。两者排错手段不同，前者看分配器，后者看释放路径。还需要注意，有些泄漏是逻辑泄漏——对象本身被引用着、永远不会被释放，比如往一个全局容器里不断塞数据却从不清理，这在工具里不算 definitely lost，但表现同样是内存只涨不跌。对比堆和栈的管理差异能帮你更快判断问题性质。理解了泄漏的本质，下面给出三种主线思路。

二、valgrind 精准定位未释放块

在本地 Linux 环境，最稳的定位手段是 valgrind 的 memcheck 工具。它会在程序运行时插桩，记录每一次 malloc / new 和 free / delete 的配对情况，运行结束后报告哪些块没有对应的释放。典型命令如下。

valgrind --leak-check=full --show-leak-kinds=all --track-origins=yes ./your_program

运行后关注 definitely lost 这一类，预期你会看到它直接指出泄漏的字节数和位置。输出样例如下：

==12345== 1,024 bytes in 1 blocks are definitely lost in loss record 1
==12345==    at 0x4C2FB55: malloc (vg_replace_malloc.c:299)
==12345==    by 0x10914B: main (leak.cpp:8)

这段输出直接告诉你泄漏发生在 leak.cpp 的第 8 行、大小 1,024 字节，顺着堆栈就能定位到漏写 delete 的那一行。失败排查时若程序依赖动态库，记得加上 --leak-check=full 才能看到完整链条。

valgrind 在性能上会让程序显著变慢，通常是几倍到几十倍，所以只适合本地调试不适合线上常驻。更多实战可参考 hellocpp 实战。关于控制块和分配语义的细节，建议对照官方标准示例，能帮助你看懂它报的每一条记录。

三、RAII + 智能指针：在代码层预防

与其事后排查，不如在写代码时就堵住泄漏口，这正是 RAII 的价值。把资源交给栈上的智能指针管理，函数返回或异常抛出时，栈展开会自动调用析构，delete 必然执行，new 和 delete 的配对由作用域保证，不再依赖人工记得释放。

#include <memory>
#include <cstddef>

void process() {
    auto buf = std::make_unique<char[]>(1024);  // 离开作用域自动释放
    // 即使中间抛异常，buf 的析构也会执行，不会泄漏
}

这就是智能指针防泄漏的核心思路：让编译器替你记着释放。除了 unique_ptr，需要共享时用 shared_ptr，缓存或观察者用 weak_ptr。C 语言没有这套机制，只能靠人工成对调用 malloc 和 free，对照可看 C 语言教程，更能体会 RAII 带来的安全收益。

适用边界：RAII 能覆盖绝大多数堆内存，但文件句柄、socket、锁等非内存资源同样适合用 RAII 包装。对比裸指针手动管理，智能指针把释放时机绑定到作用域，安全性高得多。它的边界是，你必须真的让资源对象活在栈或成员里，而不是把裸指针到处传递——一旦回到裸指针，保护就失效了。

四、重载 new-delete 做分配计数

在 Windows 或无法安装 valgrind 的环境，可以用全局重载 operator new 和 operator delete 自己做分配计数。思路是每分配一次计数加一，每释放一次计数减一，程序退出前比较两者是否相等，不相等就说明有泄漏。

#include <cstdlib>
#include <cstddef>
#include <iostream>

long g_alloc = 0;
long g_free = 0;

void* operator new(std::size_t n) {
    g_alloc++;
    return std::malloc(n);
}
void operator delete(void* p) noexcept {
    if (p) g_free++;
    std::free(p);
}

int main() {
    int* x = new int(5);
    delete x;
    std::cout << "alloc=" << g_alloc << " free=" << g_free << "\n";
    return 0;
}

运行程序，结束时比较 g_alloc 与 g_free，不相等说明某条路径漏了释放。失败排查时若数字对不上，在 new 里顺便打印调用栈或加标签，就能缩小范围。注意全局重载会影响进程内所有 new，第三方库也会走你的实现，排错时要留意这一点；placement new 不应重载，否则语义错乱。Python 这类带垃圾回收的语言不存在手动配对问题，对照 Python3 教程 能看到语言层自动管理的做法，但 C++ 仍需自己守住配对。

本文示例基于 Valgrind 3.x 官方文档与 C++ 标准实际运行（实际运行）。

总结

C++ 内存泄漏排查有三条主线：valgrind 在本地运行时扫描未释放的块，能精确定位到行；RAII 加智能指针在代码结构上预防，让释放由作用域保证；重载 new 和 delete 则在无工具环境做自监控计数。三者不互斥——开发期用 RAII 堵漏、本地用 valgrind 验证、特殊环境用计数兜底。记住根治靠 RAII、定位靠 valgrind，把预防做在前面，绝大多数泄漏都不会走到线上。想继续练手可看 C++ 官方教程。

延伸学习

• 课程：C++ 零基础课程
• 相关笔记：语言对比笔记
• 教程：Go 教程

常见问题

Q：valgrind 报 definitely lost 和 possibly lost 有什么区别？

definitely lost 表示工具确定有指针已经无法再访问到那块内存，是真实的泄漏；possibly lost 表示仍有指针指向该内存块内部（比如指向了数组中间），工具推断你可能还能访问但不确定，需要你结合代码判断。优先修 definitely lost。

Q：RAII 能防住所有 C++ 内存泄漏吗？哪些情况还会漏？

RAII 能防住绝大多数堆内存和资源的泄漏，但防不住逻辑泄漏：比如把对象塞进一个长期存活的容器却从不清理，对象被引用着所以不会析构；还有裸指针被到处传递、脱离了智能指针管理时，RAII 的保护就失效了。

Q：Windows 上没有 valgrind 怎么排查内存泄漏？

可以用本文的重载 new-delete 计数法做自监控，也可以借助 Visual Studio 自带的 CRT 调试堆、Dr. Memory 等工具。核心思路一致：要么运行时扫描未释放块，要么在分配与释放处埋点计数，比对两者是否平衡。