理解 Linux 内存分配：malloc、brk、mmap 关系及 overcommit 参数

2.2 大块内存分配：直接使用 mmap()

对于较大的内存分配（通常阈值约为 128KB，但在本测试系统中显示为 16MB），malloc() 会完全绕过堆，转而直接使用 mmap() 来完成分配：

// 分配一块大内存
void *ptr = malloc(20 * 1024 * 1024);

strace 的输出显示：

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

这实际上是将内存直接映射到虚拟地址空间中的那些'空隙'位置。

3. 内存限制：物理内存（RAM）与虚拟内存

现在，让我们尝试分配一块远远超过物理内存容量的大型内存空间：

// 尝试分配 100GB
void* ptr = malloc(100ULL * 1024 * 1024 * 1024);
if(ptr)
    printf("Success!\n");
else
    printf("Failed!\n");

在我们拥有 45GB 内存的系统上，得到的结果是：Failed!。

为什么会这样呢？这是因为在默认情况下，Linux 采用了一种称为 'overcommit（内存超量分配）' 的策略，用来限制进程可分配的内存总量。我们可以查看配置项：

$ cat /proc/sys/vm/overcommit_memory
0

当 overcommit 设置为 0（默认值）时，Linux 基于启发式策略来决定是否允许内存超量分配。它并不严格把分配额度限制在物理内存大小之内，但会尽量确保应用程序不会使用超过物理内存可承受范围的内存。运行二分搜索测试时，最大分配量接近物理内存容量（约 45.33 GB）。

4. 通过 Overcommit 打破限制

修改 overcommit 的设置后，再次尝试：

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

此时运行测试程序，结果为：Success!。

当 overcommit 设置为 1 时，Linux 的策略变得非常'乐观'。它会直接返回你所请求的虚拟内存地址，但在真正访问这些内存之前，并不会实际为其预留对应的物理内存。启用 overcommit 后，最大可分配内存可达 70 TB 左右，远超物理内存容量。

5. malloc() 与 mmap() 的极限对比

不再使用 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() 调用，最多可以分配 125 TB 的内存，而使用 malloc() 时却只能分配 70 TB。差异在于 malloc() 内部维护了额外的数据结构，而 mmap() 更直接地利用底层虚拟内存映射布局。

6. 实践中的内存分配

基于实验结果，总结内存分配在实际运行中的表现：

6.1 元数据开销

每一次通过 malloc() 进行的内存分配，都会包含一定的内部管理开销。小块内存分配（< 128KB）仅有少量元数据开销，而较大的内存分配则会产生更高的开销。

6.2 使用 mmap() 的分配阈值

在我们的系统上，当分配大小达到或超过 16MB 时，malloc() 就会改为使用 mmap() 来进行内存分配。

6.3 虚拟地址空间碎片化

限制我们最大可分配内存大小的最主要因素是虚拟地址空间的碎片化。直接 mmap() 调用可以更高效地利用底层的虚拟内存映射布局，受碎片化影响相对较小。

7. 理解内存分配的最大限制

综合以上分析，我们得出了不同场景下的内存分配上限：

决定这些上限的关键因素包括：

• 关闭 overcommit 时：内存分配上限主要受限于物理内存容量。
• 启用 overcommit，使用 malloc() 时：上限受限于 malloc() 的实现机制。
• 启用 overcommit，使用 mmap() 时：上限主要受限于虚拟地址空间的碎片化程度。

8. 对嵌入式与内核开发的启示

对于嵌入式系统开发者或内核开发者而言，这些发现具有重要的实际意义：

• 资源受限环境：在 RAM 资源有限的嵌入式系统中，建议将 overcommit 设置为 2，以防止在内存请求无法由物理内存实际支撑时仍然'成功'分配。
• 内存碎片化问题：在长时间运行的系统中，虚拟地址空间碎片化可能会逐渐成为一个严重问题，从而不断降低单次可分配内存的最大尺寸。
• 自定义内存分配器：在某些场景下，可能需要实现定制的内存分配器，以更好地满足特定需求。
• 直接硬件交互：在部分嵌入式系统中，可能需要使用 mmap() 并指定具体的物理地址，来直接映射物理内存区域以进行硬件交互。
• 内存池机制：对于频繁分配固定大小内存的场景，可以考虑使用内存池（memory pool），以减少内存碎片并降低分配与释放的开销。