malloc之后再进行free，free的内存空间一定被OS回收了吗？
我认为暂时不会，但是总归是会回收的。操作系统有一个滞后的内存管理机制。
对malloc函数实现调用brk和sbrk Linux，首次33页调用malloc（一页内存是4096字节，可以使用int getpagesize函数（void）的观点），以避免不必要的内存开销，当多个应用程序（每个应用程序，释放所有的资源，甚至作为一个给如果所有的自由了的话，），操作系统将保持到下一个配置，33页将物理映射，只有当进程退出时，那么，即使你分配到跨国经营的记忆，不会发生数据错误后，但不能保证其安全性。可能是新分配的内存擦除。
一.每一个malloc应用程序的内存将增加12个字节，在原来的基础上（一说16），这是用来维持一套实现数据结构的内存管理，如头指针，块长度和自由的标记。一旦修改，就会导致错误。
二.BRK和sbrk的实现是基于栈的操作。分配后，它必须被释放，但malloc来解决这个问题。它是免费的，它们的分布不会互相影响。这就是C语言必须实现这个功能的原因。
三.现代操作系统是分页管理存储器。如果你只是自由的一部分，页面的另一部分仍然在使用，它显然不会被回收。
此外，自由并不一定是标准的库函数。例如，如果您使用的是一种特殊的实现，那么您不会为高效的光分配释放该类型。
MacPaw
2024-09-20 广告
我认为是会的，内存肯定也是资源的一种存在形式。如果你不回收利用，你每次都要退出去，多来几次，那你的内存直接就没了。 若是glibc，你所free掉的内存，不一定会马上被OS回收，这是合理的。试想一下，你每次free掉的内存都还给OS的话，尤其是在小字节的情况下，那么造成的情况，就是一大块的内存被你弄的千疮百孔，也就是说一块内存，里面有很多gap。而在操作系统的虚拟内存管理中，更是管理着的是固定大小的内存，如4K，那你还给我1 Byte，OS显然是很尴尬的。
为了避免这个问题，内存管理通常有一个免费的列表，删掉的那些没用的东西就在这里面了。那么你可能会释放很散乱的内存过来，没关系，我们在这里会尝试合并这些散乱的block，而malloc首先找的也是free block list，而非从OS申请新的内存。
所以如果你找到了合适的自然最好的，如果你发现了一个比你想要的更大的，那么一部分malloc，另一部分放回去。而有的同学提到了小内存的问题，而这也是free block list在头部会有一些所谓的administrative data，所以用标准的malloc和free管理小内存是不高效，因为越小越容易造成gap。
最后友情提醒每个malloc实现都不同，不要只参考了一个实现之后就认为其它malloc实现也会做一样的取舍。
