为什么第一个 C++ (m) 分配总是 72 KB？

当您在C++程序中进行首次内存分配时，所请求的72 KB并非全是您代码要的那几个字节。这72 KB是标准库（glibc）为了未来高效分配而向操作系统预先申请的一块“启动资金”，它包含了管理结构、对齐填充以及一个用于小对象分配的初始内存池。

当调用 new 时，幕后究竟发生了什么？

一个简单的 new int 语句触发了一系列复杂的操作。编译器会将其转换为对 operator new 的调用，该操作符在Linux下通常由glibc的malloc函数实现。malloc（具体实现为ptmalloc2）的核心任务是高效地管理内存，它夹在应用程序和操作系统内核之间。

内核本身以“页”为单位（通常为4KB）管理内存，系统调用（如mmap或brk）的开销相对昂贵。如果每次分配都直接向内核请求，程序性能将不堪重负。因此，malloc的策略是批量申请一大块内存，然后自己精细地切割成小块分配给应用程序。第一次分配，就是这“第一批”内存的申请时刻。

72 KB 这个数字从何而来？

72 KB并非一个随机的魔法数字，而是由ptmalloc2的默认配置决定的。它主要包含以下几个部分：

• 主分配区（main_arena）的管理开销： 这是ptmalloc2用于跟踪已分配和空闲内存块的核心数据结构。
• 初始内存块（chunk）： 这是实际分配给用户程序使用的内存池。其默认大小约为64KB。
• 内存对齐填充： 为了满足系统严格的内存地址对齐要求（例如64位系统上常为16字节对齐），分配器会增加一些填充字节。
• 其他簿记信息： 每个分配的内存块都需要额外的数据来记录其大小和状态。

将管理开销（约8KB）和初始内存池（约64KB）相加，就得到了我们观察到的约72KB的总分配量。这个初始池会被用来满足后续的小内存分配请求，从而避免频繁的系统调用。

关键洞察：您看到的72 KB分配，并非您的4字节整数值72,000倍。它更像是您的程序为自己建立的一个小型、高效的“内存银行”，首次存款72 KB，以便在未来快速响应小额“取款”请求。

这是所有环境和编译器的标准行为吗？

并非如此。72 KB这个具体数字与以下几个因素紧密相关：

1. C运行库（C Runtime Library）： 此行为是GNU C库（glibc）及其ptmalloc2分配器的特性。如果使用其他库（如musl-libc或tcmalloc、jemalloc等替代分配器），首次分配的大小和行为可能完全不同。
2. 操作系统： 虽然原理类似，但在Windows（使用MSVC编译器）或macOS上，首次分配的大小会是另一个值。
3. 系统配置：
可以通过环境变量（如MALLOC_TOP_PAD_）调整glibc分配器的行为，从而影响初始分配的大小。
4. 架构和页面大小： 在不同的CPU架构（如ARM）或不同的系统页面大小下，分配策略也会相应调整。