Linux 内存泄漏排查与修复方法

应查看/proc/[pid]/smaps中的rssanon和heap段增长，而非top的virt或res；rssanon反映堆外匿名页分配，heap对应malloc/sbrk堆内存，二者持续上升才表明真实泄漏。

怎么看进程实际用了多少内存（别信 top 的 VIRT）

top 里 VIRT 是虚拟地址空间大小，包含 mmap 的文件、共享库、未分配的 brk 空洞，跟真实泄漏几乎无关。RES 看似靠谱，但它含了共享内存和 mmap 的匿名页，泄漏初期变化也不明显。

真正该盯的是 /proc/[pid]/smaps 里的 RssAnon 和 Heap 段增长——前者是堆外匿名页（比如 mmap(MAP_ANONYMOUS)），后者是 sbrk 或 malloc 分配的堆内存。用 awk '/^RssAnon:|heap:/ {print}' /proc/1234/smaps 快速抓关键值。

• 定期采样比单次看更有效，写个 while 循环每 5 秒 dump 一次 RssAnon
• 注意 MMAP_AREA 区域也可能悄悄吃内存，尤其用 libcurl 或 openssl 的程序常在这里漏
• RES 突增但 RssAnon 不变？大概率是缓存或共享内存，不是泄漏

用 valgrind --leak-check=full 抓 C/C++ 堆泄漏，但得关掉 ASLR

valgrind 能定位到 malloc/new 后没 free/delete 的位置，但默认会因地址随机化（ASLR）让调用栈模糊，报错里只显示 ??:?。

运行前必须关 ASLR：echo 0 | sudo tee /proc/sys/kernel/randomize_va_space，跑完再开回来。否则即使泄漏存在，你也看不到源码行号。

• 加 --track-origins=yes 可查未初始化内存的传播路径，对野指针引发的间接泄漏很有用
• 不要用 -O2 编译被测程序，优化会让变量生命周期和行号错位，valgrind 报告失真
• 多线程程序要加 --tool=helgrind 单独查竞态，memcheck 默认不保证线程安全上下文

gdb 实时扒堆内存分布：从 malloc_stats() 到 heap 命令

线上服务不能停，又没法上 valgrind，就靠 gdb 连上去看实时堆状态。先 gdb -p [pid]，然后执行 call malloc_stats()，它会直接打印当前 malloc arena 的总分配、空闲块数、最大空闲块等——如果“total allocated”持续上涨，“fastbins”和“unsorted bins”却没清空，基本就是泄漏了。

更进一步，用 heap 命令（需加载 libc 的 python 脚本，如 gef 或 pwndbg）可列出所有 chunk 地址、大小、是否 in-use。重点扫那些 size 大且 in-use 为 True、但无对应变量名的 chunk。

• malloc_stats() 输出里 “max system bytes” 增长快于 “total allocated”，说明 malloc 在向内核要新页，泄漏已较严重
• 若看到大量小尺寸（如 32/64 字节）in-use chunk，可能是对象池没回收，或 std::String 的小字符串优化（SSO）失效导致堆分配
• 注意 gdb 连进程会暂停它，别在高并发请求时长连，建议选低峰期或用 gcore 先打个快照再离线分析

Go 程序泄漏难发现？重点查 runtime.ReadMemStats 和 goroutine 持有堆对象

Go 的 GC 会让 top 看不到内存涨，但 ReadMemStats 的 Alloc 和 HeapAlloc 字段如果随时间单调上升，且 NextGC 总也触发不了，就是典型泄漏。

更隐蔽的是 goroutine 持有大对象不释放，比如一个长期存活的 goroutine 把 []byte 存在 map 里，或用 http.Client 的 Transport 缓存了连接池 + TLS 状态。这类泄漏不会出现在 pprof heap 的 top 函数里，因为对象被根对象（goroutine 栈/全局变量）强引用着。

• 用 go tool pprof -http=:8080 http://localhost:6060/debug/pprof/heap 查 live objects，按 “flat” 排序，重点关注非 runtime. 开头的包名
• 检查所有 for { select { ... } } 循环，确认 channel 接收后有没有把收到的数据及时处理或丢弃；没消费的 channel 会拖住发送方分配的内存
• sync.Pool 不是万能的，Put 进去的对象如果被外部变量意外持有，Pool 就永远清不掉它

泄漏最麻烦的地方不在工具不会用，而在于它常常藏在“逻辑合理”的代码里：比如日志模块缓存了请求体用于重试，但重试失败后忘了删；或者配置热更新时，旧配置对象被新 handler 闭包持有着。这种得靠代码审计+内存快照比对，没法一键定位。