C++内存管理变革(2):最袖珍的垃圾回收器
从一开始产生以来(刚new出来),到对象销毁这整个过程,它的数据都处于完备状态,是自洽的。
由于垃圾回收器负责对象的回收,它自然不止需要关注对象申请的内存的释放,同时也需要保证,在对象销毁之前它的析构过程被调用。上文我们为了关注内存管理过程,把自动析构过程需要的代码均去除了。为了支持自动析构,AutoFreeAlloc类增加了以下成员:
如果一个类存在析构,则它需要在Alloc内存的同时指定析构函数。代码如下:
只要通过该Alloc函数申请的内存,我们在Clear中就可以调用相应的析构。当然,Clear函数需要补充自动析构相关的代码:
时间性能分析 void* AutoFreeAlloc::Alloc(size_t cb); OOP技术带来一个内存上的问题是,对象粒度越来越细了,对象基本上都是小对象。这就对内存管理的性能提出了很高的要求。 如果我们以对象大小平均为32字节计算的话,每2048/32 = 64操作中,只有一次操作满足m_end – m_begin < cb的条件。也就是说,在通常情况(63/64 = 98.4%的概率)下,Alloc操作只需要一个减法操作就完成内存分配。 我说这是世界上最快速的内存分配算法,也许你对此仍然抱有怀疑态度。但是可以肯定的一点是,要突破它的性能极限我觉得已经很难很难了。
一般内存管理器通常一次内存分配操作就需调用相应的一次Free操作。但是AutoFreeAlloc不针对每一个Alloc进行释放,而是针对每一个_MemBlock。仍假设对象平均大小为32字节的话,也就是相当于把64次Alloc操作合并,为其提供一次相应的Free过程。 ★ 结论:AutoFreeAlloc在时间上的性能,大约比普通的malloc/free的快64倍。 空间性能分析 我们知道,一般内存管理器为了将用户申请的内存块管理起来,除了用户需要的cb字节内存外,通常额外还提供一个内存块的头结构,通过这个头结构将内存串连成为一个链表。一般来讲,这个头结构至少有两项(可能还不止),示意如下:
仍然假设平均Alloc一次的内存为32字节。则一次malloc分配过程,就会浪费8/32 = 25%的内存。并且由于大量的小对象存在,整个内存中的碎片(指那些自由但无法被使用的内存)将特别严重。 而AutoFreeAlloc的Alloc没有如何额外开销。整个AutoFreeAlloc,只有在将_MemBlock串为链表的有一个额外的pPrev指针,加上_MemBlock是malloc出来的,有额外的8字节开销。总计浪费(4+8)/2048 = 0.6%的内存,几乎可以忽略不计。 后记 AutoFreeAlloc于2004-5-21开发,只有100行的代码量。但是,这个组件获得了空前的成功,它的应用范围逐步扩大,超过了我最初实现这个组件时的预计。 我渐渐冷静下来,考虑这其中蕴涵的道理。我逐步领会到了,它的成功之处,不是它在时间、空间性能的高效,而是在于它帮助C++程序员解决了最大的难题——内存管理。虽然,这个解决方案并不是完整的。 AutoFreeAlloc是一个切入点,从它身上,让我明白了C++的new/delete的不合理;STL引入的allocator是一个切入点,从它身上,让我明白了内存管 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |