栈内存与堆内存：栈帧结构、堆分配与释放、内存泄漏

好，咱们今天聊聊内存管理。这个话题，说简单也简单，说复杂……嗯，我见过太多人栽在这上面了。

栈和堆，这两个概念你肯定听过。但真正在调试时能把它们分清楚，能一眼看出问题出在栈上还是堆上——这需要点功夫。我个人习惯把内存想象成两种不同的储物间，咱们一个一个来看。

栈内存：函数调用的临时舞台

栈，说白了就是系统自动管理的一块内存。你每调用一个函数，系统就会在栈上给你搭个「舞台」——这就是栈帧。

栈帧里放着什么？局部变量、函数参数、返回地址。函数一结束，这个舞台就被拆掉了。干净利落，不用你操心。

我在项目中遇到过一个问题：一个递归函数，参数传了个大结构体。结果跑着跑着就崩了。为什么？栈溢出了。每次递归都复制一份结构体到栈上，深度一深，栈空间就撑爆了。

你想想看，栈的大小通常是固定的——Linux 下默认 8MB，Windows 下 1MB。你要是敢在栈上放个 10MB 的数组，那程序直接给你脸色看。

// 危险操作：栈上分配大数组
void dangerous_func() {
    char buffer[1024 * 1024 * 10]; // 10MB，栈肯定炸
    // ...
}

// 正确做法：用堆
void safe_func() {
    char* buffer = (char*)malloc(1024 * 1024 * 10);
    if (buffer) {
        // 使用 buffer
        free(buffer);
    }
}

堆内存：你来管，你来放

堆就不一样了。堆上的内存，你申请，你释放。系统不会帮你擦屁股。

malloc、calloc、realloc 是申请，free 是释放。C++ 里还有 new 和 delete。道理一样，但 C++ 的 new 还会调用构造函数。

我曾经接手过一个项目，服务跑了三天就挂。查了三天日志，最后发现是堆内存泄漏。每次处理请求都 new 一个对象，但只有正常路径才 delete。异常路径直接 return 了，对象就永远留在堆上。

内存泄漏：看不见的杀手

内存泄漏，说白了就是你申请了内存，但丢了指向它的指针。这块内存就成了孤儿，谁也碰不了，直到程序结束。

泄漏的后果是什么？进程的内存占用持续增长。轻则被 OOM killer 干掉，重则拖垮整个系统。

泄漏类型	典型场景	检测方法
堆泄漏	malloc 后忘记 free	Valgrind、AddressSanitizer
资源泄漏	打开文件没关闭	lsof、/proc/pid/fd
循环引用	shared_ptr 互相引用	weak_ptr 打破循环

嗯，这里要注意：内存泄漏不是立刻爆发的。它像温水煮青蛙。你测试时跑几分钟看不出问题，上线跑几天就原形毕露了。

堆分配与释放的底层机制

堆是怎么工作的？简单说，glibc 的 malloc 会维护一个空闲链表。你申请内存时，它从链表里找一块合适的给你。释放时，它把内存块放回链表。

但这里面有坑。比如内存碎片——你频繁申请释放小块内存，堆上就会变得支离破碎。明明总空闲空间够，但找不到一块连续的大块内存。

我建议你这样做：

• 尽量分配大小相近的内存块
• 避免频繁分配释放
• 考虑使用内存池

// 内存池的简单思路
typedef struct MemPool {
    char* pool;
    size_t block_size;
    size_t block_count;
    int* free_list; // 空闲块索引
} MemPool;

栈 vs 堆：什么时候用哪个？

这个问题，我面试时经常问。答案其实很简单：

• 小对象、生命周期明确、函数内使用 → 栈
• 大对象、生命周期不确定、需要跨函数传递 → 堆

栈快，因为分配就是移动一下栈顶指针。堆慢，因为要遍历空闲链表、可能还要系统调用。

但栈空间有限，别贪心。

避坑指南

我曾经犯过一个低级错误：在循环里 malloc，但条件分支里忘了 free。结果跑了一晚上，内存涨到几十 GB，服务器直接挂了。

从那以后，我养成了几个习惯：

• 每次 malloc 后，检查返回值是否为 NULL
• free 后把指针置为 NULL，防止野指针
• 用工具检测泄漏：Valgrind 是我的老朋友了

知识体系图

下面这张图，是我梳理的栈与堆的核心逻辑。你看一眼，心里就有数了。

这张图把栈和堆的对比、各自的问题都列出来了。你调试时遇到崩溃，先想清楚是栈的问题还是堆的问题，方向对了，问题就解决了一半。

好了，栈和堆就聊到这儿。记住一句话：栈是系统管，堆是你管。管好堆，别泄漏，别越界，你的程序就能活得久一点。

可可精品资料库