第3章堆内存

课程目录第3章堆内存

3. 堆内存：手动管理、new/delete、内存泄漏根源

堆内存，说白了就是程序员自己说了算的那块地盘。栈上变量由系统自动回收，但堆上的东西，你不放手，它就一直在那儿。我见过太多项目，最后崩就崩在堆内存管理上。

今天咱们就把堆内存的来龙去脉彻底讲清楚。你想想看，为什么C++要保留手动管理？为什么说new/delete是双刃剑？内存泄漏到底是怎么发生的？

3.1 堆内存的本质

堆内存是进程虚拟地址空间中的一块动态区域。它不像栈那样后进先出，而是可以任意顺序分配和释放。这意味着——灵活，但也意味着碎片化。

我个人习惯把堆想象成一个巨大的仓库。你每次new，就是在仓库里划一块地。delete，就是把地还回去。但问题是，还回去的地可能不连续，久而久之仓库就变得坑坑洼洼。

核心区别：

栈：自动分配/释放，速度快，大小固定（通常几MB）
堆：手动分配/释放，速度较慢，大小灵活（取决于物理内存）

3.2 new/delete 的底层机制

new和delete不是简单的函数调用。它们背后有一套完整的机制。

// 基本用法
int* p = new int(42);    // 分配内存 + 构造
delete p;                // 析构 + 释放内存

// 数组形式
int* arr = new int[100];
delete[] arr;            // 注意：必须用delete[]

嗯，这里要注意：new做了两件事——调用operator new分配原始内存，然后调用构造函数。delete则反过来：先调用析构函数，再调用operator delete释放内存。

我曾经踩过的坑：new[]和delete[]必须配对使用。用delete释放new[]分配的内存，会导致未定义行为。不是所有编译器都会报错，但后果可能很严重——比如只析构了第一个元素，其余99个对象的内存泄漏了。

3.3 内存泄漏的根源

为什么会内存泄漏？说白了就三种情况：

忘记delete——最常见，new了之后忘了释放
异常路径导致跳过delete——函数中途抛出异常，后面的delete没执行
指针被覆盖——指向堆内存的指针被重新赋值，原来的地址找不到了

// 情况1：忘记delete
void leak1() {
    int* p = new int(10);
    // 忘记 delete p;
}

// 情况2：异常导致跳过
void leak2() {
    int* p = new int(10);
    doSomething();  // 如果抛出异常，p就泄漏了
    delete p;
}

// 情况3：指针被覆盖
void leak3() {
    int* p = new int(10);
    p = new int(20);  // 原来的10泄漏了
    delete p;         // 只释放了20
}

我在项目中遇到过最隐蔽的一种泄漏：在循环里new对象，但条件分支太多，某个分支忘了delete。跑几个小时内存就爆了。查这种bug特别痛苦，因为不是每次执行都会触发。

3.4 堆内存管理的核心原则

手动管理堆内存，有几个铁律必须遵守：

原则	说明	违反后果
谁new谁delete	分配者负责释放	内存泄漏
配对使用	new/delete, new[]/delete[]	未定义行为
释放后置空	delete后把指针设为nullptr	悬空指针
避免重复释放	同一个地址不能delete两次	堆损坏

我的建议：能用智能指针就别用裸指针。C++11之后，unique_ptr和shared_ptr能帮你自动管理生命周期。但理解裸指针的原理依然重要——因为智能指针底层也是new/delete，只是帮你包了一层。

3.5 堆内存的常见陷阱

手动管理堆内存，陷阱比你想的要多。我列几个最常见的：

悬空指针：delete之后没有置空，后续代码又使用了这个指针
二次释放：两个指针指向同一块内存，各自delete了一次
内存碎片：频繁new/delete导致堆空间碎片化，后续大块分配失败
越界访问：写入超过分配大小的数据，破坏堆管理结构

// 悬空指针示例
int* p = new int(5);
delete p;
*p = 10;  // 危险！p已经是悬空指针

// 二次释放示例
int* p1 = new int(5);
int* p2 = p1;
delete p1;
delete p2;  // 二次释放！

你想想看，这些bug为什么难查？因为它们不会每次都崩溃。有时候运气好，那块内存还没被重新分配，程序就继续跑了。但一旦被分配给了其他对象，数据就被污染了，崩溃的地方离bug发生的地方可能隔了十万八千里。

3.6 堆内存管理的核心流程

为了让你更直观地理解堆内存的整个生命周期，我画了一张图：

3.7 如何检测内存泄漏

说实话，靠肉眼审查代码来找泄漏，效率太低了。我推荐几个工具：

Valgrind（Linux）：最经典的内存检测工具，能精确定位泄漏位置
AddressSanitizer（ASan）：编译时插桩，运行时检测，性能开销比Valgrind小
Visual Studio 诊断工具：Windows下集成，方便好用
Dr. Memory：跨平台，轻量级

// 使用AddressSanitizer检测泄漏
// 编译时加上：-fsanitize=address -g
// 运行时会自动报告泄漏位置

#include <cstdlib>

void leak() {
    int* p = (int*)malloc(sizeof(int) * 100);
    // 忘记 free(p)
}

int main() {
    leak();
    return 0;
}
// 运行输出会显示：
// ==12345==ERROR: LeakSanitizer: detected memory leaks
// Direct leak of 400 byte(s) in 1 object(s) allocated from:
//     #0 0x... in malloc
//     #1 0x... in leak()

我的经验：在项目里，我习惯在CI流程中加入内存泄漏检测。每次提交代码都自动跑一遍，发现问题立刻报警。别等到上线了再查，那时候成本就高了。

3.8 总结

堆内存管理是C++的硬骨头。手动管理给了你最大的控制权，但也把责任完全交给了你。new/delete本身不复杂，复杂的是在异常、多线程、复杂生命周期下保证不出错。

嗯，我个人的建议是：

新代码优先用智能指针
必须用裸指针时，严格遵守谁分配谁释放
每次new之后，立刻想好对应的delete在哪里
善用工具，别全靠肉眼

记住：堆内存管理没有银弹。理解原理、养成好习惯、善用工具，这三样缺一不可。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

3. 堆内存：手动管理、new/delete、内存泄漏根源

3.1 堆内存的本质

3.2 new/delete 的底层机制

3.3 内存泄漏的根源

3.4 堆内存管理的核心原则

3.5 堆内存的常见陷阱

3.6 堆内存管理的核心流程

3.7 如何检测内存泄漏

3.8 总结