应查看/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 闭包持有着。这种得靠代码审计+内存快照比对，没法一键定位。
