258 points • 3 days ago • Article Link

malloc 函数为内存管理提供了一个看似简单的接口，但它隐藏了程序与操作系统交互时背后的复杂真实情况。开发者只需申请字节并在之后释放，而系统为了避免频繁 syscall 带来的高昂开销，必须完成大量的簿记工作。通过观察一个进程的内存布局可以发现，它被划分为代码段、堆 heap 、栈 stack 等不同区域。当程序需要内存时，通常会移动 program break（也就是堆的末尾边界），而不是为每一次小分配都发起新的 syscall 。

实现一个基础的分配器可以说明简单方案的低效之处。每次请求都移动 program break 的 bump allocator 在功能上是正确的，但由于每次 syscall 都会带来显著的性能惩罚，因此表现不佳。像 glibc 这样的现代分配器会从内核一次性请求大块内存，然后在用户态将其切分使用。为了管理这些切片，系统会在每个内存块上附加 headers，保存必要的 metadata，使 free 函数能够识别块的大小，并维护可用于将来复用的空闲内存列表。

进一步完善这一过程需要实现 splitting 和 coalescing 。当手上有足够大的空闲块时，分配器可以将其 split 以满足小请求；而当内存被释放时，free 函数还能将相邻的空闲块合并，从而减少 fragmentation 。但这又带来了一个难题：如何把内存真正归还给操作系统。由于内核采用 demand paging，只在需要时才把虚拟内存映射到物理 RAM，仅仅在分配器里把内存标记为 free，并不会自动降低进程的 resident set size 。开发者必须手动触发 trim 来让内存释放回内核，不过这通常只有在空闲块位于堆的顶部时才可行。

对于特别大的请求，分配器往往会改用 mmap 系统调用，直接把内存映射到 address space，从而完全绕开堆。这种做法有利之处在于：一旦内存被释放，munmap 可以立即把这部分内存归还给内核，不受它在进程地址空间中位置的影响。虽然这种方式更灵活，但它还需要为新页创建映射，带来额外开销。因此，分配器通常只把这种策略留给大块分配，而把较小、频繁的分配留在堆上完成。

将自定义分配器与生产级的 glibc 实现进行对比，就能看出性能差距从何而来。 glibc 通过使用 bins 、 thread-local caches 等更复杂的结构来获得极快的速度，使系统能迅速找到合适大小的空闲内存，而不必遍历很长的链表。尽管这些优化能显著提升性能，但它们也凸显了内存管理的根本权衡：分配器为了避免与内核交互带来的延迟，会把 chunks 保留在 caches 或 pools 中，从而以"优先保证应用性能"为代价，延后未使用内存的即时释放。 The function malloc provides a deceptively simple interface for memory management, hiding the complex reality of how a program interacts with the operating system. While developers simply request bytes and eventually free them, the system must perform significant bookkeeping to avoid the high cost of frequent syscalls. By examining the memory layout of a process, we see that it is divided into distinct regions like the code, heap, and stack. When a program needs memory, it often moves the program break, which defines the end of the heap, rather than making a new syscall for every small allocation.

Creating a basic allocator demonstrates the inefficiency of simple approaches. A bump allocator that moves the program break on every request is functionally correct but performs poorly because each syscall carries a significant performance penalty. Modern allocators like those in glibc avoid this by requesting large blocks of memory from the kernel and slicing them up in userspace. To manage these slices, the system uses headers attached to each chunk of memory, storing essential metadata that allows the free function to identify the block size and manage lists of available memory for future reuse.

Refining this process involves implementing splitting and coalescing. When a large chunk is available, the allocator can split it to satisfy a small request, and when memory is released, the free function can merge adjacent empty chunks to prevent fragmentation. However, this raises the challenge of returning memory to the operating system. Because the kernel uses demand paging to map virtual memory to physical RAM only when necessary, simply marking memory as free in an allocator does not automatically lower the process's resident set size. Developers must manually trigger a trim to release memory back to the kernel, though this is only possible if the free chunks are at the top of the heap.

For very large requests, allocators often pivot to the mmap syscall, which bypasses the heap entirely by mapping memory directly into the address space. This approach is beneficial because munmap can return this memory to the kernel immediately upon being freed, regardless of its position in the process memory. While this offers greater flexibility, it also carries the overhead of creating new page mappings, which is why allocators generally reserve this strategy for large allocations while keeping smaller, frequent requests on the heap.

Comparing custom allocators to the production-grade glibc implementation highlights why performance gaps exist. Glibc achieves remarkable speed by using complex structures like bins and thread-local caches, which allow the system to quickly locate appropriately sized free memory without traversing long lists. While these optimizations significantly improve speed, they also illustrate the fundamental trade-off of memory management: allocators spend memory by keeping chunks in caches or pools to avoid the latency of kernel interactions, effectively prioritizing application performance over the immediate release of unused memory.