C++学习笔记----6、内存管理（四）---- 通常的内存陷阱（2）

3、Windows环境下使用Visual C++发现并修复内存渗露

        内存渗露很难跟踪是因为你无法很容易地看着内存并且看到什么对象处于使用中，一开始在哪儿分配的内存。然而，是有程序可以为你做到这一点的。内存渗露检测工具有昂贵的专业软件包，也有免费下载的工具。如果你是在Microsoft Visual C++环境下工作，它的排错工具库有内建的对于内存渗露检测的支持。该内存检测默认没有打开，除非你生成了一个MFC项目。在其他项目中打开这个工具，需要在一开始包含下面三行代码。使用了#define的预处理宏，这个我们以后再讲。现在，只要使用这三行就行了。

#define _CRTDBG_MAP_ALLOC
#include <cstdlib>
#include <crtdbg.h>

        这三行的顺序不能调整。接下来，需要重新定义new操作符，如下面代码所示。也会用到一些其它的预处理宏，也会在以后再讲，现在用就是了。

#ifdef _DEBUG
	#ifndef DBG_NEW
		#define DBG_NEW new( _NORMAL_BLOCK, __FILE__,__LINE__)
		#define new DBG_NEW
	#endif
#endif

        #ifdef _DEBUG语句确保对于new的重新定义只有在编译应用的排错版本时才会做。这就是你正常想要的。发行版本通常不会再去做内存渗露检测，因为会有性能惩罚的。

        最后需要做的就是在main()函数的第一行加上下面这一行代码：

_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

        这行代码告诉Visual C++ CRT(C运行时)库，当应用退出时，把所有检测到的内存渗露写到排错输出控制台。对于早期渗露程序，排错控制台会包含类似于下面的语句：

Detected memory leaks!
Dumping objects ->
c:\leaky\leaky.cpp(15) : {147} normal block at 0x014FABF8, 4 bytes long.
Data: < > 00 00 00 00
c:\leaky\leaky.cpp(33) : {146} normal block at 0x014F5048, 4 bytes long.
Data: <Pa > 50 61 20 01
Object dump complete.

        输出清晰地展示了哪个文件的哪一行的内存分配了但是没有被释放。行号在文件名后面的括号内。大括号内的数字是对于内存分配的计数。例如，{147}意味着从程序一开始的第147次内存分配。可以使用VC++ _CrtSetBreakAlloc()函数告诉VC++排错运行时在debugger中进入断点，当选定的内存分配执行时。例如，可以加入下面一行代码在main()函数的开头，让debugger在第147次内存分配时进入断点：

_CrtSetBreakAlloc(147);

        在这个内存渗露的程序中，有两个渗露点：第一个Simple对象没有被删除，以及在自由内存空间上生成的整数。在Visual C++ debugger输出窗口中，可以双击其中一个内存渗露点，会自动跳转到该行。

        当然了，像在Microsoft Visual C++（以上讨论的就是）以及Valgrind（后面会讨论）中的程序并不能实际上为你修复内存渗露----你可能会说，这不是搞笑吗？这些工具提供了你可以用来发现实际问题的信息。正常情况下，这包含了进入代码后发现指向对象的指针被覆写而原始对象没有被释放。大部分debugger提供了“观察点”功能，当这种情况发生时可以中断程序的执行。

4、在Linux环境下使用Valgrind发现并修复内存渗露

        Valgrind是一个Linux环境下的开源免费的例子，与其它工具相比，能够定位到出现内存渗露的代码的准确的行。

        下面的输出，就是由运行在早期内存渗露程序的Valgrind产生的，定位到了内存分配而没有释放的精确位置。Valgrind发现了同样的两个内存渗露----第一个Simple对象没有被删除，以及在自由内存空间上生成的整数：

==15606== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==15606== malloc/free: in use at exit: 8 bytes in 2 blocks.
==15606== malloc/free: 4 allocs, 2 frees, 16 bytes allocated.
==15606== For counts of detected errors, rerun with: -v
==15606== searching for pointers to 2 not-freed
blocks.
==15606== checked 4455600 bytes.
==15606==
==15606== 4 bytes in 1 blocks are still reachable in loss record 1 of 2
==15606== at 0x4002978F: __builtin_new (vg_replace_malloc.c:172)
==15606== by 0x400297E6: operator new(unsigned) (vg_replace_malloc.c:185)
==15606== by 0x804875B: Simple::Simple() (leaky.cpp:4)
==15606== by 0x8048648: main (leaky.cpp:24)
==15606==
==15606==
==15606== 4 bytes in 1 blocks are definitely lost in loss record 2 of 2
==15606== at 0x4002978F: __builtin_new (vg_replace_malloc.c:172)
==15606== by 0x400297E6: operator new(unsigned) (vg_replace_malloc.c:185)
==15606== by 0x8048633: main (leaky.cpp:20)
==15606== by 0x4031FA46: __libc_start_main (in /lib/libc-2.3.2.
so)
==15606==
==15606== LEAK SUMMARY:
==15606== definitely lost: 4 bytes in 1 blocks.
==15606== possibly lost: 0 bytes in 0 blocks.
==15606== still reachable: 4 bytes in 1 blocks.
==15606== suppressed: 0 bytes in 0 blocks.

        注意：强烈推荐使用std::vector,array,string,智能指针，以及其他现代C++构造函数，以避免内存渗露。

5、双重删除与无效指针

        一旦使用delete释放与指针相关的内存，它就可以被程序的其它部分使用了。然而，什么也阻挡不了你继续使用这个指针哪，这个指针现在就成了一个悬挂指针。双重删除也是一个问题。如果你对一个指针进行两次delete操作，程序就可能会释放分配给了另一个对象的内存。

        双重删除与使用已经释放了的内存都是难以跟踪的难题，因为其症状并不会立马显现。如果双重删除出现在一个相对短的时间，程序可能会继续工作，因为与其相关的内存可能不会那么快被重新用到，如果一个被删除了的对象马上被用到，很大可能其仍然是完整的，不会出问题。

        当然了，无法保证这样的行为能够正常工作或者继续正常工作。内存分配器无法保证对于已经删除的对象进行保护。即使能够工作，使用已经被删除的对象也是极端糟糕的编程风格。

        为了避免双重删除与使用已经释放了的内存，应该在释放内存后将指针赋值nullptr。

        许多内存渗露检测程序也能够检测到双重删除与使用释放了的对象。