码迷,mamicode.com
首页 > 系统相关 > 详细

Linux 内存泄露小结

时间:2017-01-17 10:32:16      阅读:221      评论:0      收藏:0      [点我收藏+]

标签:lin   font   复杂   没有   art   处理过程   微软   打印   守护进程   

本文仅限记录自己的一次 内存泄露追踪小记。 可能并不十分适用与大家的情况。而且方法也并不是很smart。仅做记录,能提供个思路更好。 

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

Linux 内存泄露小结

标签:lin   font   复杂   没有   art   处理过程   微软   打印   守护进程   

原文地址:http://www.cnblogs.com/wanhl/p/6291815.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!