Native内存管理：C/C++内存分配，malloc/free与new/delete，Valgrind与AddressSanitizer
聊到Android内存管理，很多人第一反应是Java堆、GC、OOM这些。但说实话，真正让系统工程师头疼的，往往是Native层的内存问题。我这些年排查过的性能故障里，有一大半最后都追到了C/C++代码头上。
Native内存管理，说白了就是你自己管自己。Java有GC帮你擦屁股，C/C++可没这好事。你new出来的对象，必须亲手delete；你malloc的内存，必须亲手free。少一个，就是泄漏；多一次，就是崩溃。
malloc/free：C语言的内存基本功
先说说最基础的malloc和free。这两个函数是C标准库提供的，底层通过brk或mmap系统调用向内核申请内存。
// 分配一个int数组
int* arr = (int*)malloc(10 * sizeof(int));
if (arr == NULL) {
// 分配失败，处理错误
return -1;
}
// 使用...
free(arr);
arr = NULL; // 我习惯释放后立即置空，防止野指针这里有个细节很多人忽略：malloc返回的地址，实际指向的内存块头部还藏着管理信息。你申请100字节，系统可能实际分配了108字节。这也是为什么频繁小内存分配会导致碎片化。
核心要点：malloc/free只关心内存块的大小和生命周期，不调用构造函数和析构函数。这是它和new/delete最大的区别。
new/delete：C++的对象生命周期管理
new和delete是C++的运算符。它们做了两件事：分配内存 + 调用构造函数/析构函数。
// 分配单个对象
MyClass* obj = new MyClass();
// 分配对象数组
MyClass* arr = new MyClass[10];
// 释放
delete obj;
delete[] arr; // 注意：数组必须用delete[]嗯，这里有个坑。我遇到过好几次线上崩溃，最后发现是new和delete不匹配。new用了delete[]，或者new[]用了delete，轻则内存泄漏，重则堆损坏。
警告：new/delete和malloc/free绝对不能混用！用new分配的内存，必须用delete释放；用malloc分配的，必须用free释放。混用会导致未定义行为，程序可能随时崩溃。
底层实现：它们到底怎么工作的？
我画了一张图，帮你理清这两套机制的关系：
从图里能看出来，无论你用new还是malloc，最终都会落到内核的系统调用上。但中间那层内存管理器，才是真正决定性能的关键。
Valgrind：内存问题的老牌侦探
Valgrind是个工具集，其中最常用的是Memcheck。它能检测出：
- 未初始化的内存读取
- 越界访问（缓冲区溢出）
- 内存泄漏
- 重复释放
- 使用已释放的内存（野指针）
# 基本用法
valgrind --tool=memcheck --leak-check=full ./my_program
# 输出示例
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 5
==12345== at 0x4C2B800: malloc (vg_replace_malloc.c:299)
==12345== by 0x4005E7: main (test.c:10)我曾经在一个Android系统服务里，用Valgrind抓到了一个隐藏了两年的内存泄漏。那个泄漏每次只漏8字节，但每秒钟触发几百次，两年下来累积了几十GB。没有Valgrind，这种问题根本无从查起。
使用技巧：Valgrind会让程序运行慢10-20倍，不适合生产环境。我一般只在开发阶段和CI流水线里跑。另外，Android上跑Valgrind需要root权限，或者用eng版本的系统镜像。
AddressSanitizer (ASan)：更轻量、更现代的选择
ASan是LLVM/Clang内置的检测工具，比Valgrind快得多（只慢2-3倍）。它通过编译时插桩，在内存访问前后插入检查代码。
# 编译时启用ASan
clang -fsanitize=address -g -O1 my_program.c -o my_program
# 运行
./my_program
# 检测到越界时会直接输出并终止
==12345==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000000f4
WRITE of size 4 at 0x6020000000f4 thread T0
#0 0x4008a7 in main /home/user/test.c:15ASan的优势在于：
- 编译时集成，不需要额外运行环境
- 检测精度高，能定位到具体的代码行
- 支持Android NDK开发，Google官方推荐
注意：ASan会增加二进制体积（约2倍），并且会占用更多内存（约2-3倍）。所以只建议在debug版本或测试版本中开启。我见过有人把ASan开到了release版本里，结果应用启动就OOM了。
实际项目中的选择建议
| 场景 | 推荐工具 | 原因 |
|---|---|---|
| 开发阶段，快速迭代 | ASan | 编译时集成，速度快，定位精准 |
| 深度排查，怀疑堆损坏 | Valgrind | 检测全面，能发现ASan漏掉的问题 |
| Android NDK开发 | ASan + HWASan | Google官方支持，兼容性好 |
| CI/CD自动化测试 | 两者都跑 | 互补检测，覆盖更全面 |
说实话，没有哪个工具是万能的。我自己的习惯是：开发时开ASan，提交前跑一遍Valgrind。两个工具配合使用，基本能覆盖99%的Native内存问题。
最后提醒一句：工具再好，也不如写代码时多留个心眼。每次malloc/new之后，第一时间想好谁来free/delete，什么时候释放。养成这个习惯，能省掉你后面无数个通宵排查的夜晚。