内存管理内幕

为什么必须管理内存

内存管理是计算机编程最为基本的领域之一。在很多脚本语言中，您不必担心内存是如何管理的，这并不能使得内存管理的重要性有一点点降低。对实际编程来说，理解您的内存管理器的能力与 局限性至关重要。在大部分系统语言中，比如 C 和 C++，您必须进行内存管理。本文将介绍手工的、 半手工的以及自动的内存管理实践的基本概念。

追溯到在 Apple II 上进行汇编语言编程的时代，那时内存管理还不是个大问题。您实际上在运行整个系统。系统有 多少内存，您就有多少内存。您甚至不必费心思去弄明白它有多少内存，因为每一台机器的内存数量都相同。 所以，如果内存需要非常固定，那么您只需要选择一个内存范围并使用它即可。

不过，即使是在这样一个简单的计算机中，您也会有问题，尤其是当您不知道程序的每个部分将需要多少 内存时。如果您的空间有限，而内存需求是变化的，那么您需要一些方法来满足这些需求：

确定您是否有足够的内存来处理数据。从可用的内存中获取一部分内存。向可用内存池（pool）中返回部分内存，以使其可以由程序的其他部分或者其他程序使用。

?

实现这些需求的程序库称为?分配程序（allocators），因为它们负责分配和回收内存。程序的动态性越强，内存 管理就越重要，您的内存分配程序的选择也就更重要。让我们来了解可用于内存管理的不同方法，它们的 好处与不足，以及它们最适用的情形。





回页首



C 风格的内存分配程序

C 编程语言提供了两个函数来满足我们的三个需求：

malloc：该函数分配给定的字节数，并返回一个指向它们的指针。 如果没有足够的可用内存，那么它返回一个空指针。free：该函数获得指向由?malloc?分配的内存片段 的指针，并将其释放，以便以后的程序或操作系统使用（实际上，一些?malloc?实现只能将内存归还给程序，而无法将内存归还给操作系统）。

?

物理内存和虚拟内存

要理解内存在程序中是如何分配的，首先需要理解如何将内存从操作系统分配给程序。计算机上的每一个进程都认为自己可以访问所有的物理内存。显然，由于同时在运行多个程序，所以每个进程不可能拥有全部内存。实际上，这些进程使用的是?虚拟内存。

只是作为一个例子，让我们假定您的程序正在访问地址为 629 的内存。不过，虚拟内存系统不需要将其存储在位置为 629 的 RAM 中。实际上，它甚至可以不在 RAM 中 —— 如果物理 RAM 已经满了，它甚至 可能已经被转移到硬盘上！由于这类地址不必反映内存所在的物理位置，所以它们被称为虚拟内存。操作系统维持着一个虚拟地址到物理地址的转换的表，以便计算机硬件可以正确地响应地址请求。并且，如果地址在硬盘上而不是在 RAM 中，那么操作系统将暂时停止您的进程，将其他内存转存到硬盘中，从硬盘上加载被请求的内存， 然后再重新启动您的进程。这样，每个进程都获得了自己可以使用的地址空间，可以访问比您物理上安装的内存更多的内存。

在 32-位 x86 系统上，每一个进程可以访问 4 GB 内存。现在，大部分人的系统上并没有 4 GB 内存， 即使您将 swap 也算上，?每个进程所使用的内存也肯定少于 4 GB。因此，当加载一个进程时， 它会得到一个取决于某个称为?系统中断点（system break）的特定地址的初始内存分配。该地址之后是未被映射的内存 —— 用于在 RAM 或者硬盘中没有分配相应物理位置的内存。因此，如果一个进程运行超出了 它初始分配的内存，那么它必须请求操作系统“映射进来（map in）”更多的内存。（映射是一个表示一一对应关系的数学术语 —— 当内存的虚拟地址有一个对应的物理地址来存储内存内容时，该内存将被映射。）

基于 UNIX 的系统有两个可映射到附加内存中的基本系统调用：

brk：?brk()?是一个非常简单的系统调用。 还记得系统中断点吗？该位置是进程映射的内存边界。?brk()?只是简单地 将这个位置向前或者向后移动，就可以向进程添加内存或者从进程取走内存。mmap：?mmap()，或者说是“内存映像”，类似于?brk()，但是更为灵活。首先，它可以映射任何位置的内存， 而不单单只局限于进程。其次，它不仅可以将虚拟地址映射到物理的 RAM 或者 swap，它还可以将 它们映射到文件和文件位置，这样，读写内存将对文件中的数据进行读写。不过，在这里，我们只关心?mmap?向进程添加被映射的内存的能力。?munmap()?所做的事情与?mmap()?相反。

?

如您所见，?brk()?或者?mmap()?都可以用来向我们的 进程添加额外的虚拟内存。在我们的例子中将使用?brk()，因为它更简单，更通用。

实现一个简单的分配程序

如果您曾经编写过很多 C 程序，那么您可能曾多次使用过?malloc()?和?free()。不过，您可能没有用一些时间去思考它们在您的操作系统中 是如何实现的。本节将向您展示?malloc?和?free?的 一个最简化实现的代码，来帮助说明管理内存时都涉及到了哪些事情。

要试着运行这些示例，需要先?复制本代码清单，并将其粘贴到一个名为 malloc.c 的文件中。接下来，我将一次一个部分地对该清单进行解释。

在大部分操作系统中，内存分配由以下两个简单的函数来处理：

void *malloc(long numbytes)：该函数负责分配?numbytes?大小的内存，并返回指向第一个字节的指针。void free(void *firstbyte)：如果给定一个由先前的?malloc?返回的指针，那么该函数会将分配的空间归还给进程的“空闲空间”。

malloc_init?将是初始化内存分配程序的函数。它要完成以下三件事： 将分配程序标识为已经初始化，找到系统中最后一个有效内存地址，然后建立起指向我们管理 的内存的指针。这三个变量都是全局变量：


清单 1. 我们的简单分配程序的全局变量


我们主要使用连接的指针遍历内存来寻找开放的内存块。这里是代码：

清单 6. 主分配程序
其他 malloc 实现
malloc()?的实现有很多，这些实现各有优点与缺点。在设计一个分配程序时， 要面临许多需要折衷的选择，其中包括：
分配的速度。回收的速度。有线程的环境的行为。内存将要被用光时的行为。局部缓存。簿记（Bookkeeping）内存开销。虚拟内存环境中的行为。小的或者大的对象。实时保证。
?
每一个实现都有其自身的优缺点集合。在我们的简单的分配程序中，分配非常慢，而回收非常快。 另外，由于它在使用虚拟内存系统方面较差，所以它最适于处理大的对象。
还有其他许多分配程序可以使用。其中包括：
Doug Lea Malloc：Doug Lea Malloc 实际上是完整的一组分配程序，其中包括 Doug Lea 的原始分配程序，GNU libc 分配程序和?ptmalloc。 Doug Lea 的分配程序有着与我们的版本非常类似的基本结构，但是它加入了索引，这使得搜索速度更快，并且可以将多个没有被使用的块组合为一个大的块。它还支持缓存，以便更快地再次使用最近释放的内存。?ptmalloc?是 Doug Lea Malloc 的一个扩展版本，支持多线程。在本文后面的?参考资料部分中，有一篇描述 Doug Lea 的 Malloc 实现的文章。BSD Malloc：BSD Malloc 是随 4.2 BSD 发行的实现，包含在 FreeBSD 之中，这个分配程序可以从预先确实大小的对象构成的池中分配对象。它有一些用于对象大小的 size 类，这些对象的大小为 2 的若干次幂减去某一常数。所以，如果您请求给定大小的一个对象，它就简单地分配一个与之匹配的 size 类。这样就提供了一个快速的实现，但是可能会浪费内存。在?参考资料部分中，有一篇描述该实现的文章。Hoard：编写?Hoard 的目标是使内存分配在多线程环境中进行得非常快。因此，它的构造以锁的使用为中心，从而使所有进程不必等待分配内存。它可以显著地加快那些进行很多分配和回收的多线程进程的速度。 在?参考资料部分中，有一篇描述该实现的文章。
?
众多可用的分配程序中最有名的就是上述这些分配程序。如果您的程序有特别的分配需求，那么您可能更愿意编写一个定制的能匹配您的程序内存分配方式的分配程序。不过，如果不熟悉分配程序的设计，那么定制分配程序通常会带来比它们解决的问题更多的问题。要获得关于该主题的适当的介绍，请参阅 Donald Knuth 撰写的?The Art of Computer Programming Volume 1: Fundamental Algorithms?中的第 2.5 节“Dynamic Storage Allocation”（请参阅?参考资料中的链接）。它有点过时，因为它没有考虑虚拟内存环境，不过大部分算法都是基于前面给出的函数。
在 C++ 中，通过重载?operator new()，您可以以每个类或者每个模板为单位实现自己的分配程序。在 Andrei Alexandrescu 撰写的?Modern C++ Design?的第 4 章（“Small Object Allocation”）中，描述了一个小对象分配程序（请参阅?参考资料中的链接）。
基于 malloc() 的内存管理的缺点
不只是我们的内存管理器有缺点，基于?malloc()?的内存管理器仍然也有很多缺点，不管您使用的是哪个分配程序。对于那些需要保持长期存储的程序使用?malloc()?来管理内存可能会非常令人失望。如果您有大量的不固定的内存引用，经常难以知道它们何时被释放。生存期局限于当前函数的内存非常容易管理，但是对于生存期超出该范围的内存来说，管理内存则困难得多。而且，关于内存管理是由进行调用的 程序还是由被调用的函数来负责这一问题，很多 API 都不是很明确。
因为管理内存的问题，很多程序倾向于使用它们自己的内存管理规则。C++ 的异常处理使得这项任务更成问题。有时好像致力于管理内存分配和清理的代码比实际完成计算任务的代码还要多！因此，我们将研究内存管理的其他选择。




回页首

半自动内存管理策略
引用计数
引用计数是一种?半自动（semi-automated）的内存管理技术，这表示它需要一些编程支持，但是它不需要您确切知道某一对象何时不再被使用。引用计数机制为您完成内存管理任务。
在引用计数中，所有共享的数据结构都有一个域来包含当前活动“引用”结构的次数。当向一个程序传递一个指向某个数据结构指针时，该程序会将引用计数增加 1。实质上，您是在告诉数据结构，它正在被存储在多少个位置上。然后，当您的进程完成对它的使用后，该程序就会将引用计数减少 1。结束这个动作之后，它还会检查计数是否已经减到零。如果是，那么它将释放内存。
这样做的好处是，您不必追踪程序中某个给定的数据结构可能会遵循的每一条路径。每次对其局部的引用，都将导致计数的适当增加或减少。这样可以防止在使用数据结构时释放该结构。不过，当您使用某个采用引用计数的数据结构时，您必须记得运行引用计数函数。另外，内置函数和第三方的库不会知道或者可以使用您的引用计数机制。引用计数也难以处理发生循环引用的数据结构。
要实现引用计数，您只需要两个函数 —— 一个增加引用计数，一个减少引用计数并当计数减少到零时释放内存。
一个示例引用计数函数集可能看起来如下所示：

清单 9. 基本的引用计数函数
内存池
内存池是另一种半自动内存管理方法。内存池帮助某些程序进行自动内存管理，这些程序会经历一些特定的阶段，而且每个阶段中都有分配给进程的特定阶段的内存。例如，很多网络服务器进程都会分配很多针对每个连接的内存 —— 内存的最大生存期限为当前连接的存在期。Apache 使用了池式内存（pooled memory），将其连接拆分为各个阶段，每个阶段都有自己的内存池。在结束每个阶段时，会一次释放所有内存。
在池式内存管理中，每次内存分配都会指定内存池，从中分配内存。每个内存池都有不同的生存期限。在 Apache 中，有一个持续时间为服务器存在期的内存池，还有一个持续时间为连接的存在期的内存池，以及一个持续时间为请求的存在期的池，另外还有其他一些内存池。因此，如果我的一系列函数不会生成比连接持续时间更长的数据，那么我就可以完全从连接池中分配内存，并知道在连接结束时，这些内存会被自动释放。另外，有一些实现允许注册清除函数（cleanup functions），在清除内存池之前，恰好可以调用它，来完成在内存被清理前需要完成的其他所有任务（类似于面向对象中的析构函数）。
要在自己的程序中使用池，您既可以使用 GNU libc 的 obstack 实现，也可以使用 Apache 的 Apache Portable Runtime。GNU obstack 的好处在于，基于 GNU 的 Linux 发行版本中默认会包括它们。Apache Portable Runtime 的好处在于它有很多其他工具，可以处理编写多平台服务器软件所有方面的事情。要深入了解 GNU obstack 和 Apache 的池式内存实现，请参阅?参考资料部分中指向这些实现的文档的链接。
下面的假想代码列表展示了如何使用 obstack：

清单 11. obstack 的示例代码



回页首

垃圾收集
垃圾收集（Garbage collection）是全自动地检测并移除不再使用的数据对象。垃圾收集器通常会在当可用内存减少到少于一个具体的阈值时运行。通常，它们以程序所知的可用的一组“基本”数据 —— 栈数据、全局变量、寄存器 —— 作为出发点。然后它们尝试去追踪通过这些数据连接到每一块数据。收集器找到的都是有用的数据；它没有找到的就是垃圾，可以被销毁并重新使用这些无用的数据。为了有效地管理内存，很多类型的垃圾收集器都需要知道数据结构内部指针的规划，所以，为了正确运行垃圾收集器，它们必须是语言本身的一部分。
收集器的类型
?
复制（copying）：?这些收集器将内存存储器分为两部分，只允许数据驻留在其中一部分上。它们定时地从“基本”的元素开始将数据从一部分复制到另一部分。内存新近被占用的部分现在成为活动的，另一部分上的所有内容都认为是垃圾。另外，当进行这项复制操作时，所有指针都必须被更新为指向每个内存条目的新位置。因此，为使用这种垃圾收集方法，垃圾收集器必须与编程语言集成在一起。标记并清理（Mark and sweep）：每一块数据都被加上一个标签。不定期的，所有标签都被设置为 0，收集器从“基本”的元素开始遍历数据。当它遇到内存时，就将标签标记为 1。最后没有被标记为 1 的所有内容都认为是垃圾，以后分配内存时会重新使用它们。增量的（Incremental）：增量垃圾收集器不需要遍历全部数据对象。因为在收集期间的突然等待，也因为与访问所有当前数据相关的缓存问题（所有内容都不得不被页入（page-in）），遍历所有内存会引发问题。增量收集器避免了这些问题。保守的（Conservative）：保守的垃圾收集器在管理内存时不需要知道与数据结构相关的任何信息。它们只查看所有数据类型，并假定它们?可以全部都是指针。所以，如果一个字节序列可以是一个指向一块被分配的内存的指针，那么收集器就将其标记为正在被引用。有时没有被引用的内存会被收集，这样会引发问题，例如，如果一个整数域中包含一个值，该值是已分配内存的地址。不过，这种情况极少发生，而且它只会浪费少量内存。保守的收集器的优势是，它们可以与任何编程语言相集成。
?
Hans Boehm 的保守垃圾收集器是可用的最流行的垃圾收集器之一，因为它是免费的，而且既是保守的又是增量的，可以使用?--enable-redirect-malloc?选项来构建它，并且可以将它用作系统分配程序的简易替代者（drop-in replacement）（用?malloc/?free?代替它自己的 API）。实际上，如果这样做，您就可以使用与我们在示例分配程序中所使用的相同的?LD_PRELOAD?技巧，在系统上的几乎任何程序中启用垃圾收集。如果您怀疑某个程序正在泄漏内存，那么您可以使用这个垃圾收集器来控制进程。在早期，当 Mozilla 严重地泄漏内存时，很多人在其中使用了这项技术。这种垃圾收集器既可以在 Windows? 下运行，也可以在 UNIX 下运行。
垃圾收集的一些优点：
您永远不必担心内存的双重释放或者对象的生命周期。使用某些收集器，您可以使用与常规分配相同的 API。
?
其缺点包括：
使用大部分收集器时，您都无法干涉何时释放内存。在多数情况下，垃圾收集比其他形式的内存管理更慢。垃圾收集错误引发的缺陷难于调试。如果您忘记将不再使用的指针设置为 null，那么仍然会有内存泄漏。
?




回页首

结束语
一切都需要折衷：性能、易用、易于实现、支持线程的能力等，这里只列出了其中的一些。为了满足项目的要求，有很多内存管理模式可以供您使用。每种模式都有大量的实现，各有其优缺点。对很多项目来说，使用编程环境默认的技术就足够了，不过，当您的项目有特殊的需要时，了解可用的选择将会有帮助。下表对比了本文中涉及的内存管理策略。
表 1. 内存分配策略的对比
?
策略分配速度回收速度局部缓存易用性通用性实时可用SMP 线程友好定制分配程序取决于实现取决于实现取决于实现很难无取决于实现取决于实现简单分配程序内存使用少时较快很快差容易高否否GNU?malloc中快中容易高否中Hoard中中中容易高否是引用计数N/AN/A非常好中中是（取决于?malloc?实现）取决于实现池中非常快极好中中是（取决于?malloc?实现）取决于实现垃圾收集中（进行收集时慢）中差中中否几乎不增量垃圾收集中中中中中否几乎不增量保守垃圾收集中中中容易高否几乎不
?


参考资料
您可以参阅本文在 developerWorks 全球站点上的?英文原文。?
Web 上的文档
GNU C Library 手册的 obstacks 部分?提供了 obstacks 编程接口。?

Apache Portable Runtime 文档?描述了它们的池式分配程序的接口。?
基本的分配程序
Doug Lea 的 Malloc?是最流行的内存分配程序之一。?

BSD Malloc?用于大部分基于 BSD 的系统中。?

ptmalloc?起源于 Doug Lea 的 malloc，用于 GLIBC 之中。?

Hoard?是一个为多线程应用程序优化的?malloc?实现。?

GNU Memory-Mapped Malloc（GDB 的组成部分）?是一个基于?mmap()?的?malloc?实现。?
池式分配程序
GNU Obstacks（GNU Libc 的组成部分）是安装最多的池式分配程序，因为在每一个基于 glibc 的系统中都有它。?

Apache 的池式分配程序（Apache Portable Runtime 中）?是应用最为广泛的池式分配程序。?

Squid?有其自己的池式分配程序。?

NetBSD?也有其自己的池式分配程序。?

talloc?是一个池式分配程序，是 Samba 的组成部分。?
智能指针和定制分配程序
Loki C++ Library?有很多为 C++ 实现的通用模式，包括智能指针和一个定制的小对象分配程序。?
垃圾收集器
Hahns Boehm Conservative Garbage Collector?是最流行的开源垃圾收集器，它可以用于常规的 C/C++ 程序。?
关于现代操作系统中的虚拟内存的文章