malloc和free的复杂性

我有两个相关的问题，因此我在这一个线程中问他们

Q1）当程序终止时，我如何确认我的操作系统是否自动清除未“释放”的内存（使用malloc分配）？我正在使用Ubuntu11.04，32位和gcc-4.5.2

根据Steven Summit的教程页面，“释放未使用的内存（malloc'ed）这是一个好主意，但不是强制性的。当您的程序退出时，它已分配但未释放的任何内存都应自动释放。如果您的计算机仅仅因为程序忘记释放内存而以某种方式“丢失”内存，则表明您的操作系统存在问题或不足

Q2）假设foo.c mallocs是一个B字节的内存。稍后，foo.c将释放此B字节内存位置并将其返回到操作系统现在我的问题是，在当前实例中，这些特定的B字节内存位置是否可以（由操作系统）重新分配给foo.c，或者在其当前实例终止之前，这些B字节不能分配给foo.c

---

编辑：我建议所有阅读我的问题的人阅读类似问题的答案，然后进行编辑。这两个答案都很详细地解释了malloc（）和free（）的交互和工作，而没有使用非常深奥的术语。了解内核使用的内存管理工具（如brk（），mmap（））与C编译器使用的内存管理工具（如malloc（），free（））之间的区别是必须的。大多数现代操作系统都会回收分配的内存，因此您无需担心。
操作系统不知道您的应用程序/程序是否泄漏了内存。一旦进程完成，它只会回收分配给进程的内存

---

是的，释放的内存可以重用（如果需要）&重用可以在同一个实例化中发生。

Q1。您只需假设操作系统运行正常

---

问题2。没有理由不能将字节重新分配到foo.c，这只是取决于内存分配例程的工作方式。

当进程通过终止信号（例如

SIGSEGV

）或系统调用（从

main

返回时也会调用）结束时，所有进程资源都由内核释放。特别是，释放进程地址空间，包括堆内存（分配给系统调用（或者

sbrk（2）

）系统调用（由

malloc

库函数使用）

当然，

free

库函数要么（通常）通过以后对

malloc

的进一步调用使释放的内存区域可重用，要么（偶尔，对于大内存区域）使用例如

munmap（2）

系统调用将一些大内存块释放到内核

要了解有关进程1234的内存映射的更多信息，请依次阅读

/proc/1234/maps

伪文件（或从进程内部读取

/proc/self/maps

）。文件系统是查询内核有关进程的首选方法。（还有

/proc/self/statm

和

/proc/self/smap

以及许多其他有趣的东西）

free

和

malloc

的详细行为取决于实现。您应该将

malloc

视为获取堆内存的一种方式，并将

free

视为表示以前的

malloc

-ed区域无效的一种方式，系统（即标准C库+内核）可以用它做任何事情

用于查找内存泄漏bug。您也可以考虑使用，即使用<代码> GcMaLoC/<代码>代替<代码> MalOC ，不必费解手动内存。

Q1）我不确定你如何确认。但是，关于第二段，总是释放你分配的内存被认为是一种好的风格。这里有一个很好的解释：

---

Q2）肯定；这些字节通常是第一个要重新分配的字节（取决于malloc实现）。有关详细的解释，请参见：。

是否有任何实际的方法来确认这一点，比如说我可以制作或直接使用的测试软件？@Abhinav：幸运的是，不需要这种开销。您只需要参考目标操作系统的文档，它就应该记录您的行为。@Abhinav，确认哪一部分？如果不检测操作系统，您无法确认操作系统是否正在回收进程内存，这将降低其内存管理速度，并且在具有统一页面缓存的现代操作系统中，您将很难破译。关于进程内存重用，请参阅。感谢您给出满意的答案。我想只要程序foo.c在运行，/proc/foo/目录就会存在。对吗？那么，在这种情况下，如何创建相应的映射文件？虽然我确实检查了一些正在运行的PID（例如chrome）的地图文件，它向我抛出了一堆惊人的信息。我很惊讶我不确定是否理解您的问题（不要忘记可执行文件和进程是不同的；给定的程序有一个可执行文件，例如shell的

/bin/bash

，但可以在多个进程中运行）<代码>/proc/1234/仅在进程1234存在时才存在。（这是一个伪文件，不在磁盘上，因此读取它很快）。在这个过程中，

/proc/self/

是它的一个符号链接。欢迎使用valgrind和Boehm的链接。第二个链接有一个非常惊人的答案。（）有一个学派认为，当你退出一个程序时，你不应该释放内存。他们的论点是，这就像清理你要搬出的房子，这将被拆除一样。这完全是浪费时间和精力。我不完全同意，但不能指责这个论点：）