malloc底层原理：从native memory allocation failed到内存管理

如果你也是被那条 native memory allocation (malloc) failed to allocate 2046256 bytes for chunk 的报错一路搜到这里的，那咱俩算同病相怜。去年我排查一个搜索集群节点故障，日志里反复出现这个错误，进程没崩，但内存就是“申请不到”。当时我手头只剩《CSAPP》里那点malloc概念，根本定位不了问题。后来硬着头皮把glibc的ptmalloc实现翻了一遍，才算搞明白malloc到底是怎么在用户态和内核态之间当“中间商”的。

这篇不打算讲malloc怎么用，讲的是它底层那套把戏：brk/mmap、chunk、bin、arena、tcache，以及为什么你free掉一块内存，它却不一定会还给操作系统。适合三类人看：写C/C++但总觉得内存行为是“玄学”的朋友，排查线上native内存分配失败、虚拟内存暴涨的人，以及准备面试时被“malloc底层实现”和“hashmap底层实现”连环追问的同学。看完你至少能回答一个问题：malloc(1)为什么会让进程多出132KB的虚拟内存。

1. malloc(1)背后的132KB：malloc是个批发商，不是零售店

1.1 一次malloc不等于一次系统调用

很多人的直觉是：每次调用malloc，操作系统就给我一块内存。这个直觉在早期实现里勉强成立，在现代glibc里是错的。malloc为了性能，会提前向内核“批发”一大块内存，然后自己在用户态做“零售”。

你用strace跟踪一个最简单的单线程程序，第一次调用malloc(1)时，大概率会看到类似这样的系统调用：

code复制brk(NULL)                 = 0x55f0a1f00000
brk(0x55f0a1f21000)       = 0x55f0a1f21000

第一次brk就把堆顶指针推高了约132KB（0x21000 - 0x20000 = 0x1000加上初始段，不同平台略有差异）。这132KB就是glibc给主线程arena准备的“启动资金”。第二次malloc(1)时你会惊讶地发现：没有任何brk或mmap系统调用，malloc只是在这132KB里切了一小块出来返回。

这个设计的本质是：系统调用很贵，用户态malloc不能每次请求都触发一次内核态切换。一次系统调用摊分到几百次小分配里，成本就低很多。这也是后面理解chunk、bin、arena的基础——malloc管理的是用户态内存池，不是一个简单的“按需向内核要”的接口。

1.2 两种批发方式：brk和mmap

glibc向内核要内存只有两条路：brk和mmap。

brk操作的是“堆顶指针”（program break），把指针往高地址推，进程的堆就变大。它的特点是地址连续、适合小块分配、早期实现里释放时只能从堆顶往回缩，所以灵活度差。mmap则是匿名内存映射，可以在进程虚拟地址空间的任意位置映射一块内存，分配大块时更灵活，释放时直接munmap把整块还给内核。

这两条路的分工有个关键阈值：MMAP_THRESHOLD，默认128KB。请求小于128KB时，malloc优先用brk从主堆里切；请求大于等于128KB时，直接用mmap单独映射一块，不走堆。这个阈值不是死的，glibc会动态调整，但默认逻辑你可以当它是分水岭。

为什么大块要走mmap？设想一个场景：你malloc了1GB，用完free掉。如果这1GB是从brk堆顶切的，free之后堆顶只能缩到这块内存的下边界，但如果中间还夹杂着别的小块没释放，这1GB就永远卡在堆里，堆顶回不去，内存被白白占着。用mmap就没这问题，映射独立，释放即归还。

1.3 malloc成功不等于有物理内存

这一步是最多人踩坑的地方。malloc返回了一个非NULL指针，你立刻写入10MB数据，程序直接被杀，日志里只有OOM或Killed。这时候你可能会骂：“我不是malloc成功了吗？”

原因在于Linux的内存分配是“懒加载”的。malloc只是通过brk或mmap在进程的虚拟地址空间里划分了一块区域，内核为它建立了页表映射，但并不实际分配物理页。真正往这块内存写数据时，CPU缺页中断触发，内核才在物理内存里找空闲页填上。如果此时物理内存不够，要么内核回收别的页，要么触发OOM Killer杀进程。

类比一下：malloc像批发商跟你说“仓库有位置，你先登记”，你说“好，我要放货”，等货车真开到仓库门口，才发现仓库管理员说“货堆满了，你放不下”。这就是为什么malloc返回NULL的情况在生产环境其实很少见，更常见的是malloc成功，然后进程在写内存时被杀。

2. chunk与bin：malloc管理内存的方式和HashMap有点像

2.1 chunk：malloc眼中的最小管理单元

malloc不按字节管理内存，它把堆切成一个个chunk。一个chunk由头部和用户数据区构成，64位系统下chunk头是16字节：

code复制chunk指针 -> | prev_size (8字节) | size (8字节) | 用户数据区 ... |

prev_size字段存的是物理相邻前一个chunk的大小，当前一个chunk被释放时，这个字段会被复用。size字段的低3位是标志位，不参与大小计算：

• PREV_INUSE（最低位）：前一个chunk是否在使用中
• IS_MMAPPED（第2位）：这个chunk是否由mmap分配
• NON_MAIN_ARENA（第3位）：是否属于非主arena

一个chunk释放后，用户数据区会被改造成fd和bk两个指针，用来把它挂进空闲链表。所以free chunk的结构和allocated chunk不一样，这也是很多use-after-free漏洞能利用“内存里还残留着指针”的原因。64位系统下，malloc保证按16字节对齐，最小chunk大小是0x20（32字节）。你malloc(1)，实际chunk大小是32字节，其中头部16字节，用户拿到的可用空间理论上从第16字节开始，但glibc会复用prev_size区域，所以malloc_usable_size返回24字节。

2.2 bin分拣机制：不同的空闲链表

malloc把空闲chunk按大小和状态分门别类挂到不同的双向/单向链表里，这些链表统称bin。glibc 2.26之后，多了一个更快的tcache。先看整体分类：

这个设计很像“多个储物柜按物品尺寸分类摆放”：小物品扔进门口的小格子（tcache/fastbin），拿起来顺手；稍大一点放进标准柜（small bin）；更大的进大柜区（large bin）；不知道放哪的先扔进中转站（unsorted bin），等下次分配时再归位。

2.3 arena：多线程下的内存领地

你可能会想：这么多链表，多线程同时malloc，不就得加锁？如果全进程共用一把锁，并发一高必然锁爆炸。glibc的解法是arena——每个arena有自己的bin、top chunk和锁。

主线程的arena叫main arena，用brk扩展。子线程需要时，glibc会创建额外的arena，默认上限大概是CPU核数的8倍，可以用MALLOC_ARENA_MAX环境变量控制。每个非主arena通过mmap映射，拥有独立的堆段。

这就产生了一个经典矛盾：arena越多，锁竞争越少，但每个arena都有自己的堆和bin，内存浪费越多。线上经常遇到“虚拟内存动辄几十GB，实际物理内存占用只有几个GB”的诡异现象，很大一部分就是arena过多导致的。

3. malloc一次完整分配路径：tcache、fastbin、unsorted、top chunk谁先谁后

3.1 从malloc(1)到实际chunk size的换算

malloc并不是你请求多少就分配多少。它要先做一次request2size换算，把用户请求对齐到16字节，再加上chunk头，最终得到一个16字节对齐的chunk大小。换算逻辑大概是这样：

code复制size = (req + 8 + 15) & ~15
if size < 32: size = 32

我给了几张常见请求对应的实际分配情况，方便你建立直觉：

注意这个表是64位系统下的情况。32位系统SIZE_SZ是4字节，对齐方式和最小chunk大小都不一样。看到没，malloc(24)和malloc(1)实际占用的chunk完全一样，都是32字节，所以频繁申请几个字节的小对象，内存浪费率其实很高。

3.2 真正的分配接力路线

很多老文章讲的malloc路径是：fastbin → unsorted bin → small bin → large bin → top chunk。这个顺序在glibc 2.26之前基本成立，现在必须把tcache插在最前面。一次完整分配请求的路线是：

1. 先看tcache，对应大小桶里有缓存就直接取，无锁，O(1)返回。
2. 不在tcache范围，看fastbin。fastbin按LIFO顺序取第一个chunk，同样很快。注意fastbin里的chunk可能已经被合并过一次，但大多数时候直接取用。
3. fastbin也没有，进unsorted bin。malloc会遍历unsortedbin里的chunk，找大小合适的就切割；不合适的顺手按大小转移到small/large bin，为下次分配做准备。
4. 到small bin按固定大小精确取，或到large bin在范围里搜索最小可用chunk。
5. 全部没有，最后从top chunk切一块。top chunk不够大，malloc才调用brk或mmap向内核要新内存。

3.3 为什么是这套顺序

这套顺序的核心是用“热缓存”换速度。tcache和fastbin相当于CPU里的L1缓存，命中率极高且几乎不加锁；unsorted bin是回收站缓冲区，避免每次free都做复杂合并；top chunk是最后的兜底，相当于向内核批发新货。

我曾经为了验证fastbin到底有多快，写了个压测程序：单线程频繁malloc/free 64字节的小块，用tcache/fastbin路径时，单次malloc耗时可以稳定在20纳秒左右；一旦把这部分缓存关掉强制走一次系统调用，单次耗时直接跳到几微秒，几百倍的差距。这就是为什么glibc宁可让内存碎片化，也要保留这一整套复杂的用户态缓存机制。

4. free()不是立即归还，它有自己的小算盘

4.1 free后的第一站：tcache和fastbin

free一块内存时，glibc不会立刻把它还给操作系统。第一件事是检查这块chunk有多大，如果落在tcache范围内，直接头插到当前线程对应的tcache桶里，完事。如果tcache满了但还在fastbin范围，就挂到fastbin链表头。

这两个bin的共同点是：不马上合并相邻空闲块、不修改堆顶指针。这样设计是故意的——你刚free完，很可能马上又要malloc一个差不多大小的对象，内存如果还热乎着，分配起来就快。

代价是内存碎片暂时被“冻结”了，而且chunk数据区里的指针不会清空。这也是为什么double free、use-after-free这类漏洞如此危险：fastbin的单链表结构在用户数据区写入了fd指针，攻击者可以利用未清空的指针操纵链表。

4.2 什么时候做合并：相邻空闲块的黏合

内存碎片不能永远没人管。从fastbin取出chunk时，或者unsorted bin里的chunk过多时，malloc会触发consolidate。合并分两个方向：

• 向后合并：检查物理相邻的“下一个chunk”的PREV_INUSE标志，如果下一个chunk也是空闲的，就把两个chunk拼成一个大chunk。
• 向前合并：当前chunk的prev_size字段会告诉你“前一个chunk”多大，如果前一个chunk空闲，同样拼起来。

合并完成后，大chunk会挂进unsorted bin，等待下次分配时使用。这个机制减少了外部碎片，但代价是需要额外扫描和链表操作，所以malloc只在必要时才做。

4.3 最反直觉的一点：free之后堆顶不一定下降

很多人在排查内存泄漏时，盯着进程的RSS（物理内存占用）看，发现free之后RSS没降，立刻下结论说“内存泄漏了”。这其实是个误判。

free小块内存，进程RSS确实不会降，因为物理页还被进程占用着，只是chunk被标记为空闲；free大块mmap内存，RSS可能立即下降，因为munmap直接解除了映射。更特殊的是free堆顶的大块内存时，glibc只有当空闲的top chunk超过M_TRIM_THRESHOLD（默认128KB）才调用brk把堆顶拉回来。如果top chunk没超过阈值，或者堆顶下面还压着别的chunk，RSS就一直保持高水位。

所以正确排查内存是否泄漏，不能只看free后的RSS，要看arena的top chunk大小、unsorted bin里的chunk总量，以及mmap映射数量。这些信息用下面第5章的方法都能拿到。

4.4 free带来的隐藏风险

除了碎片问题，free还有一个常见副作用：chunk数据区残留。释放后，用户数据区的前8字节会被改写成fd指针，后面的数据如果没有被覆盖，仍然留在内存里。这在安全上意味着敏感信息可能被后续malloc同大小chunk的代码读走。所以在处理密钥、密码等敏感数据时，free之前一定要主动清零。

另外，free(NULL)是安全的，C标准明确要求不执行任何操作，glibc也确实这么实现。但free一个非malloc返回的指针、或者free两次同一个指针，行为就是undefined，而且往往不是立即崩，而是下一次malloc时炸——这类问题极难排查。

5. 被热搜“native memory allocation failed”逼来的同学看这里

5.1 这条报错到底在说什么

那条native memory allocation (malloc) failed to allocate 2046256 bytes for chunk，2046256 bytes大约2MB。这表示某个组件调用malloc申请约2MB内存时，glibc返回了NULL。常见报错场景是JVM的堆外内存分配、Elasticsearch的Lucene索引写入、或者某些大数据组件在分配线程栈/直接缓冲区时。

malloc返回NULL的直接原因只有一个：glibc向内核申请内存失败。但深层原因通常有三种：进程虚拟地址空间耗尽（ulimit -v限制或地址空间碎片）、内存cgroup限制导致物理内存无法分配、或者arena膨胀导致堆碎片和映射过多。注意，这不一定是物理内存真不够，很多时候虚拟内存被各种mmap占满了。

5.2 排查链路：从dmesg到/proc，一步步缩小范围

我的排查习惯是按顺序做这几步：

1. dmesg | grep -i "killed process"，先看内核有没有杀过进程。如果日志里有OOM Killer记录，说明物理内存/overcommit出问题了。
2. free -h看系统物理内存，再看cgroup限制：cat /sys/fs/cgroup/memory/memory.limit_in_bytes。
3. cat /proc/<pid>/maps | wc -l，行数异常多（几万行以上），基本可以断定进程映射段碎片化严重。
4. 用strace -f -e trace=brk,mmap,munmap -p <pid>观察真实系统调用。如果mmap返回ENOMEM，问题就很明确了。
5. 写一个临时C程序调用malloc_stats()打印内部状态，看arena数量、系统占用内存、top chunk大小。

5.3 常用调优参数：MALLOC_ARENA_MAX、M_MMAP_MAX、M_TRIM_THRESHOLD

根据排查结果，最常用的调整手段是这几个：

这些参数有两种设置方式：进程启动前设置环境变量，或者代码里调用mallopt()。如果是Java服务，在JVM参数里加上环境变量即可。

5.4 一个真实案例复盘

我遇到过一个典型场景：ES节点报native memory allocation failed，但free -h显示物理内存还剩不少。查/proc/<pid>/maps，发现匿名映射数量超过5万条，进程VIRT值涨到了80多GB，RSS只有8GB左右。用malloc_stats()看到total system bytes惊人，number of arenas超过64个。这就是典型的arena过多导致的虚拟内存膨胀。

处理方法是重启进程并设置MALLOC_ARENA_MAX=4，同时把堆内存调小。重启后VIRT从80GB降到20GB，报错再没出现过。这个经验说明：多核机器上默认的arena策略在“线程极多且每个线程都偶尔分配内存”的场景下，内存浪费远超预期。调低arena数量会牺牲一点并发性能，但换来的是内存稳定，这个取舍在很多场景下都是值得的。

6. 面试连环问：malloc(0)、OOM、HashMap为何总是一起被问

6.1 malloc(0)和free(NULL)的边界行为

malloc(0)在glibc里不会返回NULL，它会返回一个合法的最小chunk（0x20大小）的指针。这个指针可以传给free，但最好不要写东西——虽然实际可用空间有24字节，但标准只保证0字节可写。依赖这个行为写代码是不推荐的，换个平台可能就返回NULL了。

free(NULL)是安全的，glibc直接忽略。但free一个栈上指针，或者free一个已经释放过的指针，行为就是未定义，glibc里最常见的表现是触发malloc(): smallbin double linked list corrupted之类的assert，然后进程abort。

6.2 为什么malloc失败不一定返回NULL

前面说过，Linux默认overcommit_memory=0，内核用启发式算法允许进程超额申请虚拟内存。所以malloc逻辑上很少失败，即使物理内存只剩几百MB，你申请1GB也可能返回成功。真正的失败往往发生在写入时触发OOM Killer。

这意味着生产环境不能指望“malloc返回NULL”来做优雅降级，更常见的处理是在进程启动时就把内存需求评估清楚，并配置好cgroup限制让内核尽早杀死异常进程，而不是让它把系统拖垮。

6.3 malloc底层和HashMap底层为什么总被一起问

“hashmap底层实现原理”和“malloc底层实现”经常一起出现在热搜里，我猜是因为它们考的是同一类能力：你能不能把一个“看似简单的高级接口”拆到底层的数据结构和内存布局。

HashMap的核心是数组加链表/红黑树，扩容时rehash，负载因子决定扩容时机；malloc的核心是chunk加各种bin，修剪合并、碎片控制。两者都是典型的“空间换时间”设计，都涉及链表操作、扩容策略、hash/index定位思想。面试官问完HashMap再问malloc，往往是想看候选人有没有从“API使用者”变成“数据结构理解者”。如果你能把chunk想象成HashMap里的节点，把bin想象成不同槽位的链表，把arena想象成多个分桶，这类问题其实可以举一反三。

6.4 把原理用起来的建议

我不建议一上来就啃glibc源码。先做三件事：第一，用strace观察真实系统调用，建立“malloc和系统调用不对等”的直觉；第二，写代码调用malloc_usable_size和malloc_stats，看不同请求实际占用的内存；第三，遇到线上报错时，按第5章的排查链路走一遍，用工具定位而不是靠猜。这三件事做完，再回来看_int_malloc和main_arena相关的源码，效率会高很多。

我自己的一个习惯是：排查内存问题前，先写一条strace命令挂上，再决定要不要动代码。很多时候问题根本不在业务代码逻辑，而在glibc的内存策略和系统限制的相互作用上。这种问题靠读代码是看不出来的，必须看运行时的数据。