堆
堆概述
什么是堆
在程序运行过程中，堆可以提供动态分布的内存，允许程序申请大小未知的内存。堆其实就是程序虚拟地址空间的一块连续的线性区域，它由低地址向高地址方向增长。我们一般称管理堆的那部分程序为堆管理器。
堆管理器处于用户程序与内核中间，主要做以下工作：
1.响应用户的申请内存请求，向操作系统申请内存，然后将其返回给用户程序，同时为了保持内存管理的高效性，内核一般都会预先分配很大的一块连续的内存，然后让堆管理通过某种算法管理这块内存。只有当出现了堆空间不足的情况，堆管理器才会再次与操作系统进行交互。
2.管理用户所释放的内存。一般来说用户释放的内存并不是直接返还给操作系统的，而是由堆管理器进行管理。这些释放的内存可以来响应用户新申请的内存请求。
Linux 中早期的堆分配与回收由 Doug Lea 实现，但它在并行处理多个线程时，会共享进程的堆内存空间。因此，为了安全性，一个线程使用堆时，会进行加锁。然而，与此同时，加锁会导致其它线程无法使用堆，降低了内存分配和回收的高效性。同时，如果在多线程使用时，没能正确控制，也可能影响内存分配和回收的正确性。Wolfram Gloger 在 Doug Lea 的基础上进行改进使其可以支持多线程，这个堆分配器就是 ptmalloc 。在 glibc-2.3.x. 之后，glibc 中集成了 ptmalloc2。
目前 Linux 标准发行版中使用的堆分配器是 glibc 中的堆分配器：ptmalloc2。ptmalloc2 主要是通过 malloc/free 函数来分配和释放内存块。
需要注意的是，在内存分配与使用的过程中，Linux 有这样的一个基本内存管理思想，只有当真正访问一个地址的时候，系统才会建立虚拟页面与物理页面的映射关系。 所以虽然操作系统已经给程序分配了很大的一块内存，但是这块内存其实只是虚拟内存。只有当用户使用到相应的内存时，系统才会真正分配物理页面给用户使用。
堆的基本操作
这里我们主要介绍
- 基本的堆操作，包括堆的分配，回收，堆分配背后的系统覅用
- 介绍堆目前的多线程支持
malloc
在 glibc 的 malloc.c 中，malloc 的说明如下
1 | /* |
可以看出，malloc 函数返回对应大小字节的内存块的指针。此外，该函数还对一些异常情况进行了处理
- 当 n=0 时，返回当前系统允许的堆的最小内存块。
- 当 n 为负数时，由于在大多数系统上，size_t 是无符号数（这一点非常重要），所以程序就会申请很大的内存空间，但通常来说都会失败，因为系统没有那么多的内存可以分配。
free
在 glibc 的 malloc.c 中，free 的说明如下
1 | /* |
可以看出，free 函数会释放由 p 所指向的内存块。这个内存块有可能是通过 malloc 函数得到的，也有可能是通过相关的函数 realloc 得到的。
此外，该函数也同样对异常情况进行了处理
- 当 p 为空指针时，函数不执行任何操作。
- 当 p 已经被释放之后，再次释放会出现乱七八糟的效果，这其实就是
double free。 - 除了被禁用 (mallopt) 的情况下，当释放很大的内存空间时，程序会将这些内存空间还给系统，以便于减小程序所使用的内存空间。
内存分配背后的系统调用
在前面提到的函数中，无论是 malloc 函数还是 free 函数，我们动态申请和释放内存时，都经常会使用，但是它们并不是真正与系统交互的函数。这些函数背后的系统调用主要是 (s)brk 函数以及 mmap, munmap 函数。
如下图所示，我们主要考虑对堆进行申请内存块的操作。
(s)brk
对于堆的操作，操作系统提供了brk函数，glibc库提供了sbrk函数，我们可以通过增加brk的大小来向操作系统申请内存
初始时，堆的起始地址start_brk以及堆的当前末尾brk指向同一地址。根据是否开启ASLR，两者的具体位置会有所不同
- 不开启 ASLR 保护时，start_brk 以及 brk 会指向 data/bss 段的结尾。
- 开启 ASLR 保护时，start_brk 以及 brk 也会指向同一位置，只是这个位置是在 data/bss 段结尾后的随机偏移处。
具体效果如下图：
接下来实际操作来深入理解通过改变brk的大小来分配或释放堆
1 | /* sbrk and brk example */ |
该程序用于演示程序如何手动控制 “程序中断点（Program Break）”（堆内存的边界），理解堆内存动态分配的底层原理。
1 | curr_brk：记录当前程序中断点地址。 |
需要注意的是，在每一次执行完操作后，都执行了 getchar() 函数，这是为了我们方便我们查看程序真正的映射。
gcc编译链接
1 | gcc -o sbrk sbrk.c |
gdb调试sbrk程序观察堆边界变化情况
这里我们可以通过两种方式来查看内存分配情况
1 | vmmap |
在第一次调用brk之前
可以看到并没有出现堆，结合输出可以发现
start_brk = brk = end_data = 0x555555559000
调用完第一个printf之后
出现了堆段，brk = 0x5555557a000
觉得应该是在printf函数内部改变了brk的大小
此时调用sbrk(0)可以发现rax存储了此时的brk
接下来我们尝试将brk变大，来扩展堆内存空间
扩展
brk(curr_brk+4096);扩大一页内存
可以看到此时brk变为了0x55555557b000堆空间得到了拓展
接下来将brk变小释放刚刚扩展的堆空间
释放
brk(tmp_brk);将brk变回初始的0x55555557a000
可以看到此时brk变为了0x55555557a000刚刚扩展的部分得到了释放
mmap
malloc 会使用 mmap 来创建独立的匿名映射段。匿名映射的目的主要是可以申请以 0 填充的内存，并且这块内存仅被调用进程所使用。
同样的我们通过一个程序来深入理解
1 | /* Private anonymous mapping example using mmap syscall */ |
gcc编译链接
1 | gcc -o mmap mmap.c |
调用mmap前的内存段
可以看到调用mmap后内存段的变大了
调用munmap后内存段恢复
多线程支持
在原来的 dlmalloc 实现中，当两个线程同时要申请内存时，只有一个线程可以进入临界区申请内存，而另外一个线程则必须等待直到临界区中不再有线程。这是因为所有的线程共享一个堆。在 glibc 的 ptmalloc 实现中，比较好的一点就是支持了多线程的快速访问。在新的实现中，所有的线程共享多个堆。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
void* threadFunc(void* arg) {
printf("Before malloc in thread 1\n");
getchar();
char* addr = (char*) malloc(1000);
printf("After malloc and before free in thread 1\n");
getchar();
free(addr);
printf("After free in thread 1\n");
getchar();
}
int main() {
pthread_t t1;
void* s;
int ret;
char* addr;
printf("Welcome to per thread arena example::%d\n",getpid());
printf("Before malloc in main thread\n");
getchar();
addr = (char*) malloc(1000);
printf("After malloc and before free in main thread\n");
getchar();
free(addr);
printf("After free in main thread\n");
getchar();
ret = pthread_create(&t1, NULL, threadFunc, NULL);
if(ret)
{
printf("Thread creation error\n");
return -1;
}
ret = pthread_join(t1, &s);
if(ret)
{
printf("Thread join error\n");
return -1;
}
return 0;
}第一次申请之前， 没有任何任何堆段。
2
3
4
5
6
7
8
9
10
11
Welcome to per thread arena example::6501
Before malloc in main thread
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
b7e05000-b7e07000 rw-p 00000000 00:00 0
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$第一次申请后， 从下面的输出可以看出，堆段被建立了，并且它就紧邻着数据段，这说明 malloc 的背后是用 brk 函数来实现的。同时，需要注意的是，我们虽然只是申请了 1000 个字节，但是我们却得到了 0x0806c000-0x0804b000=0x21000 个字节的堆。这说明虽然程序可能只是向操作系统申请很小的内存，但是为了方便，操作系统会把很大的内存分配给程序。这样的话，就避免了多次内核态与用户态的切换，提高了程序的效率。我们称这一块连续的内存区域为 arena。此外，我们称由主线程申请的内存为 main_arena。后续的申请的内存会一直从这个 arena 中获取，直到空间不足。当 arena 空间不足时，它可以通过增加 brk 的方式来增加堆的空间。类似地，arena 也可以通过减小 brk 来缩小自己的空间。
2
3
4
5
6
7
8
9
10
11
12
13
Welcome to per thread arena example::6501
Before malloc in main thread
After malloc and before free in main thread
...
sploitfun@sploitfun-VirtualBox:~/lsploits/hof/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
b7e05000-b7e07000 rw-p 00000000 00:00 0
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$在主线程释放内存后，我们从下面的输出可以看出，其对应的 arena 并没有进行回收，而是交由 glibc 来进行管理。当后面程序再次申请内存时，在 glibc 中管理的内存充足的情况下，glibc 就会根据堆分配的算法来给程序分配相应的内存。
2
3
4
5
6
7
8
9
10
11
12
13
14
Welcome to per thread arena example::6501
Before malloc in main thread
After malloc and before free in main thread
After free in main thread
...
sploitfun@sploitfun-VirtualBox:~/lsploits/hof/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
b7e05000-b7e07000 rw-p 00000000 00:00 0
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$在第一个线程 malloc 之前，我们可以看到并没有出现与线程 1 相关的堆，但是出现了与线程 1 相关的栈。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Welcome to per thread arena example::6501
Before malloc in main thread
After malloc and before free in main thread
After free in main thread
Before malloc in thread 1
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
b7604000-b7605000 ---p 00000000 00:00 0
b7605000-b7e07000 rw-p 00000000 00:00 0 [stack:6594]
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$第一个线程 malloc 后， 我们可以从下面输出看出线程 1 的堆段被建立了。而且它所在的位置为内存映射段区域，同样大小也是 132KB(b7500000-b7521000)。因此这表明该线程申请的堆时，背后对应的函数为 mmap 函数。同时，我们可以看出实际真的分配给程序的内存为 1M(b7500000-b7600000)。而且，只有 132KB 的部分具有可读可写权限，这一块连续的区域成为 thread arena。
注意：
当用户请求的内存大于 128KB 时，并且没有任何 arena 有足够的空间时，那么系统就会执行 mmap 函数来分配相应的内存空间。这与这个请求来自于主线程还是从线程无关。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Welcome to per thread arena example::6501
Before malloc in main thread
After malloc and before free in main thread
After free in main thread
Before malloc in thread 1
After malloc and before free in thread 1
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
b7500000-b7521000 rw-p 00000000 00:00 0
b7521000-b7600000 ---p 00000000 00:00 0
b7604000-b7605000 ---p 00000000 00:00 0
b7605000-b7e07000 rw-p 00000000 00:00 0 [stack:6594]
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$在第一个线程释放内存后， 我们可以从下面的输出看到，这样释放内存同样不会把内存重新给系统。
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Welcome to per thread arena example::6501
Before malloc in main thread
After malloc and before free in main thread
After free in main thread
Before malloc in thread 1
After malloc and before free in thread 1
After free in thread 1
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$ cat /proc/6501/maps
08048000-08049000 r-xp 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
08049000-0804a000 r--p 00000000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804a000-0804b000 rw-p 00001000 08:01 539625 /home/sploitfun/ptmalloc.ppt/mthread/mthread
0804b000-0806c000 rw-p 00000000 00:00 0 [heap]
b7500000-b7521000 rw-p 00000000 00:00 0
b7521000-b7600000 ---p 00000000 00:00 0
b7604000-b7605000 ---p 00000000 00:00 0
b7605000-b7e07000 rw-p 00000000 00:00 0 [stack:6594]
...
sploitfun@sploitfun-VirtualBox:~/ptmalloc.ppt/mthread$
堆相关数据结构
堆的操作就这么复杂，那么在 glibc 内部必然也有精心设计的数据结构来管理它。与堆相应的数据结构主要分为
- 宏观结构，包含堆的宏观信息，可以通过这些数据结构索引堆的基本信息。
- 微观结构，用于具体处理堆的分配与回收中的内存块。
微观结构
这里首先介绍堆的一些主要内部结构，堆的漏洞利用与这些结构密切相关。
malloc_chunk
概述
在程序的执行过程中，我们称由malloc申请的内存为chunk。这块内存在ptmalloc内部用malloc_chunk结构体来表示。当程序申请的chunk被free后，会被加入到相应的空闲管理列表中。
无论一个chunk的大小如何，处于分配状态还是释放状态，它们都使用一个统一的结构。虽然它们使用了同一个数据结构，但是根据是否被释放，它们的表现形式会有所不同。
malloc_chunk 的结构体如下
1 | /* |
一些必要的宏定义
1 | /* INTERNAL_SIZE_T is the word-size used for internal bookkeeping of |
一般来说，
size_t被定义为unsigned long，其在 64 位中是 64 位无符号整数，32 位中是 32 位无符号整数。
接下来逐个解释chunk结构体的各个字段
结构体设计的 “误导性”
注释提到该结构体是一种 “视图（view）”，原因在于：
双重角色：同一个结构体既要表示已分配的内存块，也要表示空闲的内存块。
字段复用
：
- 当 chunk 被分配时，
fd和bk指针不使用（被应用程序数据覆盖）。 - 仅当 chunk 空闲时，
fd和bk才构成双向链表，用于快速查找可用内存。
- 当 chunk 被分配时，
prev_size- 若物理相邻的前一个 chunk 是空闲的，则存储其大小（包括chunk头）。
- 若物理相邻的前一个 chunk 已分配，则该字段被前一个 chunk 的数据覆盖（节省空间）。
**
size**该chunk的大小，大小必须是MALLOC_ALIGNMENT的整数倍。如果申请的内存大小不是MALLOC_ALIGNMENT的整数倍，会被转换为满足大小的最小的MALLOC_ALIGNMENT的倍数，这通过request2size()宏完成。32位系统中，MALLOC_ALIGNMENT可能是 4 或 8 ；64位系统中，MALLOC_ALIGNMENT是 8 。该字段的低三个比特位对chunk的大小没有影响为标志位，他们从高到低分别表示：- NON_MAIN_ARENA，记录当前
chunk是否不属于主线程，1表示不属于，0表示属于。 - IS_MAPPED，记录当前
chunk是否是由mmap分配的。 - PREV_INUSE，记录前一个
chunk块是否被分配。一般来说，堆中第一个被分配的内存块的size字段的p位都会设置为1，以便于防止访问前面的非法内存。当一个chunk的size的p位为0时，我们能通过prev_size字段来获取上一个chunk的大小以及地址。这也方便进行空闲chunk之间的合并
- NON_MAIN_ARENA，记录当前
fd,bkchunk处于分配状态时，从fd字段开始是用户的数据。chunk空闲时，会被添加到对应的空闲管理链表中，其字段的含义如下- fd 指向下一个（非物理相邻）空闲的`chunk` - bk 指向上一个（非物理相邻）空闲的`chunk` - 通过 fd 和 bk 可以将空闲的`chunk`块加入到空闲的`chunk`块链表进行统一管理fd_nextsize，bk_nextsize只有chunk空闲时才使用，不过其用于较大的chunk（large chunk大内存块）- fd_nextsize 指向前一个与当前 `chunk` **大小不同**的第一个空闲块，不包含 bin 的头指针 - bk_nextsize 指向后一个与当前`chunk`**大小不同**的第一个空闲块，不包含 bin 的头指针 - 一般空闲的`large chunk`在fd的遍历顺序中，按照由大到小的顺序排列。这样做可以避免在寻找合适chunk时挨个遍历 ，加速寻找过程
自 glibc 2.26 版本起，在 32 位 glibc 中，
MALLOC_ALIGNMENT宏的定义在编译时优先选择sysdeps/i386/malloc-alignment.h当中的定义，该值定义为一个常量：
因此，对于自 2.26 版本起始的 32 位 glibc，其
MALLOC_ALIGNMENT并非基于SIZE_SZ计算的8，而是和 64 位 glibc 所用值相同的16。
一个已经分配的chunk的样子如下，我们称前两个字段为chunk header，后面的部分称为user data。每次malloc申请得到的内存指针，其实指向user data的起始处。
当一个 chunk 处于使用状态时，它的下一个 chunk 的 prev_size 域无效，所以下一个 chunk 的该部分也可以被当前 chunk 使用。这就是 chunk 中的空间复用。
被释放的 chunk 被记录在链表中（可能是循环双向链表，也可能是单向链表）。具体结构如下
可以发现，如果一个 chunk 处于 free 状态，那么会有两个位置记录其相应的大小
- 本身的 size 字段会记录，
- 它后面的
chunk会记录。
一般情况下，物理相邻的两个空闲 chunk 会被合并为一个 chunk 。堆管理器会通过 prev_size 字段以及 size 字段合并两个物理相邻的空闲 chunk 块。
chunk 相关宏
介绍一些宏定义里用到的内存计算指令
按位取反（~）
~7 = 0xFFFFFFF8
47 & ~7 = 47 & 0xFFFFFFF8 = 40（将数值 47 向下舍入到 8 字节对齐 的边界，即找到 ≤47 且为 8 的倍数 的最大数值）
&按位与（Bitwise AND）运算，用于将数值 47 对齐到 8 字节边界
这里主要介绍chunk的大小、对齐检查以及一些转换的宏
chunk 与 mem 指针头部的转换
mem 指向用户得到的内存的起始位置
1 | /*从 malloc 头部（chunk）到用户指针（mem）的转换，以及反向转换。*/ |
chunk2mem(p)：将chunk指针（指向malloc_chunk结构体）转换为用户实际可用的内存指针（跳过prev_size和size字段，指向用户数据区起始位置）。mem2chunk(mem)：将用户内存指针反向转换为chunk指针（回溯两个SIZE_SZ大小的偏移，指向malloc_chunk结构体起始位置）。- 关键：
SIZE_SZ为INTERNAL_SIZE_T的字节数（32 位系统为 4，64 位为 8），因此偏移量为2 * SIZE_SZ（即prev_size和size字段总长度）。
最小的chunk大小
1 | /* 最小可能的 chunk 大小。 */ |
- 使用
offsetof计算malloc_chunk结构体中fd_nextsize字段的偏移量，即chunk至少需包含prev_size、size、fd、bk字段（fd_nextsize为 large bin 专用，最小块不包含）。 - 实际含义：最小
chunk大小为2 * SIZE_SZ（prev_size + size） + 2 * sizeof(void*)（fd + bk），确保双向链表基本结构。
最小申请的堆内存大小
用户最小申请的内存大小必须是 2*SIZE_SE 的最下整数倍
注：就目前而看 MIN_CHUNK_SIZE 和 MINSIZE 大小是一致的
1 | /* malloc 能申请的最小大小为对齐后的最小块 */ |
MALLOC_ALIGN_MASK为对齐掩码（值为MALLOC_ALIGNMENT - 1，如 64 位系统为0xf）。- 计算逻辑：将
MIN_CHUNK_SIZE向上对齐到MALLOC_ALIGNMENT的倍数，确保内存地址对齐（如 64 位系统对齐 16 字节）。 - 示例：若
MIN_CHUNK_SIZE为0x20（32 字节），MALLOC_ALIGNMENT为 16，则MINSIZE为0x20（已对齐）。
检查分配给用户的内存是否对齐
2 * SIZE_SZ 大小对齐
1 | /* 检查 m 是否符合对齐要求 */ |
请求字节数判断
1 | /* |
将用户请求内存大小转为实际分配内存大小
1 | /* 将用户请求的字节数转换为可用的块大小（内部版本） */ |
- 步骤 1：判断请求大小
req加上SIZE_SZ（预留size字段空间）和对齐掩码后的总大小是否小于MINSIZE。 - 步骤 2：若小于，直接返回
MINSIZE（强制分配最小块）；否则，通过掩码对齐到MALLOC_ALIGNMENT的倍数。 - 核心逻辑：确保用户数据区大小为
req，但整个chunk需包含头部（prev_size和size）并满足对齐要求。
当一个 chunk 处于已分配状态时，它的物理相邻的下一个 chunk 的 prev_size 字段必然是无效的，故而这个字段就可以被当前这个 chunk 使用。这就是 ptmalloc 中 chunk 间的复用。具体流程如下
- 首先，利用 REQUEST_OUT_OF_RANGE 判断是否可以分配用户请求的字节大小的 chunk。
- 其次，需要注意的是用户请求的字节是用来存储数据的，即
chunk header后面的部分。与此同时，由于 chunk 间复用，所以可以使用下一个chunk的 prev_size 字段。因此，这里只需要再添加 SIZE_SZ 大小即可以完全存储内容。 - 由于系统中所允许的申请的
chunk最小是 MINSIZE，所以与其进行比较。如果不满足最低要求，那么就需要直接分配 MINSIZE 字节。 - 如果大于的话，因为系统中申请的
chunk需要 2 * SIZE_SZ 对齐，所以这里需要加上 MALLOC_ALIGN_MASK 以便于对齐。
标记位相关
1 | /* 当相邻的前一个内存块（chunk）被使用时，size字段会与PREV_INUSE进行按位或操作 */ |
**获取 chunk size **
1 | /* 获取内存块大小（忽略使用标志位） */ |
获取下一个物理相邻的 chunk
1 | /* 指向下一个物理相邻的 chunk 指针。 */ |
通过 chunksize(p) 获取当前块总大小（含头部），计算下一块起始地址（当前地址 + 块大小）
获取前一个 chunk 的信息
1 | /* 获取 p 下方块的大小，仅当前一块空闲时有效。 */ |
当前 chunk 使用状态相关操作
1 | /* 提取 p 的使用状态位 */ |
设置 chunk 的 size 字段
1 | /* 设置头部的大小，不干扰其使用标志位 */ |
获取指定偏移的 chunk
1 | /* 将 ptr + offset 位置的空间视为一个 chunk */ |
指定偏移处 chunk 使用状态相关操作
1 | /* 检查 p + s 位置的内存块的使用状态位 */ |
bin
概述
bin本质是双向链表，用于链接空闲的chunk。每 bin的 header 包含两个指针：fd（forward）：指向下一个空闲chunk。bk（backward）：指向前一个空闲chunk。
- 由于
malloc_chunk结构体中天然包含fd和bk字段（仅在空闲时使用），bin的 header 可以直接作为链表的 “虚拟头结点”，方便插入、删除操作。
我们曾经说过，用户释放掉的 chunk 不会马上归还给系统，ptmalloc 会统一管理 heap 和 mmap 映射区域中的空闲的 chunk。当用户再一次请求分配内存时，ptmalloc 分配器会试图在空闲的 chunk 中挑选一块合适的给用户。这样可以避免频繁的系统调用，降低内存分配的开销。
在具体的实现中，ptmalloc采用分箱式方法(bin)对空闲的chunk进行管理。首先，它会根据空闲的chunk的大小以及使用状态将chunk初步分为4类：fast bins，small bins，large bins，unsorted bin。在每类bin的内部仍然会有多个互不相关的链表来保存不同大小的chunk。
对于small bins，large bins，unsorted bin来说，ptmalloc将它们维护在同一个数组中。这些 bin 对应的数据结构在 malloc_state 中，如下
1 |
|
bins 主要用于索引不同 bin 的 fd 和 bk。
为了简化在双链接列表中的使用，每个 bin 的header都设置为 malloc_chunk 类型。这样可以避免 header 类型及其特殊处理。但是，为了节省空间和提高局部性，只分配 bin 的fd/bk 指针，然后使用repositioning tricks 将这些指针视为一个malloc_chunk*的字段。
以32位系统为例，bins前4项的含义如下
| 含义 | bin1 的 fd/bin2 的 prev_size | bin1 的 bk/bin2 的 size | bin2 的 fd/bin3 的 prev_size | bin2 的 bk/bin3 的 size |
|---|---|---|---|---|
| bin 下标 | 0 | 1 | 2 | 3 |
可以看到，bin2 的 prev_size、size 和 bin1 的 fd、bks是重合的。由于我们只会使用 fd 和 bk 来索引链表，所以该重合部分的数据其实记录的是 bin1 的 fd 、bk。也就是说，虽然后一个 bin 和前一个 bin 共用部分数据，但是其实记录的仍然是前一个 bin 的链表数据。通过这样的复用，可以节省空间。
数组中的 bin 依次如下
1.第一个为 unsorted bin（未排序的箱子），这里面的chunk没有进行排序，存储的chunk比较杂。
2.索引从2到63的 bin 称为 small bin，同一个 small bin 链表中的chunk的大小相同。两个相邻索引的 small bin 链表中的chunk大小相差的字节数为2个机器字长，即32位相差8字节，64位相差16字节。
3.small bins 后面的 bin 被称作 large bins。large bins中的每一个 bin 都包含一定范围内的 chunk，其中的 chunk 按 fd 指针的顺序从大到小排列。相同大小的chunk同样按照最近使用顺序排列。
此外，上述这些 bin 的排布都会遵循一个原则: 任意两个物理相邻的空闲 chunk 不能在一起
示例：若内存中有块 A（已用）、块 B（空闲）、块 C（空闲），则块 B 和 C 因物理相邻违反规则，需通过分配其他数据或合并为一个大块来调整。
需要注意的是，并不是所有的chunk被释放后就立即被放到 bin 中。ptmalloc 为了提高分配的速度，会把一些小的chunk先放到 fast bins 的容器内。而且，fastbin容器中的chunk的使用标记总是被置位的，所以不满足上面的原则。
bin 通用的宏如下
1 | typedef struct malloc_chunk *mbinptr; |
Fast Bin
大多数程序经常会申请以及释放一些比较小的内存块。如果将一些较小的chunk释放之后发现存在与之相邻的空闲的chunk并将它们进行合并，那么当下一次再次申请相应大小的chunk时，就需要对chunk进行分割，这样就大大降低了堆的利用效率。因为我们把大部分时间花在了合并、分割以及中间检查的过程中。因此，prmalloc中专门设计了 fast bin，对应的变量就是malloc state中的 fastbinsY
1 | /*快速链表 |
为了更加高效地利用 fast bin，glibc采用单向链表对其中的每个bin进行组织，并且每个bin采取LIFO策略(后进先出)，最近释放的chunk会更早的被分配，所以会更加适合于局部性。也就是说，当用户需要的chunk的大小小于 fastbin 的最大大小时，ptmalloc会首先判断 fastbin 中相应的 bin 中是否有对应大小的空闲块，如果有的话，就会直接从这个 bin 中获取 chunk。如果没有的话，ptmalloc才会做接下来的一系列操作。
默认情况下(32位系统为例)，fast bin中默认支持最大的chunk的数据空间大小为64字节。但是其可以支持的chunk的数据空间最大为0x80字节。除此之外，fast bin 最多可以支持的 bin 的个数为10个，从数据空间为8字节开始一直到80字节(这里说的大小是数据空间的大小，也就是除去prev_size和size字段部分的大小)
定义如下
1 |
|
ptmalloc 默认情况下会调用 set_max_fast(s) 将全局变量 global_max_fast 设置为 DEFAULT_MXFAST，也就是设置 fast bins 中 chunk 的最大值。当 MAX_FAST_SIZE 被设置为 0 时，系统就不会支持 fast bins 。
fastbin 的索引
1 |
|
需要特别注意的是，fastbin 范围的 chunk 的 inuse 始终被置为 1。因此它们不会和其它被释放的 chunk 合并。
但是当释放的 chunk 与该 chunk 相邻的空闲 chunk 合并后的大小大于 FASTBIN_CONSOLIDATION_THRESHOLD 时，内存碎片可能比较多了，我们就需要把 fast bins 中的 chunk 都进行合并，以减少内存碎片对系统的影响。
1 | /* |
malloc_consolidate 函数可以将 fastbin 中所有能和其它 chunk 合并的 chunk 合并在一起。具体地参见后续的详细函数的分析。
1 | /* |
small bin
small bins中每个chunk的大小与其所在的 bin 的index的关系为: chunk_size = 2 * SIZE_SZ*index，具体如下
| 下标 | SIZE_SZ=4（32 位） | SIZE_SZ=8（64 位） |
|---|---|---|
| 2 | 16 | 32 |
| 3 | 24 | 48 |
| 4 | 32 | 64 |
| 5 | 40 | 80 |
| x | 2*4*x | 2*8*x |
| 63 | 504 | 1008 |
small bins 中一共有62个循环双向链表，每个链表中存储的chunk大小都一致。比如对于32位系统来说，下标2对应的双向链表中存储的chunk大小均为16字节。每个链表都有链表头节点，这样可以方便对于链表内部结点的管理。此外，**small bins中每个 bin 对应的链表采用 FIFO 的规则(先进先出)**，所以同一个链表中先被释放的chunk会先被分配出去
small bin 相关的宏如下
1 |
|
或许，大家会很疑惑，那 fast bin 与 small bin 中 chunk 的大小会有很大一部分重合啊，那 small bin 中对应大小的 bin 是不是就没有什么作用啊？ 其实不然，fast bin 中的 chunk 是有可能被放到 small bin 中去的，我们在后面分析具体的源代码时会有深刻的体会。
Large Bin
large bins 中一共包括 63 个 bin，每个 bin 中的 chunk 的大小不一致，而是处于一定区间范围内。此外，这 63 个 bin 被分成了 6 组，每组 bin 中的 chunk 大小之间的公差一致，具体如下：
| 组 | 数量 | 公差 |
|---|---|---|
| 1 | 32 | 64B |
| 2 | 16 | 512B |
| 3 | 8 | 4096B |
| 4 | 4 | 32768B |
| 5 | 2 | 262144B |
| 6 | 1 | 不限制 |
这里我们以32位平台的large bin 为例，第一个large bin 的其实chunk大小为512字节，位于第一组，所以该bin可以存储的chunk的大小范围为[512,512+64）。
关于large bin 的宏如下，这里我们以32位平台下，第一个large bin 的起始chunk大小为例，为512字节
1 |
|
Unsorted Bin
unsorted bin 可以视为空闲 chunk 回归其所属 bin 之前的缓冲区。
其在 glibc 中具体的说明如下
1 | /* |
在 ptmalloc 内存管理机制中，
NON_MAIN_ARENAflag 是malloc_chunk结构体中size字段的一个标志位，用于表示当前chunk是否属于主线程的分配区（main arena）
从下面的宏我们可以看出
1 | /* 无法索引的 1 号 bin 用于存放未排序的块。 */ |
unsorted bin 处于我们之前所说的 bin 数组下标 1 处。故而 unsorted bin 只有一个链表。unsorted bin 中的空闲 chunk 处于乱序状态，主要有两个来源
- 当一个较大的
chunk被分割成两半后，如果剩下的部分大于 MINSIZE，就会被放到 unsorted bin 中。 - 释放一个不属于 fast bin 的 chunk，并且该
chunk不和 topchunk紧邻时，该chunk会被首先放到 unsorted bin 中。关于 topchunk的解释，请参考下面的介绍。
此外，Unsorted Bin 在使用的过程中，采用的遍历顺序是 FIFO 。
common macro
这里介绍一些通用的宏。
根据 chunk 的大小统一地获得 chunk 所在的索引
1 |
Top Chunk
glibc 中对于Top chunk 的描述如下
1 | /* |
程序第一次进行malloc的时候，heap会被分为两块，一块给用户，剩下的那块就是 top chunk 。其实所谓的 top chunk 就是处于当前堆的物理地址最高的chunk。这个chunk不属于任何一个bin，它的作用在于当所有的bin都无法满足用户请求的大小时，如果其大小不小于指定的大小，就进行分配，并将剩下部分作为新的 top chunk 。否则就对heap进行扩展后再进行分配。在main arena中通过sbrk扩展heap，而在thead arena中通过mmap分配新的heap。
需要注意的是，top chunk 的prev_inuse 比特位始终为1，否则其前面的 chunk 就会被合并到 top chunk 中。
初始情况下，我们可以将 unsorted chunk 作为 top chunk。
last remainder
在用户使用 malloc 请求分配内存时，ptmalloc2 找到的 chunk 可能并不和申请的内存大小一致，这时候就将分割之后的剩余部分称之为 last remainder chunk，unsorted bin 也会存这一块。top chunk 分割剩下的部分不会作为 last remainder chunk。
宏观结构
arena
arena（分配区） 是用于管理内存分配的重要结构，主要与多线程环境下的内存管理相关。
在我们之前介绍的例子中，无论是主线程还是新创建的线程，在第一次申请内存时，都会有独立的 arena。那么会不会每个线程都有独立的 arena 呢？下面我们就具体介绍。
arena 数量
对于不同系统，arena 数量的约束如下
1 | For 32 bit systems: |
显然，不是每一个线程都会有对应的 arena。至于为什么 64 位系统，要那么设置，我也没有想明白。此外，因为每个系统的核数是有限的，当线程数大于核数的二倍（超线程技术）时，就必然有线程处于等待状态，所以没有必要为每个线程分配一个 arena。
arena 分配规则
- 线程首次分配内存时，优先使用主线程 Arena；若竞争激烈，会创建新的 Thread Arena。
- 小内存分配（如小于
mmap_threshold）使用堆（sbrk），大内存分配直接通过mmap创建独立堆块。
区别
与 thread 不同的是，main_arena 并不在申请的 heap 中，而是一个全局变量，在 libc.so 的数据段。
heap_info
程序刚开始执行时，每个线程是没有 heap 区域的。当其申请内存时，就需要一个结构来记录对应的信息，而 heap_info 的作用就是这个。而且当该 heap 的资源被使用完后，就必须得再次申请内存了。此外，一般申请的 heap 是不连续的，因此需要记录不同 heap 之间的链接结构。
该数据结构是专门为从 Memory Mapping Segment(内存映射段) 处申请的内存准备的，即为非主线程准备的。
主线程可以通过 sbrk() 函数扩展 program break location(进程堆的当前边界) 获得（直到触及 Memory Mapping Segment），只有一个 heap，没有 heap_info 数据结构。
heap_info 的主要结构如下
1 | #define HEAP_MIN_SIZE (32 * 1024) |
该结构主要是描述堆的基本信息，包括
- 堆对应的 arena 的地址
- 由于一个线程申请一个堆之后，可能会使用完，之后就必须得再次申请。因此，一个线程可能会有多个堆。prev 即记录了上一个 heap_info 的地址。这里可以看到每个堆的 heap_info 是通过单向链表进行链接的。
- size 表示当前堆的大小
- 最后一部分确保对齐
pad 里负数的缘由是什么呢?
pad是为了确保分配的空间是按照MALLOC_ALIGN_MASK+1(记为MALLOC_ALIGN_MASK_1) 对齐的。在pad之前该结构体一共有 6 个SIZE_SZ大小的成员, 为了确保MALLOC_ALIGN_MASK_1字节对齐, 可能需要进行pad，不妨假设该结构体的最终大小为MALLOC_ALIGN_MASK_1*x，其中x为自然数，那么需要pad的空间为MALLOC_ALIGN_MASK_1 * x - 6 * SIZE_SZ = (MALLOC_ALIGN_MASK_1 * x - 6 * SIZE_SZ) % MALLOC_ALIGN_MASK_1 = 0 - 6 * SIZE_SZ % MALLOC_ALIGN_MASK_1=-6 * SIZE_SZ % MALLOC_ALIGN_MASK_1 = -6 * SIZE_SZ & MALLOC_ALIGN_MASK。
看起来该结构应该是相当重要的，但是如果如果我们仔细看完整个 malloc 的实现的话，就会发现它出现的频率并不高。
malloc_state
该结构用于管理堆，记录每个 arena 当前申请的内存的具体状态，比如说是否有空闲 chunk，有什么大小的空闲 chunk 等等。无论是 thread arena 还是 main arena，它们都只有一个 malloc state 结构。由于 thread 的 arena 可能有多个，malloc state 结构会在最新申请的 arena 中。
注意，main arena 的 malloc_state 并不是 heap segment（堆段)的一部分，而是一个全局变量，存储在 libc.so 的数据段。
其结构如下
1 | struct malloc_state { |
- __libc_lock_define(, mutex);
- 该变量用于控制程序串行访问同一个分配区，当一个线程获取了分配区之后，其它线程要想访问该分配区，就必须等待该线程分配完成后才能够使用。
- flags
- flags 记录了分配区的一些标志，比如 bit0 记录了分配区是否有
fast bin chunk，bit1 标识分配区是否能返回连续的虚拟地址空间。具体如下
- flags 记录了分配区的一些标志，比如 bit0 记录了分配区是否有
1 | /* |
- fastbinsY[NFASTBINS]
- 存放每个 fast
chunk链表头部的指针
- 存放每个 fast
- top
- 指向分配区的 top chunk
- last_reminder
- 最新的
chunk分割之后剩下的那部分
- 最新的
- bins
- 用于存储 unstored bin，small bins 和 large bins 的
chunk链表。
- 用于存储 unstored bin，small bins 和 large bins 的
- binmap
- ptmalloc 用一个 bit 来标识某一个 bin 中是否包含空闲
chunk。
- ptmalloc 用一个 bit 来标识某一个 bin 中是否包含空闲
malloc_par
在 glibc 的 ptmalloc 内存分配实现里，malloc_par 是用于管理堆内存分配器参数的结构体，作用是为 ptmalloc 提供全局的、影响内存分配行为的配置与状态记录 ，以下从关键层面详细解释：
1. 角色与定位
malloc_par 是 参数管理中枢，为 ptmalloc 分配器的运行提供全局参数支撑。不同于 malloc_state（管理单个分配区 arena 的状态 ），malloc_par 是静态全局唯一的，影响整个进程中 ptmalloc 的行为逻辑，决定内存如何向系统申请、释放，以及空闲内存如何组织等核心流程。
2. 关联核心机制
它与 ptmalloc 关键组件深度绑定：
- 与
arena（分配区 ）协同：多个malloc_state（每个arena对应一个 ）共享malloc_par的全局参数，比如内存申请阈值、对齐规则等，确保不同线程 / 分配区遵循统一策略。 - 控制内存分配策略：像
mmap分配阈值（超过多大内存直接用mmap而非堆 ）、trim阈值（堆内存何时归还给系统 ）等，都由malloc_par相关参数决定，直接影响内存分配效率和系统资源占用。
3. 典型参数与功能（以常见逻辑为例 ）
虽具体定义依赖 glibc 版本，但通常涵盖：
内存阈值类
：
mmap_threshold：超过该大小的内存申请，ptmalloc可能直接调用mmap分配独立内存块（而非从堆arena分配 ），避免堆碎片化。trim_threshold：当堆中空闲内存超过此值，ptmalloc会尝试调用munmap或调整堆边界，将内存归还给系统，优化内存占用。
对齐与大小规则：
记录MALLOC_ALIGNMENT（内存块对齐字节数，保证内存访问效率 ）、MIN_CHUNK_SIZE（最小可分配内存块大小 ）等基础规则，约束chunk（内存块 ）的创建与管理。调试与统计辅助：
可能包含内存分配统计标记、调试模式开关（如开启额外检查 ），辅助排查内存泄漏、溢出等问题（虽ptmalloc自身调试工具弱，但这些参数可配合外部工具分析 ）。
4. 实际意义
- 统一配置：让
ptmalloc全局行为可控，开发者（或系统 ）可通过调整malloc_par参数（部分支持运行时调整 ），适配不同场景（如高并发小内存分配、大内存低频申请 ）。 - 性能优化：合理设置
mmap_threshold、trim_threshold等，能减少堆碎片、降低系统调用开销，提升程序内存使用效率。 - 问题排查：结合其参数与状态，可辅助分析内存分配异常（如频繁
mmap导致的内存离散、堆内存过度占用未释放等 ）。
简单说，malloc_par 是 ptmalloc 的 “全局配置中心”，默默调控着内存分配的规则、策略与资源交互，是理解 glibc 内存管理底层逻辑的关键结构体之一 。若想深入，建议结合具体 glibc 版本（如 2.23 等 ）的源码，追踪 malloc_par 定义及与 arena、chunk 交互的流程 。
深入理解Ptmalloc2
仔细想一下，任何堆的实现都需要从以下两个角度考虑相应的问题
- 宏观角度
- 创建堆
- 堆初始化
- 删除堆
- 微观角度
- 申请内存块
- 释放内存块
当然，这些都是比较高层面的想法，不同的堆的底层实现会有所不同。
基础操作
unlink
unlink 用来将一个双向链表（只存储空闲的 chunk）中的一个元素取出来，可能在以下地方使用
malloc
- 从恰好大小合适的 large bin 中获取 chunk。
- 这里需要注意的是 fastbin 与 small bin 就没有使用 unlink，这就是为什么漏洞会经常出现在它们这里的原因。
- 依次遍历处理 unsorted bin 时也没有使用 unlink 。
- 从比请求的 chunk 所在的 bin 大的 bin 中取 chunk。
- 从恰好大小合适的 large bin 中获取 chunk。
free
- 后向合并，合并物理相邻低地址空闲 chunk。
- 前向合并，合并物理相邻高地址空闲 chunk（除了 top chunk）。
malloc_consolidate
- 后向合并，合并物理相邻低地址空闲 chunk。
- 前向合并，合并物理相邻高地址空闲 chunk（除了 top chunk）。
realloc
- 前向扩展，合并物理相邻高地址空闲 chunk（除了 top chunk）。
由于 unlink 使用非常频繁，所以 unlink 被实现为了一个宏，如下
所用到的相关宏或函数 解释
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/*
EXPRESSION：条件表达式（如 cond）。
EXPECTED_VALUE：预期的表达式结果（通常为 0 或 1，对应 “假” 或 “真”）。
*/
malloc_printerr(stderr);
/*
malloc_printerr 是 C 标准库中 malloc 相关的错误处理函数，主要用于处理内存分配失败时的错误信息输出。
*/
/*
SMALLBIN_MAX_SIZE 是小 bins 的最大允许大小（如 64 或 128，取决于 glibc 版本）。
若堆块大小 小于 该阈值，则返回 true，属于小 bins；否则属于大 bins。lloc_printerr 是 C 标准库中 malloc 相关的错误处理函数，主要用于处理内存分配失败时的错误信息输出。
*/
1 | /* Take a chunk off a bin list */ |
这里我们以 small bin 的 unlink 为例子介绍一下。对于 large bin 的 unlink，与其类似，只是多了一个 nextsize 的处理。
可以看出， P 最后的 fd 和 bk 指针并没有发生变化，但是当我们去遍历整个双向链表时，已经遍历不到对应的链表了。这一点没有变化还是很有用处的，因为我们有时候可以使用这个方法来泄漏地址
- libc 地址
- P 位于双向链表头部，bk 泄漏
- P 位于双向链表尾部，fd 泄漏
- 双向链表只包含一个空闲 chunk 时，P 位于双向链表中，fd 和 bk 均可以泄漏
- 泄漏堆地址，双向链表包含多个空闲 chunk
- P 位于双向链表头部，fd 泄漏
- P 位于双向链表中，fd 和 bk 均可以泄漏
- P 位于双向链表尾部，bk 泄漏
注意
- 这里的头部指的是 bin 的 fd 指向的 chunk，即双向链表中最新加入的 chunk。
- 这里的尾部指的是 bin 的 bk 指向的 chunk，即双向链表中最先加入的 chunk。
同时，无论是对于 fd，bk 还是 fd_nextsize ，bk_nextsize，程序都会检测 fd 和 bk 是否满足对应的要求。
1 | // fd bk |
看起来似乎很正常。我们以 fd 和 bk 为例，P 的 forward chunk 的 bk 很自然是 P ，同样 P 的 backward chunk 的 fd 也很自然是 P 。如果没有做相应的检查的话，我们可以修改 P 的 fd 与 bk，从而可以很容易地达到任意地址写的效果。关于更加详细的例子，可以参见利用部分的 unlink 。
注意：堆的第一个 chunk 所记录的 prev_inuse 位默认为 1。
malloc_printerr
在 glibc malloc 时检测到错误的时候，会调用 malloc_printerr 函数。
1 | static void malloc_printerr(const char *str) { |
主要会调用 __libc_message 来执行abort 函数，如下
1 | if ((action & do_abort)) { |
在abort 函数里，在 glibc 还是 2.23 版本时，会 fflush stream。
1 | /* 刷新所有流。我们现在不能关闭它们，因为用户可能已经为 SIGABRT 注册了一个处理程序。 */ |
堆初始化
堆初始化是在用户第一次申请内存时执行 malloc_consolidate 再执行 malloc_init_state 实现的。这里不做过多讲解。可以参见 malloc_state 相关函数。
申请内存块
__libc_malloc
一般我们会使用 malloc 函数来申请内存块，可是当仔细看 glibc 的源码实现时，其实并没有 malloc 函数。其实该函数真正调用的是 __libc_malloc 函数。为什么不直接写个 malloc 函数呢，因为有时候我们可能需要不同的名称。此外，__libc_malloc 函数只是用来简单封装 _int_malloc 函数。_int_malloc 才是申请内存块的核心。下面我们来仔细分析一下具体的实现。
该函数会首先检查是否有内存分配函数的钩子函数（__malloc_hook），这个主要用于用户自定义的堆分配函数，方便用户快速修改堆分配函数并进行测试。这里需要注意的是，用户申请的字节一旦进入申请内存函数中就变成了无符号整数。
原子操作：
atomic_forced_read是一个原子读取宏，确保读取__malloc_hook的值时不会被其他线程打断，保证数据一致性。
size：申请的内存大小。caller：调用malloc的函数地址（可选，取决于实现）。- 返回值：需返回分配好的内存地址，或
NULL表示分配失败。ar_ptr通常是指向mstate（在 glibc 源码中定义为struct malloc_state） 类型的指针用于表示 内存分配器的 arena（内存区域）
1 | // _int_malloc 的封装器 |
接着会寻找一个 arena 来试图分配内存。
1 | arena_get(ar_ptr, bytes); |
然后调用 _int_malloc 函数去申请对应的内存。
1 | victim = _int_malloc(ar_ptr, bytes); |
如果分配失败的话，ptmalloc 会尝试再去寻找一个可用的 arena，并分配内存。
1 | /*若分配失败且之前成功获取过 Arena（即ar_ptr != NULL），则通过arena_get_retry获取另一个 Arena，并再次调用_int_malloc重试分配。 |
如果申请到了 arena，那么在退出之前还得解锁。
1 | if (ar_ptr != NULL) __libc_lock_unlock(ar_ptr->mutex); |
判断目前的状态是否满足以下条件
- 要么没有申请到内存
- 要么是 mmap 的内存
- 要么申请到的内存必须在其所分配的 arena 中
1 | assert(!victim || chunk_is_mmapped(mem2chunk(victim)) || |
最后返回内存。
1 | return victim; |
_int_malloc
_int_malloc 是内存分配的核心函数，其核心思路有如下
- 它根据用户申请的内存块大小以及相应大小 chunk 通常使用的频度（fastbin chunk, small chunk, large chunk），依次实现了不同的分配方法。
- 它由小到大依次检查不同的 bin 中是否有相应的空闲块可以满足用户请求的内存。
- 当所有的空闲 chunk 都无法满足时，它会考虑 top chunk。
- 当 top chunk 也无法满足时，堆分配器才会进行内存块申请。
在进入该函数后，函数立马定义了一系列自己需要的变量，并将用户申请的内存大小转换为内部的 chunk 大小。
1 |
|
arena
1 | /* 没有可用的内存池。回退到 sysmalloc 从 mmap 获取一个内存块。 */ |
在 glibc 的头文件（如
sys/cdefs.h或bits/types.h）中，__glibc_unlikely通常基于编译器的 分支预测指令 实现，常见定义如下：
2
3
4
5
__builtin_expect是 GCC 内置函数，用于告诉编译器某个表达式的结果大概率是0（false）或1（true）。
- 语法：
__builtin_expect(condition, expected_value)- 作用：让编译器优化代码，优先生成
expected_value路径的指令，提升执行效率。- 示例解析：
当使用__glibc_unlikely(av == NULL)时，等价于__builtin_expect((av == NULL), 0)，即告诉编译器：av == NULL这个条件大概率不成立（expected_value=0）。
fast bin
如果申请的 chunk 的大小位于 fastbin 范围内，需要注意的是这里比较的是无符号整数。此外，是从 fast bin 的头结点开始取 chunk。
1 | /* |
small bin
如果获取的内存块的范围处于 small bin 的范围，那么执行如下流程
1 | /* |
large bin
当 fast bin、small bin 中的 chunk 都不能满足用户请求 chunk 大小时，就会考虑是不是 large bin。但是，其实在 large bin 中并没有直接去扫描对应 bin 中的 chunk，而是先利用 malloc_consolidate（参见 malloc_state 相关函数） 函数处理 fast bin 中的 chunk，将有可能能够合并的 chunk 先进行合并后放到 unsorted bin 中，不能够合并的就直接放到 unsorted bin 中，然后再在下面的大循环中进行相应的处理。为什么不直接从相应的 bin 中取出 large chunk 呢？这是 ptmalloc 的机制，它会在分配 large chunk 之前对堆中碎片 chunk 进行合并，以便减少堆中的碎片。
1 | /* |
大循环 - 遍历 unsorted bin
如果程序执行到了这里，那么说明 与 chunk 大小正好一致的 bin (fast bin， small bin) 中没有 chunk 可以直接满足需求 ，但是 large chunk 则是在这个大循环中处理。
在接下来的这个循环中，主要做了以下的操作
- 按照 FIFO 的方式逐个将 unsorted bin 中的 chunk 取出来
- 如果是 small request，则考虑是不是恰好满足，是的话，直接返回。
- 如果不是的话，放到对应的 bin 中。
- 尝试从 large bin 中分配用户所需的内存
该部分是一个大循环，这是为了尝试重新分配 small bin chunk，这是因为我们虽然会首先使用 large bin，top chunk 来尝试满足用户的请求，但是如果没有满足的话，由于我们在上面没有分配成功 small bin，我们并没有对 fast bin 中的 chunk 进行合并，所以这里会进行 fast bin chunk 的合并，进而使用一个大循环来尝试再次分配 small bin chunk。
1 | /* |
unsorted bin 遍历
先考虑 unsorted bin，再考虑 last remainder (最后剩余块），但是对于 small bin chunk 的请求会有所例外。
注意 unsorted bin 的遍历顺序为 bk（从尾部到头部）。
1 | // 如果 unsorted bin 不为空 |
small request
1 | /* |
初始取出
1 | /* remove from unsorted list */ |
exact fit
如果从 unsorted bin 中取出来的 chunk 大小正好合适，就直接使用。这里应该已经把合并后恰好合适的 chunk 给分配出去了。
1 | /* 如果大小完全匹配，则直接取用，而非放入 bin 中 */ |
place chunk in small bin
如果是小请求把取出来的 chunk 放到对应的 small bin 中。
1 | /* place chunk in bin */ |
place chunk in large bin
如果不是小请求把取出来的 chunk 放到对应的 large bin 中。
1 | } else { |
最终取出
1 | // 放到对应的 bin 中，构成 bck<-->victim<-->fwd。 |
while 迭代次数
while 最多迭代 10000 次后退出。
1 | // #define MAX_ITERS 10000 |
large chunk
注： 或许会很奇怪，为什么这里没有先去看 small chunk 是否满足新需求了呢？这是因为 small bin 在循环之前已经判断过了，这里如果有的话，就是合并后的才出现 chunk。但是在大循环外，large chunk 只是单纯地找到其索引，所以觉得在这里直接先判断是合理的，而且也为了下面可以再去找较大的 chunk。
如果请求的 chunk 在 large chunk 范围内，就在对应的 bin 中从小到大进行扫描，找到第一个合适的。
1 | /* |
