内存生命周期：分配、使用、释放的全过程
好了，咱们直接切入主题。内存这东西，说得直白点，就是程序运行时的“办公室座位”。你坐进去、干活、站起来走人。整个过程就三个步骤：分配、使用、释放。任何一个环节出问题，程序就可能崩给你看。
我这些年排查过的泄漏案例，十有八九都能在这个生命周期里找到病根。你想想看，分配了没释放，或者释放了还在用，都是常见的翻车姿势。咱们今天就把它彻底掰扯清楚。
第一步：分配——你得先有块地
内存分配分两种路子：静态分配 和 动态分配。静态分配是编译器帮你安排的，像全局变量、static变量、栈上的局部变量。动态分配呢，就是运行时你主动找系统要——C里用malloc，C++用new，Java里就是new对象。
我个人习惯在团队里强调：能静态就别动态。为啥？静态分配自动回收，省心。但现实是很多时候不知道数据有多大，只能动态来。
| 特性 | 静态分配 | 动态分配 |
|---|---|---|
| 分配时机 | 编译时 / 加载时 | 运行时（程序员手动） |
| 存放位置 | 数据段 / 栈 | 堆 |
| 释放方式 | 自动（作用域结束 / 程序结束） | 手动 free / delete 或 GC |
| 大小灵活性 | 固定，编译时已知 | 可变，运行时决定 |
| 常见泄漏风险 | 低 | 高（忘记释放、多次释放） |
记得有一次在服务器项目中，实习生把一个大数组放在栈上，结果栈溢出。我告诉他：栈空间有限，大块数据要用堆。这就是分配阶段选错地方的问题。
第二步：使用——这块地你打算怎么用？
分配完内存，你就拿到一个指针。这时候你可以在上面读写数据。但这里头坑特别多。
- 越界访问：你分配了10个字节，却写了20个。C/C++不检查，直接干到隔壁内存里。
- 空指针解引用：
malloc返回 NULL 你直接用了——崩溃。 - 内存碎片：频繁分配小块再释放，堆变得像瑞士奶酪，大块申请失败。
我见过一个老项目，每周定时重启，就是因为内存碎片导致关键分配失败。修复方案就是把频繁分配的小对象改成对象池。
// 错误示范——不检查返回值
char *buf = (char*)malloc(1024);
strcpy(buf, "danger"); // 如果malloc失败，buf是NULL，直接崩
// 正确做法
char *buf = (char*)malloc(1024);
if (buf == NULL) {
// 处理分配失败
return -1;
}
// 安全使用
strcpy(buf, "safe");
第三步：释放——用完记得还
这一步是泄漏的“重灾区”。你分配了，用完了，但没还给系统。一次泄漏几百字节，日积月累，程序就跪了。
释放的规矩很简单：free / delete 一把梭。但实际中常见三种作死姿势：
- 忘记释放：最常见的泄漏。特别是异常路径或者提前return的地方。
- 重复释放：两次
free同一块内存，直接double free崩溃。 - 释放后使用：你
free了，但指针还留着，过一会儿又去读写——野指针。
所以我现在每次free之后，习惯立刻把指针设成NULL：
free(ptr);
ptr = NULL; // 防野指针
当然，现代C++推荐用智能指针，RAII帮你自动释放，省心不少。Java/C#有GC，基本上不用开发者手动释放。但底层原理你还得懂，不然遇到GC调优和STW问题照样懵。
生命周期全景图
下面这张图把整个生命流程串起来了，顺便标出了每个环节的“事故高发区”：
malloc / new 都必须有对应的 free / delete。如果做不到，就用智能指针或GC。
三个阶段的相互影响
你可能会觉得这三个阶段是独立的。其实不是。分配阶段埋的坑，可能在释放阶段才爆。举个例子：你在堆上分配了一个结构体，用完后 free 了，但其他线程还持有指向这块内存的指针——这就是释放后使用。它在分配阶段看起来没问题，使用阶段也没报错，到了释放之后才出乱子。
反过来，释放阶段的错误也会影响分配。比如你重复释放了一块内存，堆管理器的元数据被破坏，后续的 malloc 可能直接返回垃圾地址。嗯，这种bug查起来真的头大。
gcc -fsanitize=address 就开了。
// 编译时加 sanitizer
gcc -g -fsanitize=address -o test test.c
./test // 出现问题时直接打印详细信息