专为C/C++开发者打造的内存剖析利器，实时追踪堆分配、精准…

# 游戏服务器 C++ 内存泄漏排查指南

一、先确认：是泄漏还是碎片/缓存膨胀

• RSS 涨 ≠ 泄漏：先区分“分配后未释放” vs “内存碎片/池增长”。
• 快速验证：cat /proc/<pid>/smaps 看 heap 段；用 malloc_trim(0) 触发后观察 RSS 是否回落——回落说明是 glibc 碎片，不回落更可能是真泄漏。

二、Profiler 接入方案（按侵入度选择）

方案A：Heaptrack（推荐，离线分析）

• 运行：heaptrack ./gameserver（或 heaptrack -p <pid> 附加运行中进程）。
• 跑几小时后停止，生成 .gz 文件，用 heaptrack_gui 打开。
• 重点看："Leaked" 视图 + 火焰图中调用栈最深的分配点。

方案B：Valgrind massif（低频峰值分析）

• valgrind --tool=massif --stacks=yes ./gameserver
• 用 ms_print 查看随时间的堆增长曲线，定位增长时段对应模块。

方案C：gperftools / jemalloc（生产友好，低开销）

• 编译时链接 tcmalloc，开启堆采样：环境变量设 HEAPPROFILE=/tmp/prof、HEAPPROFILE_ALLOCATION_INTERVAL（调低采样间隔）。
• pprof --pdf ./gameserver /tmp/prof.xxx 生成热点图。
• jemalloc 用户：je_malloc_conf 开 profiling，je_mallctl dump，用 jeprof 分析 diff。

三、辅助手段（进程已运行、不便重启时）

• 附加 gdb：gdb -p <pid>，多次执行 batch -ex "gcore" 对比 core 中的可疑对象。
• 直接看泄漏：gdb + _IO_list_all 不现实时，用 gcc 地址消毒器：测试环境用 -fsanitize=address 重新编译，跑 reproducer 抓泄漏栈（ASan 会直接打印泄漏调用栈）。

四、游戏服务器常见泄漏模块排查清单（按概率排序）

• 会话/连接对象：断线后 Player/Session 对象未从 map 移除（检查 std::unordered_map 中 UID 键的清理逻辑）。
• 定时器/回调未取消：对象析构但 timer 还持有 shared_ptr。
• 智能指针循环引用：shared_ptr 互相持有 → 改 weak_ptr。
• 日志/数据库缓冲区：异步队列只进不出（消费者阻塞后队列无限膨胀）。
• 快照/回放数据：战斗记录、录像缓存没有淘汰机制。
• Lua/脚本绑定：C++ 对象注册进 Lua 但没释放引用。

五、验证与收尾

• 定位后写最小 reproducer 验证；修复后用同工具复测 24h，RSS 曲线应平稳。
• 长期方案：接入 jemalloc/tcmalloc + 定期 heap profile 作为常驻监控。

建议第一步：生产环境直接上 heaptrack 附加运行 4~8 小时，Leaked 视图通常一眼就能看到泄漏调用栈所属模块。