工作也有一些年头了，一直在使用C++做程序，程序做了不少，BUG也改了不少。这里面，内存泄漏的跟踪，调试和修改是最耗时间的工作之一。这些年，还是积累了一些经验，在这里记录一下，也算做个总结。
现在的高级语言，大多都有垃圾回收机制，除非语言本身的缺陷，一般不会遇到内存泄漏的问题。但C/C++不一样，自己申请的资源必须自己释放，否则，就像慢性病一样慢慢侵蚀你的程序，在不经意间给你的程序致命一击，然后悄无声息的消失，让你不知所措。如果这个程序是你从头到尾负责的，解决起来还好；如果是从别人那里接手的程序出了问题，那解决起来才叫身心俱疲，头发不知道要掉多少。
但是问题总得解决才行，解决了问题，才能睡好觉，吃好饭。那么遇到像内存泄漏这样的问题，可以怎样解决呢？
第一种方法：代码回溯
这是最简单，最节省时间的一种做法。有时候，前几天的代码还没有什么问题，今天突然出问题了，调试起来工作量比较大，就可以使用这种方式。在版本控制系统中以未出问题版本时间开始到今天为止，采用二分法方式取历史代码来调试，找到出问题的时间点，再进一步调试。其实不光内存泄漏，比较麻烦的崩溃等问题，都可以采取这些方式来解决。采用这种方式，我还是解决了好几个看起来很麻烦的问题，尤其是接手别人的代码。
第二种方法：打日志
这是程序员最常用的方法，不管什么问题，都可以用打日志的方法来定位问题，尤其是服务器程序和需要长时间运行的程序，虽然不能准确定位问题，但可以缩小分析问题的范围。在日志中，可以定时把内存占用情况打印出来，万一出现内存泄漏，还有些痕迹可以查询。
第三种方法：代码调试
VC中，在Debug模式下，可以在程序入口加入以下代码
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)这样在程序退出的时候，就可以打印出泄漏的代码码，看如下代码
int main()
{
#ifdef _DEBUG
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif
char* p = new char[1000];
char* q = new char[500];
return 0;
}调试完成后，Output会输出：
一个1000， 一个500。但这只知道有泄漏，不知道哪里泄漏啊。如果程序比较复杂，还得慢慢分析。
我们可以将new改写一下：
#ifdef _DEBUG
#define MY_NEW new(_NORMAL_BLOCK, __FILE__, __LINE__)
#else
#define MY_NEW new
#endif
int main()
{
#ifdef _DEBUG
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);
#endif
char* p = MY_NEW char[1000];
char* q = MY_NEW char[500];
return 0;
}这样就知道了，哪里分配没有释放了
但这只适合自己从头到尾参与的项目，而且自己是主要开发人员。如果是中途接手的，那调整的工作量也是挺大的。但是项目有迭代，项目组也不只你一个人，如果有人没有按你的要求来做，还是有泄漏风险的。
最后，放大招吧。使用WinDbg来调试
接下来，我重点讲讲怎么通过WinDbg来定位内存泄漏。
WinDbg是Windows平台下一个非常强大的调试工具，不仅可以调试用户态的程序，还可以进行内核态的调试。这里不对该工具做过多的介绍，网上使用教程也多，现在我们只讨论下怎么使用它去检测内存泄漏（用我习惯的做法）。
安装完WinDbg后，还需要做一些简单的设置，才能开始我们后续的工作。
1、由于我们要使用到WinDbg的扩展命令!heap，而这个命令需要下载ntdll.dll和kernel32.dll的符号，所以我们必须配置Windows的符号服务器。我们得添加一个环境变量：
变量名必须是_NT_SYMBOL_PATH_,
变量值是 SRV*f:\symbols* http://msdl.microsoft.com/download/symbols，这里面，f:\symbols是我放符号的路径。当然，也可以在WinDbg里面使用命令加载符号服务器，我觉得不方便，这里就不做介绍了。不过我使用新版WinDbg后好像不用设置也行，但为了尊重以前的习惯，还是加上吧。
2、接下来，我们需要监视我们的程序内存分配情况。在WinDbg目录下，有一个gflags.exe程序，我们使用命令行对程序进行设置
Gflags.exe /i F:\Test\Debug\Test.exe +ust其中，/i 表示指定哪个文件，比如我的程序放在F:\Test\Debug目录下，就指定为F:\Test\Debug\Test.exe。+ust表示创建用户模式堆栈跟踪数据库。执行后，命令行提示：
表示成功。gflags更多的设置，可以在命令行下输入gflags.exe /?进行查阅。
（特别提醒，打开了内存监控以后，程序运行会特别占内存，所以调试完成以后一定要关闭监控，命令也很简单，Gflags.exe /i F:\Test\Debug\Test.exe -ust，+ust改为-ust即可）
好了，现在可以调程序了。
首先，我们打开WinDbg，然后通过File->Open Executable菜单打开我们的程序。如果我们的程序正在运行，那使用File->Attach to a process挂载上我们的程序。
接下来，使用菜单File->Symbol file path加载Test.exe（我们自己的程序）的符号。我们的程序在Debug模式编译好后都会生成一个PDB文件，这个文件里面包含我们程序的调试符号。加载上程序的符号，我们才好对程序下断点，单步执行等操作，否则，只能去汇编代码里面找位置下断点或者在程序里面加中断了。
符号路径之间使用分号“;”隔开，这里我的路径为(srv*;C:\Users\zy099\source\repos\Test\x64\Debug)点击OK。然后在WinDbg命令行中输入
.reload /f
加载符号，等待符号加载完成。在WinDbg命令行里也可以操作，但我这个记性不太好，又懒得去查，所以就用最简单的方式吧。
由于符号服务器在国外，在国内下载会比较慢，所以需要耐心等待一段时间....
当WinDbg命令行可输入的时候，说明符号已下载成功，这时使用“lm”命令查看符号加载情况：
这里请一定注意ntdll、KERNEL32和我们的Test程序符号加载上没有，如果后面是如上提示，说明符号加载成功。ntdll和KERNEL32主要是需要使用扩展命令，Test用于调试程序。
接下来，可以使用菜单File->Open Source file打开要调试的源文件。一般如果符号加载正确，代码中有中断的话，就自动跳到源代码处。这里我们就手动打开。
如果Test.exe的符号加载成功，就可以在指定位置按F9下断点了。这里我在 main 的 return 处下了一个断点
之后就是检查程序泄漏点了，在这里，我们要用到WinDbg的扩展命令!heap，关于!heap命令的详细使用方式，这里不多做介绍，有兴趣的朋友可以去查看WinDbg的帮助文档，以后有时间，我也可以另起一篇介绍介绍。
代码如下：
class Bad
{
public:
void AllocMemory()
{
for (auto i = 0; i < 100; ++i)
{
char* p = new char[5000];
}
}
};
int main()
{
Bad b;
b.AllocMemory();
return 0;
}很简单吧，可以一眼看出哪儿有内存泄漏，现在我们就来看看WinDbg是怎么去发现的
在程序执行前，我们先看一下堆的情况。
在WinDbg命令行中输入!heap -s显示所有堆的摘要信息：
0:000> !heap -s
Failed to read heap keySEGMENT HEAP ERROR: failed to initialize the extention
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0xe48d63c61a6de263
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
000001e134530000 08000002 1220 60 1020 2 2 1 0 0 LFH
000001e134500000 08008000 64 4 64 2 1 1 0 0
-------------------------------------------------------------------------------------然后按F5执行程序，命中断点后停下来。再来看一下堆信息：
0:000> !heap -s
Failed to read heap keySEGMENT HEAP ERROR: failed to initialize the extention
NtGlobalFlag enables following debugging aids for new heaps:
stack back traces
LFH Key : 0xe48d63c61a6de263
Termination on corruption : ENABLED
Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast
(k) (k) (k) (k) length blocks cont. heap
-------------------------------------------------------------------------------------
000001e134530000 08000002 1220 652 1020 24 8 1 0 0 LFH
000001e134500000 08008000 64 4 64 2 1 1 0 0
-------------------------------------------------------------------------------------这里我们看到，地址为0x000001e134530000的堆有明显增长，之前Commit是60K，现在是652K
然后，我们使用命令!heap -stat -h 000001e134530000进行查看，其中参数-stat表示显示指定堆的使用情况统计信息，-h指定要查看的堆地址，这里是0x000001e134530000
0:000> !heap -stat -h 000001e134530000
heap @ 000001e134530000
group-by: TOTSIZE max-display: 20
size #blocks total ( %) (percent of total busy bytes)
13bc 64 - 7b570 (90.02)
1cf0 1 - 1cf0 (1.32)
30 8d - 1a70 (1.21)
1234 1 - 1234 (0.83)
1034 1 - 1034 (0.74)
df4 1 - df4 (0.64)
400 2 - 800 (0.36)
100 8 - 800 (0.36)
7c4 1 - 7c4 (0.35)
7a2 1 - 7a2 (0.35)
138 6 - 750 (0.33)
390 2 - 720 (0.33)
695 1 - 695 (0.30)
628 1 - 628 (0.28)
1d8 3 - 588 (0.25)
25c 2 - 4b8 (0.22)
470 1 - 470 (0.20)
168 2 - 2d0 (0.13)
50 8 - 280 (0.11)
238 1 - 238 (0.10)我们看到，大小为0x13bc的块有0x64个，总大小0x7B570, 占整个正在使用块的90.02%。我们怀疑这些块就是泄漏的块。
接下来我们获取这些块的地址。使用命令!heap -flt s 13bc。其中-flt将显示范围限定为指定大小或大小范围的堆，参数s 13bc就是指定大小为0x13bc的块。
0:000> !heap -flt s 13bc
_HEAP @ 1e134530000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
000001e134546ce0 013f 0000 [00] 000001e134546d10 013bc - (busy)
unknown!noop
000001e1345480d0 013f 013f [00] 000001e134548100 013bc - (busy)
000001e1345494c0 013f 013f [00] 000001e1345494f0 013bc - (busy)
000001e13454a8b0 013f 013f [00] 000001e13454a8e0 013bc - (busy)
000001e13454bca0 013f 013f [00] 000001e13454bcd0 013bc - (busy)
000001e13454d090 013f 013f [00] 000001e13454d0c0 013bc - (busy)
000001e13454e480 013f 013f [00] 000001e13454e4b0 013bc - (busy)
000001e13454f870 013f 013f [00] 000001e13454f8a0 013bc - (busy)
000001e134550c60 013f 013f [00] 000001e134550c90 013bc - (busy)
000001e134552050 013f 013f [00] 000001e134552080 013bc - (busy)
unknown!noop
000001e134553440 013f 013f [00] 000001e134553470 013bc - (busy)
000001e134554830 013f 013f [00] 000001e134554860 013bc - (busy)
unknown!printable
000001e134555c20 013f 013f [00] 000001e134555c50 013bc - (busy)
unknown!printable这里我只截取了部分数据，其实这儿比较长。这里我们会看到很多状态为busy的堆块，这些堆块应该就是没有释放的内存空间。
我们使用!heap -p -a 000001e134546ce0，来输出一下它的调用堆栈：
0:000> !heap -p -a 000001e134546ce0
address 000001e134546ce0 found in
_HEAP @ 1e134530000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
000001e134546ce0 013f 0000 [00] 000001e134546d10 013bc - (busy)
unknown!noop
7ff9c9d3d6c3 ntdll!RtlpAllocateHeapInternal+0x00000000000947d3
7ff9730dd480 ucrtbased!heap_alloc_dbg_internal+0x0000000000000210
7ff9730dd20d ucrtbased!heap_alloc_dbg+0x000000000000004d
7ff9730e037f ucrtbased!_malloc_dbg+0x000000000000002f
7ff9730e0dee ucrtbased!malloc+0x000000000000001e
7ff60b1c1f73 Test!operator new+0x0000000000000013
7ff60b1c19f3 Test!operator new[]+0x0000000000000013
7ff60b1c1e10 Test!Bad::AllocMemory+0x0000000000000040
7ff60b1c4746 Test!main+0x0000000000000046
7ff60b1c1eb9 Test!invoke_main+0x0000000000000039
7ff60b1c1d5e Test!__scrt_common_main_seh+0x000000000000012e
7ff60b1c1c1e Test!__scrt_common_main+0x000000000000000e
7ff60b1c1f4e Test!mainCRTStartup+0x000000000000000e
7ff9c83354e0 KERNEL32!BaseThreadInitThunk+0x0000000000000010
7ff9c9c8485b ntdll!RtlUserThreadStart+0x000000000000002b在这里，我们看到了这个堆的调用堆栈，Test!Bad::AllocMemory，确实是我们分配没有释放的内存空间。这就是这个堆块分配的堆栈信息，通过这个信息，我们就可以定位到这块内存是哪里分配的，然后再到相应的函数里面去分析。
真正在项目中，情况远没有这种简单，有时候，打印出来的堆信息就有很长一串，这就需要在这些信息里面去找有用的信息的。调试是很让人头痛的一件事，但一旦解决了这些难嗗的骨头，成就感还是有的。
写在最后
C++程序员要想做到内存使用不出什么意外，好像还真不容易做到。但我们使用一些方法减少内存泄漏的风险，比如，使用C++的智能指针，使用内存池技术来统一管理内存等。