简介：这份资源围绕C语言动态内存分配展开，面向希望深入理解内存管理原理的开发者与计算机专业学习者，通过动手实现一个简易malloc函数来打通从调用到实现的认知链路。压缩包共3个文件，包含2个C源文件与1个头文件，分别承载函数声明、核心分配逻辑与测试验证代码，整体仅3KB，结构精简，便于直接阅读与编译调试。内容涉及堆区管理、内存块划分、空闲链表维护、首次适配与最佳适配等分配策略，以及释放时的相邻块合并与内存碎片控制，并延伸讨论内存对齐、多线程并发等实际实现中的复杂因素。目前已有1827人学习下载，适合作为操作系统或系统编程课程的配套实践材料，帮助读者在动手编码中理解malloc的运作机制，为排查内存泄漏、优化程序性能打下基础。
1. 自己动手写malloc：为什么堆管理是程序员的“玄学”重灾区
很多人写了多年 C 代码，对malloc的认知仍然停留在“申请内存，返回指针”这一层。直到某天程序在深夜崩溃，gdb 栈里赫然出现malloc_consolidate或者_int_malloc，才开始意识到：这个每天调用无数次的黑匣子，内部藏着一整套精密的内存分配机制。自己动手写一个 malloc，不是为了替代 glibc，而是为了搞清楚三件事：空闲块怎么组织、分配时怎么找、释放时怎么合并。这三个问题一旦想通，内存泄漏、野指针、堆碎片这些“玄学”问题，都会变成可推理的工程问题。本文从零实现一个可运行的简易 malloc，把底层机制一层层拆开。
2. 堆内存的物理模型：从 brk 到空闲链表
2.1 进程地址空间里堆到底长什么样
在 Linux 进程的虚拟地址空间中，堆是一段从低地址向高地址增长的连续区域。内核通过brk系统调用维护一个“程序断点”（program break），这个断点就是堆的边界。当malloc需要更多内存时，它调用brk把断点往上推；当释放的内存足够多时，它可能调用brk把断点往回收。但这里有个关键设计：malloc并不会每次申请都调用brk，因为系统调用开销太大。它一次性向内核要一大块内存（比如 128KB），然后自己管理这块“内存池”，后续的小额分配都从池子里切分。
这就引出了堆管理的核心矛盾：内核给的是连续的大块，而程序请求的是大小不一、生命周期各异的小块。malloc的职责就是在这块连续内存上做“二次分配”，把大块切成小块给调用者，同时记录哪些块被用了、哪些块空闲。这个记录结构，就是空闲链表。
2.2 空闲链表：用内存本身存储管理信息
一个常见的实现思路是隐式空闲链表。每个内存块前面放一个头部（header），记录块的大小和分配状态。头部通常是一个size_t，最低位作为标志位：0 表示空闲，1 表示已分配。由于内存对齐要求，块大小总是 8 的倍数，所以最低三位天然为 0，可以拿来存标志位而不浪费空间。
// 块头部：size 的低 3 位用作标志位 // bit 0: 当前块是否已分配 // bit 1: 前一个块是否已分配（用于合并） typedef size_t block_header; #define BLOCK_SIZE(h) ((h) & ~0x7) #define IS_ALLOCATED(h) ((h) & 0x1) #define IS_PREV_ALLOCATED(h) ((h) & 0x2) #define SET_ALLOCATED(h) ((h) | 0x1) #define SET_FREE(h) ((h) & ~0x1)这个设计的关键在于：管理信息就存在内存块自己的头部里，不需要额外的元数据数组。遍历堆时，从起始地址开始，每次跳过一个块的大小，就能访问到下一个块的头部。这种“自描述”结构让堆可以被线性扫描，但也意味着一旦头部被越界写坏，整个堆就崩了——这就是堆溢出漏洞的根源。
2.3 显式空闲链表与分离空闲链表
隐式链表的问题是分配时最坏要扫描整个堆。改进方案是显式空闲链表：在空闲块内部再维护前驱和后继指针，把所有空闲块串成一个双向链表。这样分配时只需要遍历空闲块，不用管已分配的块。但显式链表也有代价：空闲块必须足够大才能放下两个指针，小空闲块放不下，于是又引入了分离空闲链表——按大小分类，小块的用单链表，大块的用双向链表，类似 glibc 的 bins 机制。
// 显式空闲链表节点：放在空闲块的数据区 typedef struct free_block { struct free_block *prev; struct free_block *next; size_t size; // 也可以复用头部，这里为了清晰单独存 } free_block;我一般会这么理解：隐式链表是“用空间换时间”的反面——省了指针空间，但牺牲了分配速度；显式链表是“用空间换时间”，空闲块里存指针，分配时跳着找。glibc 的 malloc 用的是更复杂的分离链表 + 边界标记 + 延迟合并，但核心思想脱胎于这两种基础结构。
3. 分配与释放的核心算法：首次适配、分割与合并
3.1 首次适配：找到第一个够大的块就切
分配算法的目标是在空闲链表中找到一个大小足够的块。最简单的策略是首次适配（first fit）：从头遍历，遇到第一个大小 >= 请求大小的空闲块就返回。它的优点是实现简单、分配快；缺点是会在堆的前部留下大量小碎片，因为每次都从前面切，后面的空闲块很少被用到。
void *my_malloc(size_t size) { size_t total = ALIGN(size) + sizeof(block_header); block_header *cur = heap_start; while (cur < heap_end) { size_t bsize = BLOCK_SIZE(*cur); if (!IS_ALLOCATED(*cur) && bsize >= total) { // 找到合适的空闲块，考虑是否分割 if (bsize >= total + MIN_BLOCK_SIZE) { split_block(cur, total); } *cur = SET_ALLOCATED(*cur); return (void *)((char *)cur + sizeof(block_header)); } cur = (block_header *)((char *)cur + bsize); } return NULL; // 没有合适的块，需要扩展堆 }这段代码里有两个关键参数：ALIGN(size)把请求大小向上对齐到 8 的倍数，保证返回的指针满足对齐要求；MIN_BLOCK_SIZE是分割后剩余块的最小尺寸，如果剩余部分太小，就不分割，直接把整个块给出去，避免产生无法使用的碎片。首次适配的“首次”二字意味着它不关心后面有没有更合适的块，找到就走，这是速度和碎片率之间的一个折中。
3.2 分割：把大块切成小块的艺术
分割是 malloc 的核心操作之一。当找到的空闲块比请求大很多时，把它切成两块：前一块给用户，后一块继续留在空闲链表里。分割的边界由total决定，即头部 + 对齐后的用户数据。分割后要更新新块的头部，设置大小为剩余部分，并标记为空闲。同时，新块的前一个块（也就是刚分配出去的块）是已分配的，所以新块的头部要设置IS_PREV_ALLOCATED位。
void split_block(block_header *b, size_t total) { size_t old_size = BLOCK_SIZE(*b); size_t new_size = old_size - total; block_header *new_block = (block_header *)((char *)b + total); *new_block = new_size | 0x2; // 新块空闲，且前一块已分配 *b = total | 0x1; // 当前块已分配 // 如果新块后面还有块，需要更新它的 IS_PREV_ALLOCATED 位 block_header *next = (block_header *)((char *)new_block + new_size); if (next < heap_end) { *next &= ~0x2; // 下一个块的前一块变成空闲了 } }这里有个容易翻车的点：更新下一个块的IS_PREV_ALLOCATED位。如果忘了这一步，后续释放时合并逻辑就会出错，导致空闲块被错误地标记为“前一块已分配”，从而无法与前一块合并，堆碎片越积越多。这种 bug 在测试时不一定立刻暴露，但长时间运行后内存占用会持续上涨。
3.3 合并：释放时为什么要看前后邻居
释放操作比分配更微妙。当调用free(ptr)时，不能简单地把块标记为空闲就完事，因为相邻的空闲块如果不合并，就会形成“假碎片”——明明两块连在一起可以满足一个大请求，但因为它们各自独立，分配器找不到足够大的连续空间。所以释放时要检查前一块和后一块是否空闲，如果空闲就合并成一个大块。
void my_free(void *ptr) { if (!ptr) return; block_header *b = (block_header *)((char *)ptr - sizeof(block_header)); *b = SET_FREE(*b); // 向后合并：如果下一个块空闲 block_header *next = (block_header *)((char *)b + BLOCK_SIZE(*b)); if (next < heap_end && !IS_ALLOCATED(*next)) { *b = BLOCK_SIZE(*b) + BLOCK_SIZE(*next); // 更新再下一个块的前块状态 block_header *next2 = (block_header *)((char *)next + BLOCK_SIZE(*next)); if (next2 < heap_end) *next2 |= 0x2; } // 向前合并：如果前一个块空闲 if (!IS_PREV_ALLOCATED(*b)) { // 需要找到前一个块的头部，这要求知道前一块的大小 // 隐式链表做不到，需要边界标记 } }向前合并是隐式链表的痛点：你知道前一块空闲，但不知道它从哪里开始、有多大。解决方案是边界标记（boundary tag）：在每个块的尾部再放一个脚部，复制头部的大小信息。这样从当前块往前读一个size_t，就能拿到前一块的大小，从而定位到它的头部。glibc 的 malloc 正是这么做的。代价是每个块多了一个size_t的开销，但换来了 O(1) 的向前合并能力。
4. 避坑与排查：自己写 malloc 最容易翻车的五个地方
4.1 对齐没做对，程序在 ARM 上直接崩
现象：在 x86 上跑得好好的代码，移植到 ARM 平台后一访问malloc返回的指针就触发SIGBUS。原因：ARM 对未对齐访问的容忍度远低于 x86，某些指令要求指针必须是 8 字节对齐。如果my_malloc返回的地址没有按 8 字节对齐，后续的double或指针访问就会崩。解决：在分配时强制ALIGN(size)到 8 的倍数，并且确保头部大小也是 8 的倍数，这样用户数据区的起始地址天然对齐。
4.2 忘记更新下一个块的前块状态位
现象：程序运行一段时间后，free无法合并相邻空闲块，堆内存持续增长，最终brk扩展失败返回 NULL。原因：在分割或合并时，没有更新后继块的IS_PREV_ALLOCATED位，导致释放时误判前一块的状态。解决：每次改变一个块的分配状态后，都要检查它的后继块是否存在，并同步更新后继块头部的 bit 1。这个操作要封装成函数，避免遗漏。
4.3 双重释放导致空闲链表成环
现象：对同一个指针调用两次free，程序在后续malloc时陷入死循环。原因：第一次free把块标记为空闲并可能合并，第二次free再次操作同一块，如果合并逻辑把已经合并的块又串了一遍，空闲链表就会出现环。解决：在free入口检查块是否已经是空闲状态，如果是就直接返回或报错。更严格的做法是在块头部加一个 magic number，释放后写入特定值，再次释放时校验失败就中止。
4.4 堆扩展时没有处理 brk 失败
现象：程序在内存紧张时malloc返回 NULL，但调用方没有检查，直接解引用导致段错误。原因：my_malloc在空闲链表找不到合适块时，应该调用brk扩展堆，但brk可能失败（比如超过系统限制）。如果代码直接假设brk成功，就会返回一个无效指针。解决：每次brk后检查返回值，失败时返回 NULL，并确保调用方检查返回值。这是 C 语言内存分配的基本契约。
4.5 小块分割产生无法使用的碎片
现象：频繁申请和释放 16 字节的小块后，堆里全是 24 字节的空闲块，但再申请 16 字节时却找不到合适的块。原因：分割时没有设置最小块大小阈值，导致每次分割都产生一个极小的剩余块，这些小块既放不下指针（无法加入显式链表），又因为太小而无法满足任何请求。解决：定义MIN_BLOCK_SIZE（通常为 16 或 24 字节），当剩余部分小于这个值时，不分割，直接把整个块分配出去。虽然会浪费一点空间，但避免了碎片化。
5. 从玩具到生产级：设计取舍与验证方法
自己写的 malloc 和 glibc 的 malloc 之间，差的不只是代码量，而是一整套针对真实负载的优化策略。glibc 用了分离空闲链表（bins）来加速小内存分配，用了mmap处理大块内存（超过 128KB 的请求直接映射，避免污染主堆），用了延迟合并和malloc_consolidate来平衡分配速度和碎片率。这些设计没有一个是“显然正确”的，都是在特定负载下反复权衡的结果。
比如mmap阈值的选择：太小会导致大量系统调用和页表开销，太大则会让大块内存无法及时归还给系统。glibc 默认 128KB，这个数字来自对典型工作负载的统计——大多数程序的分配请求集中在几十字节到几KB之间，超过 128KB 的请求占比很小，用mmap单独处理不会影响主堆的效率。再比如 bins 的数量和分组：glibc 用了 128 个 bins，前 64 个是精确大小的 small bins，后面是按范围分组的 large bins。这个设计让常见的小块分配能在 O(1) 时间内完成，同时用较少的 bins 覆盖大块范围，节省元数据空间。
要验证一个 malloc 实现的正确性和性能，不能只靠“跑起来没崩”。我一般会走三步：第一步，用随机化的分配释放序列做压力测试，记录每次操作的指针和大小，确保没有重叠、没有越界；第二步，用valgrind或 AddressSanitizer 检查内存错误，它们能发现隐藏的越界写和 use-after-free；第三步，对比不同负载下的碎片率——比如交替分配 16 字节和 1024 字节的块，观察堆的总大小和实际使用量的比值。如果碎片率超过 2，说明合并策略或分割阈值需要调整。
从那以后我每次实现内存分配器，都会先写一个最小可用的版本，然后用随机序列跑够一百万次操作，确认没有崩溃和泄漏，再去优化性能。这个习惯帮我省掉了无数个调试堆损坏的深夜。希望帮到你。
本文还有配套的精品资源，点击获取
