Linux C++ 内存泄漏排查分析手册

文档时间： 2026-03

本文面向 Linux 下 C++ 项目（服务端、守护进程、命令行工具等），从内存泄漏常见场景与考点 、事前预防（编码规范与 RAII） 、事中检测（ASan、Valgrind、CI、监控） 、事后定位流程 到典型案例与速查表，整理为一套可落地的排查分析手册。便于团队统一规范、快速发现与修复泄漏。

一、内存泄漏基础：场景与判断

1.1 常见泄漏场景（面试与实战高频）

场景	说明
未释放动态内存	`new`/`malloc` 后忘记 `delete`/`free`，或路径遗漏（多 return/异常）
循环引用	`std::shared_ptr` 互相持有，引用计数无法归零，对象无法释放
异常安全	在 `new` 与 `delete` 之间发生异常，`delete` 被跳过
基类析构非虚	通过基类指针 `delete` 派生类时，若基类析构非 `virtual`，只调用基类析构，派生类资源泄漏
智能指针误用	同一裸指针构造多个 `shared_ptr`（重复释放）；类内 `shared_ptr(this)` 未用 `enable_shared_from_this`
资源泄漏	文件描述符、Socket、共享内存、句柄等未关闭（`close`/`shutdown`/`munmap` 等）
逻辑泄漏	对象仍被全局容器/缓存持有但业务已不用，内存只增不减，工具不报"泄漏"
多线程相关	线程/进程句柄未正确释放；引用计数非线程安全导致计数错误；TLS 未正确释放等。多线程下 ASan/Valgrind 仍可检测泄漏；若怀疑数据竞争导致计数错误，可结合 ThreadSanitizer(TSan) 或 Valgrind Helgrind

1.2 内存区域与"泄漏"的界定

区域	说明	是否算泄漏
栈	局部变量，自动回收	栈溢出不是泄漏；大数组导致栈溢出属编程错误
堆	`new`/`malloc`，需显式或智能指针释放	未释放即堆内存泄漏
数据段/代码段	全局/静态，程序结束回收	一般不称泄漏，但大对象会长期占内存

1.3 Linux 特有资源泄漏

文件描述符 ：open/read/write 后未 close，可用 lsof -p <pid> 或 ls /proc/<pid>/fd 查看。
Socket ：socket/bind/listen/accept 后未 close，可用 ss -tanp/netstat -anp 查看。
共享内存/信号量 ：shmget/shmdt/munmap/semctl 等未成对释放。
子进程 ：未 wait/waitpid 导致僵尸进程，消耗内核资源。

1.4 真泄漏 vs 逻辑泄漏

类型	含义	工具表现
真泄漏	分配后再也无法通过任何指针访问，永远无法释放	ASan/Valgrind 报 `definitely lost` 等
逻辑泄漏	对象仍被容器/全局变量持有，但业务已不用，导致 RSS 持续增长	工具通常不报，需靠监控与业务分析

判定思路：进程运行时间越长 RSS/PSS 越高且不回落 → 可疑泄漏；重启后指标恢复 → 基本可确认为泄漏。

泄漏与 OOM：长期真泄漏或逻辑泄漏会导致进程 RSS 持续上升，最终可能触发 OOM（Out of Memory）被系统杀死；排查时要与「一次性大块分配导致 OOM」区分------前者随运行时间恶化，后者多在启动或某次操作后很快发生。

泄漏嫌疑判定流程（示意）：
否
是
是
否
RSS 持续上升?
非泄漏嫌疑
重启后恢复?
基本确认泄漏
可能为业务增长/缓存
用 ASan/Valgrind 定位

二、事前预防：编码规范与设计约束

2.1 资源管理原则

RAII：资源获取即初始化，将资源生命周期绑定到对象，析构时自动释放。
谁申请谁释放，严禁跨模块裸指针随意传递所有权；优先用智能指针或 RAII 封装。

2.2 RAII 在 Linux 中的实践

文件描述符封装示例：

cpp 复制代码

class FdGuard {
    int fd_;
public:
    explicit FdGuard(int fd) : fd_(fd) {}
    ~FdGuard() { if (fd_ >= 0) ::close(fd_); }
    int get() const { return fd_; }
    // 禁止拷贝，避免同一 fd 被 close 两次
    FdGuard(const FdGuard&) = delete;
    FdGuard& operator=(const FdGuard&) = delete;
};

Socket、锁、共享内存映射等同样可封装为 RAII，在析构中调用 ::close(sockfd)、munmap 等。

2.3 智能指针使用规范

建议	说明
默认用 unique_ptr	独占所有权，无引用计数开销
需要共享时用 shared_ptr	并用 `std::make_shared` 构造，避免同一裸指针构造多个 `shared_ptr`
循环引用必须用 weak_ptr 打断	画出对象关系图，双向引用的一侧改为 `weak_ptr`
类内需要 shared_ptr(this)	使用 `std::enable_shared_from_this`，禁止直接 `shared_ptr(this)`

用 weak_ptr 打断循环引用示例：

父子节点若互相持有 shared_ptr，引用计数永不为 0，导致泄漏。将「从子到父」或「从父到子」的一侧改为 weak_ptr 即可打断环。
正确
shared_ptr
weak_ptr
Parent
Child
错误
shared_ptr
shared_ptr
Parent
Child

cpp 复制代码

struct Node {
    std::shared_ptr<Node> next;
    std::weak_ptr<Node>   prev;  // 用 weak_ptr 打破循环，避免泄漏
};

2.4 异常安全

避免在 new 之后、delete 之前写可能抛异常的代码；推荐用智能指针，天然异常安全。

cpp 复制代码

// 不安全：doSomething() 抛异常则 p 泄漏
void foo() {
    char* p = new char[1024];
    doSomething();
    delete[] p;
}

// 安全：异常时 p 自动释放
void foo() {
    auto p = std::make_unique<char[]>(1024);
    doSomething();
}

2.5 基类析构函数规则

若类会被继承且可能通过基类指针 删除，基类析构函数必须为 virtual，否则只调用基类析构，派生类部分泄漏。

cpp 复制代码

class Base {
public:
    virtual ~Base() = default;
};

2.6 代码审查要点

每个 new 是否有对应 delete 或由智能指针接管？
每个 malloc 是否有对应 free？
多 return/异常路径上是否都正确释放？
shared_ptr 是否存在循环引用？是否用 weak_ptr 打破？
文件/socket/共享内存是否在所有 return/throw 前关闭？
可继承类的析构函数是否为 virtual？

三、事中检测：工具链配置与使用

3.1 AddressSanitizer（ASan）+ LeakSanitizer（LSan）

编译参数（GCC/Clang）：

bash 复制代码

g++ -g -O1 -fno-omit-frame-pointer \
    -fsanitize=address,leak \
    main.cpp -o app_asan

运行后自动检测越界与泄漏，并打印完整堆栈（文件名、行号）。
Direct leak ：明确泄漏；Indirect leak：多为容器持有泄漏对象。
注意：ASan 会明显增加内存与时间开销，不适合生产环境全量开启 ；第三方库误报可用 -fsanitize-blacklist=asan.blacklist 排除。

3.2 Valgrind Memcheck

bash 复制代码

valgrind --tool=memcheck --leak-check=full \
         --track-origins=yes --log-file=valgrind.log ./app

输出类型	含义
definitely lost	确定泄漏
possibly lost	可能泄漏（如指针偏移）
still reachable	程序结束时仍可访问（常为全局对象未释放，不一定是 bug）

优点：不需重新编译（建议带 -g），兼容性好。
缺点：性能开销大，适合本地或测试环境完整回归。
第三方库误报 ：可用 --suppressions=file 指定 suppressions 文件，忽略指定栈的 still reachable 等报告，例如：valgrind --leak-check=full --suppressions=my.supp ./app。

3.3 CI/CD 自动化检测

在单元测试/集成测试中开启 ASan，泄漏即阻断合并。

CMake 示例：

cmake 复制代码

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -g -O1 -fsanitize=address,leak")

GitLab CI 示例：

yaml 复制代码

build-asan:
  stage: test
  script:
    - mkdir build && cd build
    - cmake .. && make
    - ctest --output-on-failure || true
  artifacts:
    paths: [asan_report.txt]

3.4 线上/灰度监控

内存趋势 ：采集 /proc/<pid>/status 中 VmRSS/VmHWM，或 ps -p $PID -o rss= 定期写入日志，绘制曲线；连续多次 RSS 增长超阈值则告警。
句柄与连接 ：lsof -p <pid> 看 fd 数量；ss -tanp/netstat 看 TIME_WAIT/CLOSE_WAIT 堆积。
Heap Profiler（可选）：jemalloc/tcmalloc 开启 profiling，定期 dump 分析分配热点。

简易 RSS 采集脚本示例：

bash 复制代码

while true; do
    ps -p $PID -o rss= >> rss_log.txt
    sleep 60
done

四、事后定位：排查流程

排查流程概览：
是
否
确认现象
RSS/fd 持续增长?
缩小范围
非泄漏或需长期观察
工具定位
ASan/Valgrind 拿堆栈
修复并验证
再次跑工具 + 压测

确认现象 ：top/htop/smem 看 RSS 是否只增不减；lsof -p <pid> 看 fd 是否持续增长；ss -tanp 看连接状态是否异常堆积。
缩小范围：按模块/功能灰度关闭，观察指标变化；在关键路径加日志或计数器，看分配/释放是否匹配。
工具定位：本地用 ASan/Valgrind 复现，获取泄漏堆栈；若无法本地复现，在测试环境用 jemalloc/tcmalloc heap profiler 抓 profile。
修复与验证 ：改为智能指针或 RAII、补全 close/shutdown/munmap 等；再次跑 ASan/Valgrind + 长时间压测，确认指标平稳。

五、典型案例

案例	场景	现象	修复
shared_ptr 循环引用	父子节点互相持有 `shared_ptr`	ASan 报大量对象未释放	将一方改为 `weak_ptr`
文件描述符泄漏	`open()` 后某分支提前 return 未 `close()`	`lsof` 中 fd 数持续增长	用 FdGuard 等 RAII 封装
异常导致 delete 未执行	`new` 后执行业务逻辑，中间抛异常	Valgrind 报 `definitely lost`	用 `unique_ptr` 或 try/catch 确保释放
基类析构非虚	基类指针 delete 派生类对象	派生类成员/资源未释放	基类析构声明为 `virtual`
容器逻辑泄漏	全局 map/vector 只增不减，无淘汰	RSS 随业务量线性增长，工具不报	增加 LRU/TTL 等清理策略

六、附录：速查表与 FAQ

6.1 常用命令速查

用途	命令
查看进程内存	`top` / `htop` / `cat /proc/<pid>/status
查看 fd 数量	`ls -l /proc/<pid>/fd
查看 socket	`ss -tanp
ASan 编译	`g++ -g -O1 -fsanitize=address,leak ...`
Valgrind	`valgrind --leak-check=full --track-origins=yes ./app`

6.2 代码审查 Checklist

每个 new 都有对应 delete 或由智能指针接管
每个 malloc 都有对应 free
shared_ptr 是否存在循环引用，是否用 weak_ptr 打破
异常路径是否仍能保证资源释放
文件/socket 是否在 return/throw 前关闭
可继承类的析构函数是否为 virtual

6.3 检测工具对比与选择

工具	平台	特点
ASan + LSan	Linux，需重编	速度快，适合开发与 CI；开销大，不适合生产
Valgrind Memcheck	Linux，可不重编	兼容性好，开销大，适合本地/测试回归
VS CRT Debug Heap	Windows	调试器内 `_CrtDumpMemoryLeaks()` 等，适合本地
jemalloc/tcmalloc profiler	Linux	可做 heap profile，分析分配热点，适合线上轻量分析

工具选择示意：
是
否
是
否
是
需要查泄漏
能重编且跑测试?
ASan + LSan
仅本地/测试机?
Valgrind
线上/生产
RSS/fd 监控 + heap profiler
怀疑竞争导致计数错?
TSan / Helgrind

6.4 FAQ

Q: ASan 报的泄漏在 Valgrind 里看不到？

A: 可能 Valgrind 未跑完泄漏路径，或 ASan 更敏感；可对比两者报告。
Q: 线上能开 ASan 吗？

A: 一般不建议，性能与稳定性影响大；建议用内存趋势监控 + heap profiler + 日志。
Q: 如何避免第三方库"假泄漏"？

A: ASan 用 -fsanitize-blacklist=asan.blacklist 排除符号；Valgrind 用 --suppressions=file 忽略指定栈（如 still reachable），或联系库维护者修复。
Q: 泄漏只在 Release 出现怎么查？

A: 用带符号的 Release 构建跑 ASan/Valgrind，或结合 heap profiler 与业务日志缩小范围。

小结与延伸阅读

小结

预防：RAII + 智能指针（unique_ptr/shared_ptr/weak_ptr）+ 基类析构 virtual + 代码审查。
检测：开发/CI 用 ASan、Valgrind；线上用 RSS/句柄监控 + 可选 heap profiler。
定位：确认现象 → 缩小范围 → 工具拿堆栈/profile → 修复后再测。

Linux C++ 内存泄漏排查分析手册