本文仅限记录自己的一次 内存泄露追踪小记。 可能并不十分适用与大家的情况。而且方法也并不是很smart。仅做记录，能提供个思路更好。
一、 要问调试程序遇到什么问题最头疼， 内存泄露肯定能排在前几名里的。 内存泄露一般是由于 在申请、释放内存的过程中，并没有将其正确的结对使用。 出现了申请了内存，但是未释放或者少释放了内存的情况。 内存泄露问题的出现，可能短时间内不会造成很大的影响。但是如果长时间运行程序， 内存会被逐步蚕食殆尽。 而造成服务器（主机）工作异常的情况，严重的造成其他程序没法正常工作，甚至宕机的情况。
二、遇到、发现内存泄露
内存泄露的问题，肯定不是一眼就看出来的。这个一般是长期观察， 或者某种情况重复执行，并查看内存的使用情况，发现内存可用值逐步变少。而且停止该情况的执行后，内存使用率并不恢复。 此时， 出现内存泄露的问题的可能性就很大了。
三、找到内存泄露的必要条件
发现内存泄露了。最重要的是找到内存泄露的必要条件。最好是找到最一针见血的泄露条件。这个过程可能会比较长，如果情况较简单的话还好说。 几种条件试下来 基本上就能摸个差不多了！ 但是如果碰到较复杂的情况，那么需要多钟条件组合测试。 得出最根本的那个导致泄露的条件，成功就不远了！
四、找到内存泄露的代码
有了问题必现的条件， 那么接下来就得跟代码了（废话。。。）。 根据条件的处理过程一点点缕代码， 查看内存的分配及释放情况。查看是否有少释放的情况。 不过这种方法是最笨的方法。
（1）介绍一个工具valgrind，虽然在我的debug 阶段并未给予太大的帮助，而且还帮了点倒忙。但不妨碍要夸它是一款 很好的跟踪内存问题的工具。
具体的使用方法可以参考 IBM 大神的文章 http://www.ibm.com/developerworks/cn/linux/l-cn-valgrind/
说说它的优点：
不用向代码里特意插入新的跟踪代码。 仅在编译可执行程序时加入 -g 选项。 就可以使用valgrind 工具对其进行 内存调试啦。 方法还算简单些。
但是有一点， 在我使用的程序中，是一个大循环。且是一个后台守护进程。 使用valgrind 就有点不方便了！ 必现条件执行一次，非常之慢。。。 所以根据你的程序实际使用情况，甄别选用。如果没有其他思路的时候，可以使用该工具跑一下，没准就解决了呢！
（2） 笨办法 在调用malloc/new， free/delete 等申请、释放内存的函数处，打印申请过程和一些基本信息（申请空间的大小，地址，也可以使用一个全局变量记下申请、释放的次数）。以便观察哪块有申请后，但没有找到对应的释放地方。
总结来讲， 解决内存泄露没有非常便捷的办法。 预防方法就是规范自己的代码编写， 做好成对的申请与释放。 在处理异常情况返回、退出时记得释放之前申请的内存。养成编码的好习惯。 或者架构软件代码时，可以将内存申请、释放函数封装一下， 增加自己的调试信息进去。多一些必要的调试信息对解决问题有很大的帮助。
出了内存泄露问题也不要太焦虑。没法快速解决问题也不要着急。 如果不是那种一眼就看出来就有泄露的地方， 基本上花费的时间都不会短。所以保持自己debug的热情，别气馁。 一般棘手问题的解决办法大多都是 缺了那么几行代码。找到解决办法后，也不要觉得自己菜鸟。 认为这么简单的问题花费了好长的时间 。 重要的是解决问题的过程。 每解决一个问题，你就进步了一次。