C 应用程序中 MALLOC 的资源消耗答案

【问题标题】：Resource Consumption of MALLOC in a C ApplicationC 应用程序中 MALLOC 的资源消耗
【发布时间】：2011-05-15 18:24:56
【问题描述】：

我正在编写一个 C 应用程序，我使用 malloc 在堆上创建数据。现在，当应用程序处于活动状态时，这些数据始终是持久的，所以我从不“释放” Malloc 数据。

我的问题是：这个内存会在应用程序终止时自动释放，还是我必须在应用程序完成时手动执行 free()？

【问题讨论】：

【解决方案1】：

这是实现定义的。严格遵循 C 标准，您应该在应用程序终止之前 free malloc'd 的所有内容。

但是，任何现代通用操作系统都会在您之后进行清理，因此这只适用于某些嵌入式、老式或其他特殊环境。

作为一种风格，请尝试free 每个分配的块。它让您养成编写干净代码和防止内存泄漏的习惯。

【讨论】：

我在标准中找不到任何声明或暗示您“应该释放”您 malloc 的所有内容。自然地，托管环境和进程的性质超出了 C 语言规范的范围，但我无法想象任何具有“运行程序”感的操作系统，其中程序的内存不会在退出时被放弃给操作系统，甚至没有DOS。当然，没有操作系统的嵌入式环境甚至可能没有“运行程序”或“退出”的概念，在这种情况下，这无关紧要。
@R..：我没有准备好标准的副本，但我记得它没有指定退出时 malloc 的内存会发生什么。我听说（没有参考，所以这可能只是谣言）一些较旧的大型机操作系统需要明确的free，因为它们每个用户只有一个地址空间。

【解决方案2】：

它将被释放。这就是“过程”抽象的奇妙之处。此正在运行的进程所拥有的所有资源和内存在终止时都会被释放。

请注意，提出这种抽象需要一些时间，但它是一个非常好的系统沙箱。事实上，杀死进程甚至被用作最后的手段来尝试修复在执行数天时出现泄漏或性能下降的错误程序（它被称为"Process Rejuvenation"，甚至存在于会议和期刊中，但实际上是承认糟糕的设计或编码）。

【讨论】：

【解决方案3】：

你永远不应该明确地free 这样的内存。充其量它不会给您带来任何好处，而最坏的情况它会将大量换出的数据交换回内存，只是为了检查一些簿记指针，然后将其丢弃，从而无缘无故地破坏用户的硬盘驱动器。

【讨论】：

-1 反对大多数非 OOP 语言中最知名的做法之一：“始终释放您分配的内容”。好处之一是它可以帮助您保持代码自包含，因此一旦您在不同的应用程序中使用某些代码（库例程？），并且在该应用程序中分配的块不会持续到应用程序终止，您将能够轻松地重复使用代码。否则，您可能很难找到什么时候必须释放哪些东西。
你可以给所有你想要的 -1，但我的建议会给出一个表现更好的程序。
我倾向于同意 R，尽管说 "never" 似乎过于规范。如果您的代码是库代码，它应该提供释放使用资源的清理函数——是否调用它们取决于应用程序。确实，在进程退出时遍历大型数据结构仅到 free() 它们（这通常甚至不会将内存返回给操作系统！）可能是一项耗时的忙碌工作。
我怀疑 Firefox 问题是（密切相关的）级联 C++ 对象析构函数之一，而不是简单的 free() s。
如果你的应用程序有很多这样的小分配，你可以创建自己的具有相同行为的分配器 - 它会使用mmap() 获得一大块，跟踪高水位标记，并且只允许您使用整个批次中的单个munmap() 来释放它。这样的分配器可能在库代码中很有用。