内存泄露 碎片等问题

这个坑其实很大很大。。。。。。

虽然这名字很长,但其实就是一码事,试问你做内存跟踪不是为了看泄露?试问你看到了泄露和碎片不回去优化?哈哈

理论知识咱不具备,所以现实点,从实践出发好了。

我一向干点啥事,都是被勾引的,先是要解决问题,然后又觉得不够过瘾,就变成优化问题本身。这回的任务原本是内存泄露,我东一榔头,西一锤子的,却是满世界乱敲,敲到最后,原来的问题早湮灭了,剩下的,只是自己的问题而已。

内存问题由来已久,最早做c++的时候,包装的很好,这个东西其实不明显,因为多半是new和delete,malloc和free显得特别扎眼,泾渭分明,最大的麻烦也不过是从这里new/malloc,去那里delete/free,这种东西极少,反而很好抓出来暴打五十大板。所以那会名义上boundschecker啥的用了一堆,实际上却没什么技术活,都拼体力去了,反正就几个点,我单步还不成么。

这回却是一个很好的锻炼机会,因为遇到了一个类似photoshop的庞然大物,而且代码从c到c++到c#,满世界的malloc,new,GC,这要泄露起来,可谓是五毒俱全,声色一时无两啊。哈哈哈哈(被吓傻了)

Problem1:内存跟踪

1:方法论

对于内存的跟踪,其实办法很多,我所知道的,可以归为几类

宏定义法:不管现代版的new还是古典版的malloc,#define吃遍天下无敌手啊,#define malloc mymalloc #define new mynew不就成了。

Hook法:其实new和malloc都提供有hook方法,《Windows核心编程》就提到了非著名的crtdbg库(对于初级程序员,这东西少有人知啊)。

重载法:对于C++来说,其实还有个重载全局new的方法可以用。。。。。

工具法:著名工具BoundsChecker,processXP等。。。。。。。。

GC法:GC值得单独拿出来说,因为你没法干涉他,但是又能找到很多工具,比如微软的CLR Profiler,比如收费的.net memory profiler,以及各种重量级。。。

2:世界观

最重要的问题,就是,你的问题是什么,所以我称之为世界观问题,比如,就内存泄露而言,对于纯C++程序而言(现代C++),new和delete以及设计良好的class可以极好的屏蔽内存泄露的问题,所以看到内存泄露,我认为合格的c++程序员应该首先考虑设计的合理性。而对于内存碎片问题,优雅高效的内存分配算法和一个设计合理的memory pool 才是终极兵器。

相对来说,核心问题,也就是最终决定你能不能解决问题的东西,是程序员的内存观念,或者说对内存的理解,这方面推荐《windows核心编程》。至少总得知道用户内存空间只有2G,知道virtualAlloc,知道HeapAlloc,知道dll对内存的共享,知道内存碎片化的后果,知道tls。。。。。。

话说回来,一个全局的内存跟踪器仍然是一大杀器,你说内存有问题,他说内存没问题,你说你优化了,他说效率没有变,你说我把内存全打出来了,吃了多少,费了多少,漏了多少,时间节省了多少,他。。。。。。。。。

最后我选了条通俗易懂的道道,#define malloc/free,当然,你还需要一个c级别的list,我想,就那么多了,虽然一大片废话只得到这么个结果。

3:实践

实践永远比动脑子臆想复杂,比如我臆想着一个define+list就可以开杀的时候,发现还不是那么回事。比如,当你需要跨越多层lib,在所有dll中统计全局内存的时候。事情就变复杂了,首先,你希望看到每个dll自己的内存,接着,你不想牺牲太多效率,然后,你还要结果能够易于访问,最后,别忘了多线程同步。我想破了脑袋,才整出一个临时解决方案的0.1beta版而已。

1:一个公用的memory库,定义一个static变量用来指向memory list,这样可以保证每个使用这个库的dll拥有各自的memorylist。

2:一个全局的FileMapping,保存所有dll中memorylist头指针。这样可以随时遍历全局内存,并且Filemapping是系统级别的可见,甚至可以在其他进程中访问。

3:简单有效的数据结构(包括memoryinfo和globalmemoryinfo),良好的数据同步机制。

 

Problem 2:内存泄露

看到完整的内存统计数据的时候,我乐得那是一个合不拢嘴啊,这个刀基本上是磨了个1/3出来了,简单砍砍柴,那是问题不大。

有了统计信息,我们就可以解决一部分问题了,只要再加上一个snapShot的功能,再加上compare一下,就可以针对问题,发现未释放内存的大小和地址了。对于跟踪大块内存泄露,马上就从蒙昧时代,进化到刀耕火种了。现在只需要一个条件断点,就可以把问题,跟个八九不离十出来。

但再好它也只是个柴刀,装备不够好啊。可是加上了CallStack,那可就是电锯和柴刀,白板和暗金的距离了。这个东西其实有成品,著名的Visual Leak Detector(http://www.codeproject.com/KB/applications/visualleakdetector.aspx)是也,当然商业化的BoundsChecker也挺好,前提是你有破解和一台彪悍无比的机器。以及,vld和boundschecker不会自杀,好吧,我承认我这里都跑不起来,我人品应该没问题吧。。。。。。

自己写一个也不难,StackWalk64函数给好了,抄抄代码也就搞定了,自己用用还是够的。

一般这个阶段是最消耗时间和耐性的,毕竟有了CallStack也还是要自己一行行的去review code,但同理,实际情况永远比你想象的复杂,比如我明明看到全局统计里面,C/C++内存没有涨,可是任务管理器里面已经涨了200MB了,oh my god,这又是怎么一回事。

是的,有一个重要问题是不能忘记的,这里不但有可控的c/c++,还有不可控的C#和.net。我就知道一个真实的事,有一帮人心比天高的开发了一套很高级的j2ee后台服务,号称。。。(此处省略5000字),上线前听说出事了,内存泄露,好吧,java的内存泄露,后来又听说解决了,怎么解决的呢,买了IBM的purify和一年高级服务,然后直接用高级服务从美国弄了个人过来purify了三天,价格?10w+。

GC我实在是不熟悉,只好又去求教Jeffrey Richter 的 《CLR Via C#》,然后被我发现了 CLR Profiler,所以说什么事情都怕楞的,我这个也是初哥蛮干,选项全开,CLR Profiler一开,挂了。内存一路飚涨,直到“Out of Memory”,无语。后来吧,学乖了只开个基本开关,做几次snapshot马上退出,看着内存从1G飚到3G,再飚下来,心里直念阿弥陀佛你老人家早啊。看看结果我也楞了,20寸的显示器完全不够大的,那位借个65寸的给我使使吧,最后没办法,数据拷回去那看电影那个28的屏幕做分析,勉强够啊也就。真不是一般人玩的起的。.Net还真是出了问题,有几个对象死活没有释放,而且还越来越多,貌似什么eventhandler,我的不懂。后来有人找了个商业的.net memory profiler 出来,马上就好多了,那是腰也直了,眼睛也亮了,腿脚也好了啊,你看看人家,内存没占多少,性能影响极少,自带分析界面,可以snapShot,可以compare,还带智能分析。败家的clr profiler啊。

至此问题基本解决了,其实已经可以喝酒聊天,大家party了。剩下的全是我个人兴趣。。。。。

Problem 3:内存碎片

碎片吧,其实也不算是特大问题,俗话说挤一挤总还有的,实在不行,我报错重启总行吧,反正一个client,又不是Server。这也就是说说,以photoshop这种级别的client,内存开的那叫一个恐怖啊。我这随便操作了两三下,得,malloc次数10w,这,这也太离谱了点。。。。。这不是把可怜的2G空间玩死里捏吗。

对于普通程序不太重要的碎片问题,在一跑就是几个月的Server上,和对内存极度渴求的图像,音乐,视频程序中,就变成了暴风源头,一不小心,那可就是一场台风。

对付碎片问题,绝招有两个,一:用linux,二:用memory pool。

第一个答案其实很,怎么说呢,没办法,做Server的人大概都知道,VC的Malloc效率极低,让人无法忍受,而相反,linux的malloc几乎是你能想到最新最快的,所有许多做linxu的人,很干脆的就是直接用malloc/free,才懒得写那劳什子的memory pool。

malloc其实也很多版本,最初的malloc算法也是种类繁多,各执一词,但据说次从N年前,tcmalloc诞生之后,就王者归来了一把,从此再无硝烟。只是由于tcmalloc多线程比较差,所以之后才有linux的ptmalloc和通用版本的nedmalloc做了一些改进。可以毫不夸张的说,用nedmalloc/hoard用上手之后,一般的程序,也就不用优化来优化去了,也不用考虑啥memory pool了,我想,这也是现在malloc算法名声不显的原因吧。

hoard:http://prisms.cs.umass.edu/emery/index.php?page=hoard

nedmalloc:http://www.nedprod.com/programs/portable/nedmalloc/

这些都是基于C的,我们还有一个后起之秀,基于C++的google-perftools,据说性能还要彪悍一些,由于本人VC6,所以就。。。。。

goole-perftools:http://code.google.com/p/google-perftools/

至于Memory Pool,可谓仁者见仁,智者见智了,一般是用在嵌入式和Server上。其他地方,那就根据需求,量身定做,才会合乎需求,提高效率,不然就要画虎不成反类犬了。用了还不如不用。而且对memory pool的管理算法,本人也是头疼的紧,暂时还没有一个特别有效的办法,不知哪里有达者可以教我。

 

Problem 4:内存优化

就我个人而言,是不愿放弃碎片问题的,毕竟对于图像程序,大量碎片伤害太大。所以我的最终方案,既不是替换malloc,也不是构造memory pool,而是第三种选择,一个简单的GC。

说是简单,因为我只做了两件事情,内存重用和定期回收。free不再free,只是设了个标志位,遇到还要malloc同样size的内存时,直接return就好。而为了防止内存无限制增长,还做了定期回收,比如30秒或者一分钟回收一次不再使用的内存。

经过测试,这个方案对于内存碎片问题是革命性的(纯属自夸),在30s回收条件下,malloc的次数整整降了一个数量级,原本10w次的malloc,只需要不到8k,就能完成所需了。而内存占用,也并不比傻傻的malloc/free多出多少来,这也是图像程序的性质决定的,往往都是开一些同样大小的内存,malloc次数又是极高。

接下来的问题,就是比较了,这种方案除了减少碎片以外,到底能带来多大的性能提高呢?

最后,希望能实现一个漂亮的GC算法,提高10倍左右的性能和降低2个数量级的malloc/free次数吧,待续。。。。。

已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页