编译程序时开启调试信息
Valgrind 报告的准确性依赖于调试符号。编译 C++ 程序时必须加上 -g 选项，以便 Valgrind 能定位到具体代码行。
示例：
g++ -g -O0 -Wall main.cpp -o myapp- -g：生成调试信息
- -O0：关闭优化，避免代码重排影响分析结果
- -Wall：开启警告，辅助发现潜在问题
使用 memcheck 检测内存泄漏
Valgrind 默认使用 memcheck 工具，可检测：
- 堆内存泄漏（new/delete 不匹配）
- 读写越界
- 使用已释放内存
- 使用未初始化内存
运行命令：
立即学习“C++免费学习笔记（深入）”；
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./myapp常用参数说明：
- --leak-check=full：详细显示每个泄漏块
- --show-leak-kinds=all：显示所有类型的泄漏（definite、indirect、possible 等）
- --track-origins=yes：追踪未初始化值的来源（对性能有影响）
- --verbose：输出更详细信息
解读 Valgrind 输出
典型内存泄漏输出片段：
==12345== 40 bytes in 1 blocks are definitely lost in loss record 1 of 2==12345== at 0x4C30F1B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12345== by 0x4E9A7D4: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6)
==12345== by 0x108757: main (main.cpp:10)
这表示在 main.cpp 第 10 行调用 new 分配了 40 字节，但没有被释放。
关键关注点：
- definitely lost：明确泄漏，new 后未 delete
- possibly lost：可能泄漏，指针丢失但仍有引用
- still reachable：程序结束时仍可达的内存，通常不是严重问题，但应检查
常见问题与修复建议
遇到以下情况需重点检查：
- 类中有指针成员，但未定义析构函数或未正确释放资源
- 异常抛出导致 delete 被跳过，建议使用智能指针（如 std::unique_ptr）
- 容器元素为原始指针，删除容器前未手动 delete 元素
- 循环或递归中动态分配内存但未及时释放
推荐做法：
- 优先使用 RAII 和智能指针管理资源
- 确保每个 new 对应一个 delete，每个 new[] 对应 delete[]
- 多线程环境下注意资源释放时机，避免竞态
