32位Linux系统无法耗尽物理内存的技术问题咨询

老兄，我之前跟几个深耕C和系统底层的老伙计也掰扯过这个问题，一开始大家都懵，直到把内存管理的底层逻辑扒透才搞明白。你说的这个故意造内存泄漏的程序，在64位Windows/Linux上看似“符合预期”——比如任务管理器/top里的内存占用一路飙升，但肯定有某个细节让所有人都卡壳了对吧？

我把核心原因拆解成几个点，你对照着看：

• 64位虚拟地址空间的“冗余度”：32位系统用户态最多也就4GB虚拟地址（还得刨掉内核占的），内存泄漏很快就会把地址空间耗尽触发崩溃。但64位系统不一样——Windows用户态有8TB虚拟地址，Linux甚至能给到128TB，这就导致你的程序能疯狂分配虚拟地址，短时间内根本用不完，物理内存都耗尽了，虚拟地址还剩一大片，这就让“内存泄漏导致崩溃”的预期被大大延迟，甚至看起来“没触发预期结果”。

• 操作系统的内存超售（Overcommit）机制：以Linux为例，默认允许程序分配超过物理内存+交换分区的内存空间——但这只是给你虚拟地址，只有当你实际往内存里写数据时，系统才会分配物理页。如果你的泄漏程序只是malloc内存却不写入数据，那你看top里的VSZ（虚拟内存大小）会暴涨，但RSS（实际占用物理内存）几乎不动。很多人只看RSS，就会误以为内存泄漏没生效，这也是为啥没人能立刻解释的关键。

• 内存分配器的缓存策略：不管是glibc的malloc还是Windows的堆管理器，都会把释放的内存缓存起来复用，但你的程序只分配不释放，缓存机制没用武之地。不过64位下分配器的地址扩展更灵活，不会像32位那样很快碰到堆的上限，这也让泄漏的表现更“温和”，不容易立刻触发异常。

给你贴段我当时测试用的代码，你跑一下就能明白：

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

int main() {
    int count = 0;
    while (1) {
        // 每次分配1MB内存
        char *buf = malloc(1024 * 1024);
        if (!buf) {
            perror("分配失败");
            break;
        }
        // 注释掉下面这行，Linux下RSS几乎不涨；打开它，RSS才会跟着VSZ暴涨
        // memset(buf, 0, 1024 * 1024);
        printf("已分配 %d MB\n", ++count);
        // 加个延迟方便观察
        sleep(1);
    }
    return 0;
}

说白了，这个问题的坑不在C代码本身，而是64位系统虚拟内存管理、操作系统超售策略和内存分配器行为的叠加效果——很多C开发者平时只关注业务逻辑里的内存泄漏，没深入到OS底层的内存映射机制，所以一时半会儿说不清楚。

内容的提问来源于stack exchange，提问作者root