9.9 动态内存分配

        虽然可以使用低级的 mmap 和 munmap 函数来创建和删除虚拟内存的区域，但是 C程序员还是会觉得当运行时需要额外虚拟内存时，用 动态内存分配器 更方便，也有更好的可移植性。

         动态内存分配器维护着一个进程的虚拟内存区域，称为 堆（heap）。系统之间细节不同，但是不失通用性，假设堆是一个请求二进制零的区域，它紧接在未初始化的数据区域后开始，并向上生长（向更高的地址）。对于每个进程 内核维护着一个变量 brk(读做 ‘ break ')，它指向堆的顶部

         分配器将堆视为一组不同大小的块（block）的集合来维护。每个块就是一个连续的虚拟内存片（chunk），要么是已分配的，要么是空闲的。已分配的块显示地保留为供应用程序使用。空闲块可用来分配。空闲块保持空闲，直到它显示地被应用所分配。一个已分配的块保持已分配状态，直到它被释放，这种释放要么是应用程序显示执行的，要么是内存分配器自身隐式执行的。

        分配器有两种基本风格。两种风格都要求应用显示地分配块，它们不同之处在于由哪个实体来负责释放已分配的块。

        ① 显示分配器：要求应用显示地释放任何已分配的块。例如，C标准库提供一种 malloc 程序包的显示分配器。C 程序通过调用 malloc 函数来分配一个块，并通过调用 free 函数来释放一个块。 C++ 中的 new 和 delete 操作符与 C 中的 malloc 和 free 相当。 

        ② 隐式分配器：另一方面，要求分配器检测一个已分配块何时不再被程序所使用，那么就释放这个块。隐式分配器也叫做 垃圾收集器，而自动释放未使用的已分配块的过程叫做垃圾收集。例如，诸如 Lisp ML 以及 Java 之类的高级语言就依赖垃圾收集来释放已分配的块。

9.9.1 malloc 和 free 函数

        C标准库提供了一个称为 malloc 程序包的显示分配器。程序通过调用 malloc 函数从堆中分配块。 malloc 函数返回一个指针，指针大小为至少 size 字节的内存块，这个块会为可能包含在这个块内的任何数据对象类型做对齐。实际中，对齐依赖于编译代码在 32 位模式 （gcc -m32）还是 64位模式（默认）中运行的。 在 32 位模式中，malloc 返回的块的地址总是 8 的倍数。 在 64位模式中，该地址总是16的倍数。

        如果 malloc 遇到问题（例如，程序要求的内存块比可用的虚拟内存还要大），那么它就返回 NULL，并设置 errno。 malloc 不初始化它返回的内存。那些想要已初始化的动态内存的应用程序可以使用 calloc，calloc 是一个基于 malloc 的瘦包装函数，它将分配的内存初始化为零。想要改变一个以前已分配的大小，可以使用 realloc 函数。

        动态内存分配器，例如 malloc，可以通过使用 mmap 和 munmap 函数，显示地分配和释放堆内存，或者还可以使用 sbrk 函数：

 sbrk 函数通过将内核的 brk 指针增加 incr 来扩展和收缩堆。如果成功，它就返回 brk 的旧值，否则返回 -1，并将 errno 设置为 ENOMEM。如果 incr 为 0，那么 sbrk 就返回 brk 的当前值。用一个为负的 incr 来调用 sbrk 是合法的，而且很巧妙，因为返回值（brk 的旧值）指向距新堆顶向上 abs（incr）字节处。

        程序是通过调用 free 函数来释放已分配的堆块

         ptr 参数必须指向一个从 malloc、calloc 或者 realloc 获得的已分配块的起始位置。如果不是，那么 free 行为就是未定义的。更糟的是，既然它什么都不返回，free 就不会告诉应用出现了错误。就像在 9.11节看到的，会产生一些令人迷惑的运行时错误。

        图 9-34 展示了一个 malloc 和 free 的实现是如何管理一个 C 程序的 16字的（非常）小的堆的。每个方框代表了一个 4字节的字。粗线标出的矩形对应于已分配块（有阴影的）和空闲块（无阴影的）。初始时，堆是由一个大小为 16 个字的，双字对齐的，空闲块组成的。（假设分配器返回的块是 8字节双字边界对齐的）。

9.9.2 为什么要使用动态内存分配

        程序使用动态内存分配的最重要原因是经常直到程序实际运行时，才知道某些数据结构的大小。 例如，假设编写一个 C 程序，它读一个 n 个 ASCII 码整数的链表，每一行一个整数，从 stdin 到一个 C数组。输入是由整数 n 和接下来要读和存储到数组中的 n 个整数组成的。最简单的方法就是静态地定义这个数组，它的最大数组大小是硬编码的：

        像这样用硬编码的大小来分配数组通常不是一种好方法。MAXN 的值是任意的，与机器上可用的虚拟内存的实际数量没有关系。而且，如果这个程序的使用者想读取一个比 MAXN 大的文件，唯一的办法就是用一个更大的 MAXN 值来重新编译这个程序。虽然对于简单的示例来说不成问题，但是硬编码数组界限的出现对于拥有百万行代码和大量使用者的大型软件产品而言，会变成一场维护的噩梦。

        一种更好的方法是在运行时，在已知了 n 的值之后，动态地分配这个数组。使用这种方法，数组大小的最大值就只由可用的虚拟内存数量来限制了。 

9.9.3 分配器的要求和目标

        显示分配器必须在一些相当严格的约束条件下工作：

        ① 处理任意请求序列。一个应用可以由任意的分配请求和释放请求序列，只要满足约束条件：每个释放请求必须对应于一个当前已分配的块，这个块是由一个以前的分配请求获得的。因此，分配器不可以假设分配和释放请求的顺序。例如，分配器不能假设所有的分配请求都有相匹配的释放请求，或者有相匹配的分配和空闲请求是嵌套的。

        ② 立即响应请求。分配器必须立即响应分配请求。因此，不允许分配器为了提高性能重新排列或者缓冲请求。

        ③ 只使用堆。为了使分配是可扩展的，分配器使用的任何非标量数据结构都必须保存在堆里

        ④ 对齐块（对齐要求）。分配器必须对齐块，使得它们可以保存任何类型的数据对象。

        ⑤ 不修改已分配的块。 分配器只能操作或者改变空闲块。特别是：一旦块被分配了，就不允许修改或者移动它了。因此，诸如压缩已分配块这样的技术是不允许使用的。 

这些限制条件下，分配器的编写者试图实现吞吐率最大化和内存使用率最大化，而这两个性能目标通常是相互冲突的。

        目标1：最大化吞吐率。假定 n 个分配和释放请求的某种序列：

希望一个分配器的吞吐率最大化，吞吐率定义为每个单位时间里完成的请求数。例如，如果一个分配器在 1 秒内完成 500 个分配请求和释放请求，那么它的吞吐率就是每秒 1000 次操作。一般而言，可以通过使满足分配和释放请求的平均时间最小化来使吞吐量最大化。正如看到的，开发一个具有合理性能的分配器并不困难，所谓合理性能是指一个分配请求的最糟运行时间与空闲块的数量成线性关系，而一个释放请求的运行时间是个常数。 

        目标2：最大化内存利用率。实际上，一个系统中被所有进程分配的虚拟内存的全部数量是受磁盘上交换空间的数量限制的。好的程序员知道虚拟内存是一个有限的空间，必须高效地使用。对于可能被要求分配和释放大块内存的动态内存分配器来说，尤其这样。 

        有很多方式来描述一个分配器使用堆的效率如何：最有用的标准是 峰值利用率。给定 n 个分配和释放请求的某种顺序 

         如果一个应用程序请求一个 p 字节的块，那么得到的已分配块的有效载荷是 p字节。在请求 Rk 完成之后，聚集有效载荷表示为 Pk，为当前已分配的块的有效载荷之和，而 Hk 表示堆的当前的（单调非递减的）大小。 那么，前 k+1 个请求的峰值利用率，表示为 Uk，通过下式得到：

那么分配器的目标就是在整个序列中使峰值利用率 Un-1 最大化。在最大化吞吐率和最大化利用率之间是互相牵制的，特别是，以堆利用率为代价，很容易编写出吞吐率最大化的分配器。分配器设计中的一个挑战就是在两个目标之间找到一个适当的平衡。

9.9.4 碎片

        造成堆利用率很低的主要原因是一种称为 碎片 的现象，当虽然有未使用的内存但不能用来满足分配请求时，就发生这种现象。有两种形式的碎片：内部碎片和外部碎片。 

        内部碎片是一个已分配块比有效载荷大时发生的。很多原因都可能造成这个问题。例如，一个分配器的实现可能对已分配块强加一个最小的大小值，而这个大小要比某个请求的有效载荷大。或者如图9-34b中看到，分配器可能增加块大小以满足对齐约束条件。

        内部碎片的量化是简单明了的。它就是已分配块大小和它们的有效载荷大小之差的和。因此，在任何时刻，内部碎片的数量只取决于以前请求的模式和分配器的实现模式。 

        外部碎片是当空闲内存合计起来足够满足一个分配请求，但是没有一个单独的空闲块足够大可以来处理这个请求时发生的。 例如，如图9-34e中的请求要求 6 个字，而不是两个字，那么如果不向内核请求额外的虚拟内存就无法满足这个请求，即使在堆中仍然有 6 个空闲的字。问题的产生是由于这 6 个字是分在两个空闲块中的。

        外部碎片比内部碎片的量化困难的多，因为它不仅取决于以前请求的模式和分配器的实现方式，还取决于将来请求的模式。例如，假设在 k 个请求之后，所有空闲块的大小都恰好是 4 个字。堆会有外部碎片吗？ 这取决于将来请求的模式。如果将来所有的分配请求都要求小于或者等于 4 个字的块，那么就不会有外部碎片。另一方面，如果有一个或多个请求要求比 4个字大的块，这个堆就会有外部碎片。 

        因为外部碎片难以量化且不可能预测，所以分配器通常采用启发式策略来试图维持少量的大空闲块，而不是维持大量的小空闲块。 

9.9.5 实现问题 

        最简单的分配器会把堆组织成一个大的字节数组，还有一个指针p，初始指向这个数组的第一个字节。为了分配 size 个字节，malloc 将 p 的当前值保存在栈里，将 p 增加 size，并将 p 的旧值返回到调用函数。 free 只是简单地返回到调用函数，而不做其他任何事情。 

         这个简单的分配器是设计中的一种极端情况。因为每个 malloc 和 free 只执行很少量的指令，吞吐率会极好。然而，因为分配器从不重复使用任何块，内存利用率极差，一个实际的分配器要在吞吐量和利用率之间把握好平衡，就必须考虑以下问题：

        ① 空闲块组织：如何记录空闲块？

        ② 放置：如何选择一个合适的空闲块来放置一个新分配的块

        ③ 分割：在将一个新分配的块放置到某个空闲块之后，如何处理这个空闲块中的剩余部分

        ④ 合并：如何处理一个刚刚被释放的块？

因为放置，分割以及合并这样的基本技术贯穿在许多不同的空闲块组织中，所以我们将在一种叫做隐式空闲链表的简单空闲块组织结构中来介绍，

9.9.6 隐式空闲链表

        任何实际的分配器都需要一些数据结构，允许它来区别块边界，以及区别已分配块和空闲块。大多数分配器将这些信息嵌入块本身。一个简单的方法如图9-35所示。

        在这种情况，一个块是由一个字的头部，有效载荷，以及可能的一些额外的填充组成的。头部编码了这个块的大小（包括头部和所有的填充），以及这个块是已分配的还是空闲的。如果强加一个双字的对齐约束条件，那么块大小就总是 8 的倍数，且块大小的最低 3 位总是零。因此，我们只需要内存大小的 29 个高位，释放剩余的 3 位来编码其他信息。这种情况中，用其中的最低位（已分配位）来指明这个块是已分配的还是空闲的。

例如，假设有一个已分配的块，大小为 24（0x18）字节。它的头部将是 0x00000018 | 0x1 = 0x00000019

类似地 一个块大小为 40（0x28）字节的空闲块有如下的头部： 0x00000028 | 0x0 = 0x00000028

头部后面就是应用调用 malloc 时请求的有效载荷。有效载荷后面是一片不使用的填充块，其大小可以是任意的。 需要填充有很多原因。比如，填充可能是分配器策略的一部分，用来对付外部碎片。或者也需要用它来满足对齐要求。

        假设块的格式如图9-35，可以将堆组织为一个连续的已分配块和空闲块的序列，如图9-36。

 称这种结构为隐式空闲链表，是因为空闲块是通过头部中的大小字段隐含地连接的。分配器可以通过遍历堆中所有块，从而间接地遍历整个空闲块的集合。注意，需要某种特殊标记的结束块，在这个示例中，就是一个设置了已分配位而大小为零的终止头部。

        隐式空闲链表的优点是简单，显著缺点是任何操作的开销，例如放置分配的块，要求对空闲链表进行搜索，该搜索所需时间与堆中已分配块和空闲块的总数呈线性关系。 

        很重要的一点就是意识到系统对齐要求和分配器对块格式的选择会对分配器上的最小块大小有强制要求。没有 已分配块或者空闲块可以比这个最小值还小。例如，如果我们假设一个双字的对齐要求，那么每个块大小都必须是双字（8字节）的倍数。因此，图9-35的块格式就导致最小的块大小为 两个字：一个字作头，另一个字维持对齐要求。即使应用只请求一字节，分配器也仍然要创建两个字的块。 

9.9.7 放置已分配的块

        当一个应用请求一个 k 字节的块时，分配器搜索空闲链表，查找一个足够大可以放置所请求块的空闲块。分配器执行这种搜索的方式是由放置策略确定的。一些常见的策略是 首次适配（first fit），下一次适配（next fit）和 最佳适配（best fit）

        首次适配从头开始搜索空闲链表，选择第一个合适的空闲块，下一次适配 和 首次适配很相似，只不过是从链表的起始处开始每次搜索，而是从上一次查询结束的地方开始。最佳适配 检查每个空闲块，选择适合所需请求大小的最小空闲块。

        首次适配的优点是它趋向于将大的空闲块保留在链表的后面。缺点是它趋向于在靠近链表起始处留下小空闲块的碎片，增加了对较大块的搜索时间。下一次适配是由 Donald Knuth 作为首次适配的一种代替品最早提出的，源于这样的想法：如果我们上一次在某个空闲块已经发现了一个匹配，那么很可能下一次我们也能在这个剩余块中发现匹配。下一次适配比首次适配运行起来明显要快一些，尤其是当链表的前面布满了许多小的碎片时。 然而，一些研究表明，下一次适配的内存利用率要比首次适配低很多。研究还表明，最佳适配比首次适配和下一次适配的内存利用率要高一些。然而，在简单空闲链表组织结构中（比如隐式空闲链表），使用最佳适配的缺点是他要求对堆进行彻底的搜索。在后面，将看到分离式空闲链表组织，它接近于最佳适配策略，不需要进行彻底的堆搜索。

9.9.8 分割空闲块 

        一旦分配器找到一个匹配的空闲块，它就必须做另一个策略决定，分配这个空闲块中多少空间。 一个选择是用整个空闲块。虽然这种方法简单而快捷，但是主要的缺点是它会造成内部碎片。如果放置策略趋向于产生好的匹配，那么额外的内部碎片也是可以接受的。 

        然而，如果匹配不太好，那么分配器通常会选择将这个空闲块分割为两部分。第一部分变成分配块，而剩下的变成一个新的空闲块。 图 9-37 展示了分配器如何分割图 9-36 中 8个字的空闲块，来满足一个应用的对堆内存 3个字的请求 

9.9.9 获取额外的堆内存

        如果分配器不能为请求块找到合适的空闲块将会发生什么呢？一个选择是通过合并那些在内存中物理上相邻的空闲块来创建一些更大的空闲块（下一节描述）。然而，如果这样还是不能生成一个足够大的块，或者如果空闲块已经最大程度地合并了，那么分配器就会调用 sbrk 函数，向内核请求额外的堆内存。分配器将额外的内存转化成一个大的空闲块，将这个块插入到空闲链表中，然后被请求的块放置在这个新的空闲块中。

9.9.10 合并空闲块

         当分配器释放一个已分配块时，可能有其他空闲块与这个新释放的空闲相邻。这些邻接的空闲块可能引起一种现象，叫做假碎片，就是有许多可用的空闲块被切割成为小的，无法使用的空闲块。比如，图 9-38 展示了释放图 9-37 中分配的块后得到的结果。结果是两个相邻的空闲块，每一个的有效载荷都为 3 个字。因此，接下来对一个 4 字有效载荷的请求就会失败，即使两个空闲块的合计大小足够大，可以满足这个请求。

 为了解决加碎片问题，任何实际的分配器都必须合并相邻的空闲块，这个过程称为合并。这时出现了一个重要的策略决定，那就是何时执行合并。分配器可以选择立即合并，也就是在每次一个块被释放时，就合并所有的相邻块。或者也可以选择 推迟合并，就是等到某个稍晚的时候再合并空闲块。例如，分配器可以推迟合并，知道某个分配请求失败，然后扫描整个堆，合并所有的空闲块

        立即合并简单明了，可以在常数时间内执行完成，但是对于某些请求模式，这种方式会产生一种形式的抖动，块会反复地合并，然后分割。例如，图 9-38 中，反复地分配和释放一个 3 字的块将产生大量不必要的分割和合并。 在对分配器的讨论中，我们会假设使用立即合并，但是应该了解， 快速的分配器通常会选择某种形式的推迟合并。

9.9.11 带边界标记的合并

        分配器是如何实现合并的？称当前想要释放的块为当前块。那么，合并（内存中的）下一个空闲块很简单而且高效。当前块的头部指向下一个块的头部，可以检查这个指针以判断下一个指针是否空闲的，如果是，就将它的大小简单地加到当前块头部的大小上，这两个块在常数时间内被合并。 

        如何合并前面的块呢？ 给定一个带头部的隐式空闲链表，唯一的选择将是搜索整个链表，记住前面块的位置，直到我们到达当前块。使用隐式空闲链表，意味着每次调用 free 需要的时间都与堆的大小成线性关系。即使使用更复杂精细的空闲链表组织，搜索时间也不会是常数。

        knuth 提出了一种聪明而通用的技术，叫做 边界标记，允许在常数时间内进行对前面块的合并。这种思想，如图9-39 所示，是在每个块的结尾处添加一个脚部（footer，边界标记），其中脚部就是头部的一个副本。如果每个块包括这样一个脚部，那么分配器就可以通过检查它的脚部，判断前面一个块的起始位置和状态，这个脚部总是在距当前块开始位置一个字的距离。

        考虑当分配器释放当前块时所有可能存在的情况：

  在情况1中，两个邻接的块都是已分配的，因此不可能进行合并。所以当前块的状态只是简单地从已分配变成空闲。在情况2中，当前块与后面的块合并。用当前块和后面块的大小的和来更新当前块的头部和后面块的脚部。 在情况3中，前面的块和当前块合并。用两个块大小的和来更新前面块的头部和当前块的脚部。在情况4中，要合并所有的三个块形成一个单独的空闲块，用三个块大小的和来更新前面块的头部和后面块的脚部。在每种情况中，合并都是在常数时间内完成的。

         边界标记的概念是简单优雅的，它对许多不同类型的分配器和空闲链表组织都是通用的。然而，也存在一个潜在的缺陷。它要求每个块都保持一个头部和一个脚部，在应用程序操作许多小块时，会产生显著的内存开销。例如，如果一个图形应用通过反复调用 malloc 和 free 来动态地创建和销毁图形节点，并且每个图形节点都只要求两个内存字，那么头部和脚部将占用每个已分配块的一半的空间。

        有一种非常聪明的边界标记的优化方法，能够使得在已分配块中不再需要脚部。回想一下，当试图在内存中合并当前块以及前面的块和后面的块时，只有在前面的块是空闲时，才会需要它的脚部。如果把前面块的已分配/空闲位存放在当前块中多出来的低位中（？），那么已分配块就不需要脚部了，这样我们就可以将这个多出来的空间用作有效载荷了，不过请注意，空闲块仍然需要脚部。 

9.9.12 综合：实现一个简单的分配器        

         构造一个分配器是一件富有挑战性的任务，设计空间巨大，有多种块格式，空闲链表格式，以及放置，分割和合并策略可供选择。另一个挑战就是经常被迫在类型系统的安全和熟悉的限定之外编程，依赖于容易出错的指针强制类型转换和指针运算，这些操作都属于典型的低层系统编程。

        虽然分配器不需要大量的代码，但是还是细微而不可忽视的。熟悉诸如 C++ 或者 Java 之类高级语言的学生通常在它们第一次遇到这种类型的编程时，会遭遇概念上的障碍。将基于隐式空闲链表，使用立即边界标记合并方式，从头到尾地讲述一个简单分配器的实现。最大的块大小为 2^32=4GB。 代码是 64位干净的，即代码能不加修改地运行在 32位（gcc -m32） 或 64位（gcc -m64）的进程中。

        1. 通用分配器设计

        我们的分配器使用如图 9-41 所示的 memlib.c 包所提供的一个内存系统模型。模型的目的在于我们在不干涉已存在的系统层 malloc 包的情况下，运行分配器。

        mem_init 函数 将对于堆来说可用的虚拟内存模型化为一个大的，双字对齐的字节数组。在 mem_heap 和 mem_brk 之间的字节表示已分配的虚拟内存。 mem_brk 之后的字节表示未分配的虚拟内存。 分配器通过调用 mem_sbrk 函数来请求额外的堆内存，这个函数和系统的 sbrk 函数的接口相同，而且语义相同，除了它会拒绝收缩堆的请求。

        分配器包含在一个源文件（mm.c），用户可以编译和链接这个源文件到它们的应用之中。分配器输出三个函数到应用程序：

mm_init 函数初始化分配器，如果成功就返回 0，否则就返回 -1。 mm_malloc 和 mm_free 函数与它们对应的系统函数有相同的接口和语义。分配器使用如图 9-39 所示的块格式。最小块的大小为 16 字节。空闲链表组织成一个隐式空闲链表，如图 9-42所示的恒定形式。

        第一个字是一个双字边界对齐的不适用填充字。填充后面紧跟着一个特殊的序言块，这是一个 8 字节的已分配块，只由一个头部和一个脚部组成。序言块是在初始化时创建的，并且永不释放。在序言块后边紧跟的是零个或者多个由 malloc 或 free 调用创建的普通块。 堆总是以一个特殊的结尾块来结束，这个块是一个大小为 0 的已分配块，只由一个头部组成。序言块和结尾块是一种消除合并时边界条件的技巧。分配器使用一个单独的私有全局变量，他总是指向序言块。（作为一个小优化，我们可以让他指向下一个块，而不是这个序言块）

        2. 操作空闲链表的基本常数和宏

        图 9-43 展示了一些我们在分配器编码中将要使用的基本常数和宏。第 2~4 行定义了一些基本的大小常数：字的大小(WSIZE) 和双字的大小（DSIZE），初始空闲块的大小和扩展堆时的默认大小（CHUNKSIZE）。

        在空闲链表中操作头部和脚部可能是很麻烦的，因为它要求大量使用强制类型转换和组织运算。因此，我们发现定义一小组宏来访问和遍历空闲链表是很有帮助的（第 9~25 行）。PACK 宏（第 9 行）将大小和已分配位结合起来并返回一个值，可以把它存放在头部或者脚部中。 

 GET 宏（第 12 行）读取和返回参数 p 引用的字。这里强制类型转换是至关重要的。参数 p 典型地是一个（void * ）指针，不可以直接进行间接调用，类似的，PUT 宏 （第 13 行）将 val 存放在参数 p 指向的字中。

         GET_SIZE 和 GET_ALLOC 宏（第 16~17 行）从地址 p 处的头部或者脚部分别返回大小和已分配位。剩下的宏是对 块指针（block pointer 用 bp 表示）的操作，块指针指向第一个有效载荷字节。给定一个块指针 bp，HDRP 和 FTRP（第 20~21 行）分别返回指向这个块的头部和脚部指针。NEXT_BLKP 和 PREV_BLKP宏（第 24~25 行）分别返回指向后面的块和前面的块的块指针。

        可以用多种方式来编辑宏，以操作空闲链表。比如，给定一个指向当前块的指针 bp，可以使用下面的代码行来确定内存后面的块的大小。

size_t size = GET_SIZE(HDRP(NEXT_BLKP(bp))); 

 3. 创建初始空闲链表

在调用 mm_malloc 或者 mm_free 之前，应用必须通过调用 mm_init 函数来初始化堆（图9-44）

       mm_init 函数从内存系统得到 4 个字，并将它们初始化，创建一个空的空闲链表（第4~10行）然后它调用 extend_heap 函数（图9-45），这个函数将堆扩展 CHUNKSIZE 字节，并且创建初始的空闲块。此刻，分配器已经初始化了，并且准备好接受来自应用的分配和释放请求。

extend_heap 函数会在两种不同的环境中被调用：1）当堆被初始化时；2）当 mm_malloc 不能找到一个合适的匹配块时。为了保持对齐，extend_heap 将请求大小向上舍入为最接近的 2 字（8字节）的倍数，然后向内存系统请求额外的堆空间（第 7~9 行）

        extend_heap 函数的剩余部分（第 12~17 行）有点微妙。堆开始于一个双字对齐的边界，并且每次对 extend_heap 的调用都返回一个块，该块的大小是双字的整数倍。因此，对 mem_sbrk 的每次调用都返回一个双字对齐的内存片，紧跟在结尾块的头部后面。这个头部变成了新的空闲块的头部（第12行），并且这个片的最后一个字变成了新的结尾块的头部（第 14 行）。最后，在很可能出现的前一个堆以一个空闲块结束的情况中，我们调用 coalesce 函数来合并两个空闲块。并返回指向合并后的块的块指针（第 17 行） 

        4.释放和合并块

        应该通过调用 mm_free 函数（图9-46），来释放一个以前分配的块，这个函数释放所请求的块（bp），然后使用9.9.11节描述的边界标记合并技术将之与邻接的空闲块合并起来。 

        coalesce 函数中的代码是图 9-40 中勾画的四种情况的一种简单直接的实现。这里也有一个微妙的方面。我们选择的空闲链表格式（它的序言块和结尾块总是标记为已分配）允许我们忽略潜在的麻烦边界情况， 也就是，请求块 bp 在堆的起始处或者是在堆的结尾处。如果没有这些特殊块，代码将混乱得多，更加容易出错，并且更慢，因为我们不得不在每次释放请求时，都去检查这些并不常见的边界情况。

        5. 分配块

        一个应用通过调用 mm_malloc 函数（图9-47）来向内存请求大小为 size 字节的块。在检查完请求的真假之后，分配器必须调整请求块的大小，从而为头部和脚部留有空间，并满足双字对齐的要求。第 12~13 行强制了最小块大小是 16 字节：8字节用来满足对齐要求，另外 8个用来放头部和脚部，对于超过 8 字节的请求（第 15 行），一般的规则是加上开销字节，然后向上舍入到最接近的 8 的整数倍。

        一旦分配器调整了请求的大小，他就会搜索空闲链表，寻找一个合适的空闲块（第 18 行）。如果有合适的，那么分配器就放置这个请求块，并可选地分割出多余的部分（第 19 行），然后返回新分配块的地址。

        如果分配器不能够发现一个匹配的块，那么就用一个新的空闲块来扩展堆（第 24~26 行），把请求块放置在这个新的空闲块里，可选地分割这个块（第27行），然后返回一个指针，指向这个新分配的块。