为什么C管理堆而不是操作系统？

换句话说，为什么

free（）

不将内存返回到操作系统，而

malloc

只是从操作系统请求内存

这就引出了三个密切相关的问题：

• 为什么

  C

  需要管理自己的堆？（是因为操作系统只允许您分配和释放最小大小的连续内存吗？）
• 假设我在括号里写的是真的，为什么呢
• 这个问题是否会影响操作系统本身，使其无法为任何正在运行的进程分配内存块

malloc

本身就是一个C方法。您正在使用一个为您提供它的标准库，但最终，它是C代码，就像您的代码一样

在某些操作系统中，只能从操作系统获取页面大小的内存（使用

mmap

）。这对于常规数据结构来说太大了

每次需要内存时进行系统调用的成本太高了

为什么C需要管理自己的堆

实际上并没有指定It需要实现，但它需要按照标准中描述的方式实现

malloc（）

和friends。因此，如果有一个操作系统已经提供了这样一个接口，那么C实现只能提供一个很小的包装器

是因为操作系统只允许您分配和释放最小大小的连续内存吗？如果这是真的，原因是什么

---

对。典型的操作系统将管理分页内存，并映射或取消映射整个内存页。可“分页”的内存单元取决于硬件体系结构。您可能需要阅读一些有关如何工作的详细信息。在没有MMU的体系结构上，操作系统可能不会执行任何操作，C实现只会填充物理地址空间中固定位置的

malloc（）

请求。

实际上，它是留给实现的。问题是：

为什么free（）不将内存返回到操作系统，然后 malloc只是从操作系统请求内存

是错误的，因为没有任何东西可以阻止实现这样做。所以这个问题没有答案——每个实现都可能是不同的（它只需要符合标准）

为什么C需要管理自己的堆？（是因为操作系统只允许您分配和释放最小大小的连续内存吗？）

---

操作系统管理页面中的内存。分配和释放页面的开销很高。C语言中的大多数分配往往比页面大小小得多。

从其他答案中，我得出了答案

大多数操作系统只将内存分配给固定大小的进程，称为页面。当进程将内存返回到操作系统时，它只能以分页的形式返回内存。页是一个固定大小的内存序列。页面的起点和终点是固定的，因此即使您有足够大的可用内存，也无法将其返回到操作系统，除非它位于页面的起点和终点之间

---

另一方面，您可以想象没有操作系统（或者操作系统从自己的堆中为程序分配内存）。这有助于我更好地理解事物，因为操作系统阻碍了我的直觉，因为它看起来好像释放的内存被扔进了一个黑洞，而分配的内存来自一个类似的黑洞。如果没有任何操作系统，计算机中的所有内存都可能被描绘成属于一个大的单元序列。如果分配计算机中的所有可用内存，然后开始释放一些内存，则可能无法找到足够大的连续内存块来满足malloc请求。

首先，运行一个探查器，并计算由简单操作执行的

malloc（）

和

free（）

调用的数量。然后意识到每一个进程都会以系统调用的形式结束……操作系统是一个全国性的分销商，只处理大型请求。您的程序（用

C

或其他任何语言编写）是本地超市，可以为您提供少量内存。这完全取决于操作系统。[c]标记中最不流行的一个实际上实现了自己的堆，CRT只是直接使用它。这不是Unix的方式，在嵌入式系统中变得相当模糊。首先，C代码并不总是在操作系统上运行。假设存在操作系统是错误的。我用C语言执行过许多软件项目，这些项目都是在裸硬件上运行的。第2点并不适用于所有的操作系统。@MichaelWalz有趣-你知道有一个例子不是这样的吗？我如何在这些操作系统中分配内存？我相信mmap正在处理页面？@mrks Windows就是一个例子。或者可能是没有MMU的微控制器上的自定义环境。好的，因为问题中的“malloc”，我只考虑POSIX。严格遵守POSIX标准的OSs正确吗？@mrks POSIX标准不排除扩展API，所以不一定。