Linux 进程内存分配：malloc、brk、mmap 与 overcommit

对应的 strace 结果类似这样：

$ strace -e mmap ./our_program
mmap(NULL, 20971520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= 0x7f3700858000

这类内存会直接映射到进程地址空间里，不一定跟 [heap] 连在一起。对分配器来说，这样省掉了堆扩张和后续整理的一部分麻烦；代价是映射管理会更分散。

为什么申请 100GB 会失败

试着申请一块远超物理内存的大内存：

void* ptr = malloc(100ULL * 1024 * 1024 * 1024);
if(ptr)
    printf("Success!\n");
else
    printf("Failed!\n");

在一台 45GB 内存的机器上，结果是 Failed!。

关键在 overcommit。Linux 默认不是'你要多少我都先给'，它会先做一层启发式判断：

$ cat /proc/sys/vm/overcommit_memory
0

overcommit_memory=0 是默认策略。它不等于'死卡在物理内存大小以内'，但也不会毫无顾忌地放行大额申请。实际效果就是：可申请上限会跟物理内存、交换空间以及当前系统状态挂钩。跑二分搜索时，最大值大概接近这台机器的物理内存容量，约 45.33GB。

把 overcommit 打开，会发生什么

把策略改成 1：

$ sysctl -w vm.overcommit_memory=1
vm.overcommit_memory = 1

再跑同样的程序，结果就变成了 Success!。

overcommit_memory=1 的思路很直接：先答应你，至于以后真不真用得上这块内存，等访问时再说。也就是说，它返回的是虚拟地址的承诺，不是物理页的保证。这样一来，可分配上限会被地址空间和分配器实现细节拉高到一个很夸张的数值，测试里大约能到 70TB。

直接 mmap() 和 malloc() 的上限不一样

如果不经过 malloc()，直接调用 mmap()，结果还会再往上走一点：

# 直接 mmap 分配 125TB
mmap(NULL, 137438953472000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= 0x7f4db1b34000

# malloc 尝试分配 70TB
mmap(NULL, 76965814472704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)= 0x39835adaf000

这里能看到一个很实际的差别：

• mmap() 更接近内核的原始接口，分到哪、分多少，基本就是虚拟地址空间和映射布局的问题。
• malloc() 还要维护自己的分配器结构，路径更长，额外开销也更多。

所以两者的极限不是同一个数字，这不奇怪。

这些实验能说明什么

几个结论放在一起看，会比较完整：

元数据是有成本的

malloc() 不只是'给你一块内存'，它还要记账。小块分配的元数据相对少，块大了以后，分配器往往会直接切到 mmap() 路径，管理成本和系统调用成本都会上来。

阈值不是固定死的

在这台机器上，分配到 16MB 左右，malloc() 就开始偏向 mmap()。这个值不是标准答案，跟 libc 实现、版本和配置都有关系。实际排障时别把别人的阈值当成自己的结论。

真正卡你的，经常不是 RAM 本身

很多时候限制并不是'物理内存不够'，而是虚拟地址空间碎片化、分配器策略，或者 overcommit 的限制。尤其是长时间运行的进程，映射越来越碎，单次大块申请会越来越难看。

最大能分到多少

实验里得到的大致结果可以整理成这样：

背后的原因也很直接：

• 关闭 overcommit 时，上限主要被物理内存和系统内存账本卡住。
• 开启 overcommit 后，malloc() 先受分配器实现影响。
• 直接 mmap() 时，更多看虚拟地址空间和碎片化情况。

对嵌入式和内核开发更有用的部分

如果系统资源紧，overcommit 的默认策略通常不够稳。把它设成 2，至少能让'先分配、后失败'这类问题少一点。这个策略不会让申请看起来那么乐观，但在内存紧张的环境里，宁可申请时就失败，也别把问题拖到运行时才炸。

长时间运行的系统还会遇到碎片化。这个问题一开始不明显，等地址空间被各种库、映射、匿名页切碎以后，单次大分配就会越来越难做。

有些场景下，定制内存分配器比盯着 malloc() 更实在。比如固定大小对象特别多、释放模式也比较稳定时，内存池通常比通用分配器更省心。

如果要跟硬件直接打交道，mmap() 映射物理地址也还是常见手段，不过这已经不是普通应用层分配内存的范畴了，边界条件要自己兜住。

最后，频繁分配固定尺寸内存的程序，优先考虑内存池。它不优雅，但很管用；很多碎片问题，靠它确实能少很多。