微信官方账号，硬核文章第一时间送达！
前言
由于malloc()源代码很繁琐，会调用OS所提供的API，所以我不对malloc()分析了源代码，但只分析了malloc()动作，这就够了。
一、malloc()分配的内存空间
前面的文章已经提到了，当malloc()在分配空间时，我不会尽可能多地分配空间，而是会添加额外的第一部分和尾部。这里将解释一些简单的部分，我将在本文下面的分析中逐步改进更重要的部分。图片来自侯杰C 内存分配系列教程讲义
这张图去掉了上下两块cookie以下填补区pad。
浅绿色的fill是调用malloc()向系统申请的内存也会在函数返回时返回该区域开头的指针。这里申请0x100 byte的内存.
fill上下两块gap提前填满0xfdfdfdfd，用于分隔客户可以使用的内存区和不可用的内存区。同时，当内存归还时，编辑器也可以通过以下方式使用gap判断当前内存块是否越界。
上gap七个向上连续的内存空间共同构成debug header，自上而下的标签为1-7
为了将多个内存块连接成链表，将两个指针保存在2个空间中。
3空间保存了申请本内存块的文件名
4- 该空间保存了申请本内存块的代码行数
5空间记录了用户在本内存块中实际使用的内存空间的大小
6空间记录了当前内存块的流水号，即链表中的第几个，从1开始
7空间记录了当前内存块分配的形式，将在后面进行分析
二、内存分配
1.内存管理中使用的结构层次
首先，在进入程序之前，系统已经分配了一个管理内存的结构。让我们先看看这个结构
代码很难理解。我在这里分析一下。
先调用系统__cdecl_heap_init()函数分配堆空间，用于管理程序中会产生的动态分配内存的要求。__cdecl_heap_init()在这个函数中，回去创建一个长度为16的类型HEADER链表，链表的每个节点将在未来的程序中管理1MB的内存。
让我们来看看链表节点的结构：
这里需要注意的是两个指针:
指针pHeapData指向这个header所管理的那1MB内存空间的开头。
pRegion它将被指向一个管理结构，它将在下面展开
这张图对应了上边的关系
显示在此图中，pHeapData它指向虚拟地址空间。是的，它仍然是虚拟的，没有为它分配内存。我们可以把他想象成门牌号的集合。门牌号只保存在这里，但房子还没有建成。未来将分配1个空间MB，将被分为32个32KB的内存段。
接下来我们详细看一下pRegion指向的结构，即指向的结构，即tagRegion；
indGroupUse表示当前将提供内存group编号，从0开始
cntRegionSize用64个字节对应后面group链表将展开，当相应的链表有内存时，它将变成1.
bitvGroupHi和bitvGroupLo共同构成了一个的byteMap共64个byte(分为32组)将来用于对应每个组group64条双向链表挂在相应位置有内存时，会变成1.
grpHeadList就是32个group，每个group负责32KB
这里的cntEntries代表当前链表中挂载的内存块被切割的次数
listHead对应64对指针，即形成64条链表，用于挂载不同大小的内存块，间隔为16byte，最后一个链表大于或等于1K的内存块
编号1就是上面说的。grop64条双向链在最后一条双向链表中表现为内存页。
编号2是这个group所对应的那32K内存段分为8份，每份为4份K，将这8个内存页面串成链表，因为每个内存页面大于1K，所以都会挂载在最后一个链表上。
一切准备好后，挂载的对应方式如下图所示：
编号1是当前header所管理的1MB32等分的空间，每个32KB由一个group去负责分配
编号2是一个group所管理的32K将空间分为8个4个KB在最后一个链表上挂载的大小内存页面
编号3是分割的内存页链表，串成双向链表。
编号4是一个group中的64条链表
2.内存页面的划分
让我们来看看每个新内存页面的内容
这是一个4K大小内存页：
中间的空白区代表可共malloc()索取的4080byte的内存空间
在空白的底部和红色的顶部，两个标有4080的空间被用来记录剩余空间的大小cookie
剩下的两个红色部分是指向链表前后内存页面的两个指针
黄色的标有0xfdfdfdfd上面提到了两个分区的具体功能
最上面的保留区是让下面的空白区成为16byte的整数倍
内存页面划分的规则
当申请内存空间时，首先找到符合要求的链表。如果链表中没有内存块，则从最近的链表中划分。
内存页面划分后的情况
最左边原本是一个全新的内存页面(4K = ff0)然后我们从内存页面划分0x130 byte的空间：
编号为1，实际空间分割
编号2是用户可以使用的实际空间，应该是0x100
上下两根cookie至于为什么是0，记录了被划分的实际空间x前一篇文章提到了131，
内存被划分后，malloc()重写，然后将实际空间交付给客户。
当内存被分配时，原始内存页面cookie = ff0-130 = ec此时仍大于1KB，因此，无需转移挂载位置。
3.内存分配动作
我们刚刚分配了0x130空间，我们先来看看这个空间分配后的动作。
编号1：此时由group所以Region 中的 indGroupUse被设置为0
编号2：整个group内存页面被划分一次，所以Group 中的 cntEntries被置为1
编号3：此时group0链表只挂在最后一个链表空间，所以Region 中对应的byte被置为1
此时page1中剩余空间为ec0 byte;
当分配时，group0中没有比当前需求更大的内存块。此时，需要打开另一个内存块group去服务了
编号1:因为现在是group因此，重新分配内存Region 中的 indGroupUse设置为1
编号2：将group最后一后一个链表bitMap对应位置设置为1
编号3：group整个内存页面被划分一次，所以Group 中的 cntEntries被置为1
此时，再分配内存将从group中去分配了
4.内存归还动作
经过多次连续分配，有一个动作可以返回空间
编号1：当前group分配出的内存块-1
编号2:由于归还的内存大小为0x第35号链表应挂载240，因此对应第35号链表bite设1(这里将byteMap中每四个byte写成16进制数)
编号3:目前还是group所以所分配的内存Region 中的 indGroupUse仍为0
编号4:此时返回的内存被重写，两个cookie从0x241变回0x240表示没有使用，两根指针连接到35号链表。
三、归还内存OS
让我们讨论几个问题：
Q1、当多个group被启用时，如何找到归还的内存属于哪个？group？
答案很简单，夹杀法:我们知道每一个group对应内存的起始地址和结束地址，我们只需要判断归还指针中地址的大小是否在两者之间，就可以判断是否属于当前地址group。寻找对应的header方法也是如此。
Q2.如何将内存返还给操作系统？`
这里时malloc和之前过的分配器本质上的区别，我们能将收回的内存还给操作系统，具体步骤如下：
对于回收的连续的内存空间进行合并 这个实现时基于上下两个cookie的实现完成的
这里我们假设还的的1号空间，我们能看到 2、3两个空间的cookie结尾都是0，所以也是空闲的，也就是说这三块连续的空间可以合并。
向下合并：我们首先有一个指向1号空间的指针，他通过cookie可以知道自己有多大，所以下调对应的大小就可以到达2号空间的开头，查看2号空间的cookie可以知道他的大小，也可以知道它是空闲的，所以可以将他们两个合并。
向上合并：我们首先有一个指向1号空间的指针，他向上调整两个int的长度，可以到达3号空间的cookie，通过三号空间的cookie可以知道3号空间的大小，也可以知道3号空间是空闲的，所以就可以将他们两个合并。重复上边两个步骤，我们可以将相连的N块空闲内存全部合并，并计算大小调整连接位置。
判断分配的空间的全回收
这也很简单，我们再每个group都记录了分配出去的次数，每当我们回收的时候，就将这个值-1，所以当它再次为0的时候，就证明这个group的内存全部回收了。
当内存全回收之后的状态
由于有上边的合并机制，所以当一个group的内存全回收之后，他的状态就和最开始时一样，也就是最后一个链表上连接着8个4KB大小的内存块，这时我们就可以将他还给操作系统了。
Q3：当一个group全回收之后，我们需要将他立刻还给系统么？
答案肯定是否定的，因为如果我们全回收一个就还一个，那么当下一次在需要分配时，我们还需要重新分配。所以全回收的group不会立刻被还给系统，而是等待下一个全回收的group出现，就会将前一个group对应的内存free掉。
链接：https://blog.csdn.net/qq_34269632
☞ 专辑 | 趣味设计模式
☞ 专辑 | 音视频开发
☞ 专辑 | C++ 进阶
☞ 专辑 | 超硬核 Qt
☞ 专辑 | 玩转 Linux
☞ 专辑 | GitHub 开源推荐
☞ 专辑 | 程序人生
👇，一起优秀！
回复 进技术交流群，回复 获取海量学习资源。