为什么 C++ 程序第一次内存分配总是 72 KB？揭秘 libstdc++ 的“应急内存池”

现象：即使分配 1 字节，也会“偷走” 72 KB？

在进行 C++ 性能调优或底层内存监控时，你可能会发现一个奇怪的现象：即使你的代码中只是简单地执行了 new char 或者初始化了一个 std::vector，通过 strace 或内存分析工具观察到的第一次堆内存分配（allocation）往往不是你申请的大小，而是一个固定的 72 KB 左右的数值。这究竟是操作系统的预热机制，还是 C++ 运行时隐藏的“税收”？

背后的真相：__cxa_allocate_exception

经过对 C++ 运行时库（特别是 GNU libstdc++）的深度分析，我们会发现这笔开销源于 C++ 的异常处理（Exception Handling）机制。具体来说，罪魁祸首是一个名为 __cxa_allocate_exception 的函数。

在 C++ 中，当程序抛出异常时，运行时需要分配内存来存储异常对象。然而，这里存在一个“先有鸡还是先有蛋”的问题：如果程序是因为内存耗尽（OutOfMemory）而抛出 std::bad_alloc，此时堆空间已经满了，程序又该如何分配内存来存储这个 std::bad_alloc 对象呢？

应急内存池（Emergency Pool）的引入

为了解决上述悖论，libstdc++ 在程序启动后的第一次内存分配动作时，会顺便初始化一个应急内存池（Emergency Pool）。其核心逻辑如下：

• 保障异常抛出：该内存池专门用于在常规堆空间枯竭时，确保依然有足够的空间来分配异常对象。
• 预分配策略：这种分配是贪婪的。一旦你的程序触发了任何涉及堆的操作，运行时就会认为程序可能需要异常处理支持，从而提前圈占这块内存。
• 72 KB 的由来：在典型的 Linux x86_64 系统上，libstdc++ 的源码（如 eh_alloc.cc）定义了应急池的大小。它通常包含约 64 KB 的数据区加上相关的管理元数据（metadata），最终在内存映射中体现为约 72 KB。

技术细节：源码层面的实现

在 libstdc++ 的源代码中，可以看到该池是通过 malloc 申请的一块静态区域。它被划分为多个小的 slot。当 __cxa_allocate_exception 被调用时，它会首先尝试正常的 malloc。如果 malloc 失败，它会立即转向这个“应急池”获取空间。

这意味着，即使用户的代码中从未写过 throw 语句，只要链接了标准库并进行了堆分配，这 72 KB 的开销通常是不可避免的，因为编译器和运行时无法在静态阶段完全确定程序永远不会抛出异常。

关键要点总结

• 内存开销：这是 C++ 健壮性设计的一部分，确保在极端 OOM 情况下程序仍能优雅地崩溃或处理异常。
• 嵌入式影响：对于内存极度受限的嵌入式系统，这 72 KB 可能是巨大的负担。开发者可以通过编译选项 -fno-exceptions 来禁用异常处理，从而移除这部分开销。
• ABI 层级：这种行为属于 C++ ABI（Itanium ABI）规范的一部分，因此在不同的 Linux 发行版中表现非常一致。

结论

那神秘的 72 KB 并不是内存泄漏，而是 C++ 为你的程序买的一份“意外保险”。了解这一机制有助于我们在开发高性能、低内存占用的应用时，对系统的内存布局有更精准的把控。