转载--大内高手—内存管理器(一)

大内高手—内存管理器(一)

转载时请注明出处：http://blog.csdn.net/absurd

作为一个C程序员，每天都在和malloc/free/calloc/realloc系列函数打交道。也许和它们混得太熟了，反而忽略了它们的存在，甚至有了三五年的交情，仍然对它们的实现一无所知。相反，一些好奇心未泯的新手，对它们的实现有着浓厚的兴趣。当初正是一个新同事的问题，促使我去研究内存管理算法的实现。

内存管理算法多少有些神秘，我们很少想着去实现自己的内存管理算法，这也难怪：有这样需求的情况并不多。其实，至于内存分配算法的实现，说简单也简单，说复杂也复杂。要写一个简单的，或许半天时间就可以搞掂，而要写一个真正实用的，可能要花上你几周甚至几个月的时间。

malloc和free是两个核心函数，而calloc和realloc之所以存在，完全是为了提高效率的缘故。否则完全可以用malloc和free的组合来模拟它们。

拿calloc函数的实现来说，在32位机上，内存管理器保证内存至少是4字节对齐的，其长度也会扩展到能被4字节整除，那么其清零算法就可以优化。可以一次清零4个字节，这大大提高清零速度。

拿realloc函数的实现来说，如果realloc的指针后面有足够的空间，内存管理器可以直接扩展其大小，而无须拷贝原有内容。当然，新大小比原来还小时，更不拷贝了。相反，通过malloc和free来实现realloc时，两种情况下都要拷贝，效率自然会低不少。

另外还有两个非机标准的，但很常用的函数，也涉及到内存分配：strdup和strndup。这两个函数在linux和win32下都支持，非常方便。这完全可以用malloc来模拟，而且没有性能上的损失。

这里我们主要关注malloc和free两个函数的实现，并以glibc 2.3.5(32位linux) 为例分析。

内存管理器的目标

内存管理器为什么难写？在设计内存管理算法时，要考虑什么因素？管理内存这是内存管理器的功能需求。正如设计其它软件一样，质量需求一样占有重要的地位。分析内存管理算法之前，我们先看看对内存管理算法的质量需求有哪些：

l 最大化兼容性

要实现内存管理器时，先要定义出分配器的接口函数。接口函数没有必要标新立异，而是要遵循现有标准(如POSIX或者Win32)，让使用者可以平滑的过度到新的内存管理器上。

l 最大化可移植性

通常情况下，内存管理器要向OS申请内存，然后进行二次分配。所以，在适当的时候要扩展内存或释放多余的内存，这要调用OS提供的函数才行。OS提供的函数则是因平台而异，尽量抽象出平台相关的代码，保证内存管理器的可移植性。

l 浪费最小的空间

内存管理器要管理内存，必然要使用自己一些数据结构，这些数据结构本身也要占内存空间。在用户眼中，这些内存空间毫无疑问是浪费掉了，如果浪费在内存管理器身的内存太多，显然是不可以接受的。

内存碎片也是浪费空间的罪魁祸首，若内存管理器中有大量的内存碎片，它们是一些不连续的小块内存，它们总量可能很大，但无法使用，这也是不可以接受的。

l 最快的速度

内存分配/释放是常用的操作。按着2/8原则，常用的操作就是性能热点，热点函数的性能对系统的整体性能尤为重要。

l 最大化可调性（以适应于不同的情况）

内存管理算法设计的难点就在于要适应用不同的情况。事实上，如果缺乏应用的上下文，是无法评估内存管理算法的好坏的。可以说在任何情况下，专用算法都比通用算法在时/空性能上的表现更优。

为每种情况都写一套内存管理算法，显然是不太合适的。我们不需要追求最优算法，那样代价太高，能达到次优就行了。设计一套通用内存管理算法，通过一些参数对它进行配置，可以让它在特定情况也有相当出色的表现，这就是可调性。

l 最大化局部性(Locality)

大家都知道，使用cache可以提高程度的速度，但很多人未必知道cache使程序速度提高的真正原因。拿CPU内部的cache和RAM的访问速度相比，速度可能相差一个数量级。两者的速度上的差异固然重要，但这并不是提高速度的充分条件，只是必要条件。

另外一个条件是程序访问内存的局部性(Locality)。大多数情况下，程序总访问一块内存附近的内存，把附近的内存先加入到cache中，下次访问cache中的数据，速度就会提高。否则，如果程序一会儿访问这里，一会儿访问另外一块相隔十万八千里的内存，这只会使数据在内存与cache之间来回搬运，不但于提高速度无益，反而会大大降低程序的速度。

因此，内存管理算法要考虑这一因素，减少cache miss和page fault。

l 最大化调试功能

作为一个C/C++程序员，内存错误可以说是我们的噩梦，上一次的内存错误一定还让你记忆犹新。内存管理器提供的调试功能，强大易用，特别对于嵌入式环境来说，内存错误检测工具缺乏，内存管理器提供的调试功能就更是不可或缺了。

l 最大化适应性

前面说了最大化可调性，以便让内存管理器适用于不同的情况。但是，对于不同情况都要去调设置，无疑太麻烦，是非用户友好的。要尽量让内存管理器适用于很广的情况，只有极少情况下才去调设置。

设计是一个多目标优化的过程，有些目标之间存在着竞争。如何平衡这些竞争力是设计的难点之一。在不同的情况下，这些目标的重要性又不一样，所以根本不存在一个最好的内存分配算法。

关于glibc的内存分配器，我们并打算做代码级分析，只谈谈几点有趣的东西：

1. Glibc分配算法概述：

l 小于等于64字节：用pool算法分配。

l 64到512字节之间：在最佳凭配算法分配和pool算法分配中取一种合适的。

l 大于等于512字节：用最佳凭配算法分配。

l 大于等于128K：直接调用OS提供的函数(如mmap)分配。

2. Glibc扩展内存的方式：

l int brk(void *end_data_segment);

本函数用于扩展堆空间（堆空间的定义可参考内存模型一章），用end_data_segment指明堆的结束地址。

l void *sbrk(ptrdiff_t increment);

本函数用于扩展堆空间（堆空间的定义可参考内存模型一章），用increment指定要增加的大小。

l void*mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset);

本函数用于分配大块内存了，如前面所述大于128K的内存。

3. 空指针和零长度内存

l free(NULL)会让程序crash吗？答案是不会，标准C要求free接受空指针，然后什么也不做。

l malloc(0)会分配成功吗？答案是会的，它会返回一块最小内存给你。

4. 对齐与取整

l 内存管理器会保证分配出来的内存地址是对齐的，通常是4或8字节对齐。

l 内存管理器会对要求内存长度取整，让内存长度能被4或8的整除。

5. 已经分配内存的结构

如果前面有一块有效内存块的，则第一个size_t指明前一块内存的大小。

第二个size_t指明自己的大小，同时还指明：自己是不是用mmap分配的(M)，前面是否有一个效内存块（P）。你可能觉得奇怪，在32位机上，sizeof(size_t)就是32位，怎么还能留下两个位来保存标志呢？前面我们说了，会对内存长度取整，保证最低2或3bits为0，即是空闲的。

6. 空闲内存的管理

由此可以看出，最小内存块的长度为16字节：

sizeof(size_t) +

sizeof(size_t) +

sizeof(void*) +

sizeof(void*) +

0

这一招非常管用，第一次看到时，感觉简直太巧妙了。这使得无需要额外的内存来管理空闲块，利用空闲块自己，把空闲块强制转换成一个双向链表就行了。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=842292