linux - libc内存管理

Question

libc 如何与操作系统(例如 Linux 内核)通信以管理内存？具体来说，它是如何分配内存的，又是如何释放内存的呢？另外，在什么情况下它会分别无法分配和取消分配？

Answer 1

这是一个非常笼统的问题，但我想谈谈分配失败。重要的是要认识到内存实际上是由内核在第一次访问时分配的。您在调用 malloc/calloc/realloc 时所做的是在进程的虚拟地址空间内保留一些地址(通过系统调用 brk、mmap 等。libc 就是这样做的)。

当我得到 malloc 或类似的失败时(或者当 libc 得到 brk 或 mmap 失败时) ，通常是因为我耗尽了一个进程的虚拟地址空间。当没有连续的空闲地址 block ，没有扩展现有地址的空间时，就会发生这种情况。您可以耗尽所有可用空间或达到限制 RLIMIT_AS。这在使用多线程的 32 位系统上尤其常见，因为人们有时会忘记每个线程都需要它自己的堆栈。堆栈通常会消耗几兆字节，这意味着在您没有更多可用地址空间之前，您只能创建几百个线程。也许地址空间耗尽的更常见原因是内存泄漏。 Libc 当然会尝试重用堆上的空间(通过 brk 系统调用获得的空间)并尝试 munmmap 不需要的映射。但是，它无法重用未“解除分配”的内容。

由于分配失败，无法从进程(或作为进程一部分的 libc)内检测到物理内存不足。是的，您可以达到“过度使用限制”，但这并不意味着物理内存已全部占用。当可用物理内存不足时，内核会调用称为 OOM killer (Out Of Memory Killer)的特殊任务，该任务会终止某些进程以释放内存。

关于 deallocate 失败，我的猜测是它不会发生，除非你做了一些愚蠢的事情。我可以想象将程序中断(堆末尾)设置在其原始位置下方(通过 brk 系统调用)。那当然是灾难的根源。希望 libc 不会那样做，它也没有多大意义。但它可以看作是失败的释放。如果您提供一些愚蠢的参数，munmap 也可能会失败，但我想不出它失败的常规原因。这并不意味着它不存在。我们必须深入挖掘 glibc/kernel 的源代码才能找到答案。