最实用方法是cat /proc/[pid]/maps | grep "\[heap\]"定位堆段起止地址，再用printf计算字节数；vmdata字段粗略反映数据段（含堆），但jvm等场景不适用；pmap -x [pid]的anon列可精准识别堆外匿名内存泄漏。
怎么看进程的堆内存到底占了多少
Linux 进程的“堆内存”不是单一数值，/proc/[pid]/statm 和 /proc/[pid]/status 里没有直接叫“heap”的字段。真正反映堆使用情况的，是匿名映射中由 sbrk 或 brk 扩展的那一块——也就是 Heap 段，它在 /proc/[pid]/maps 中表现为起始地址接近 [heap] 标记、权限含 rw、且不关联任何文件的一段。
最实用的办法是：
- 用
cat /proc/[pid]/maps | grep "\[heap\]"定位堆段起止地址（如01234000-01256000 rw-p ... [heap]），再用printf "%d\n" $((0x01256000 - 0x01234000))算出字节数（约 139264 字节） - 更粗略但快：看
cat /proc/[pid]/status | grep -E "VmData|VmStk|VmExe"，其中VmData是数据段（含堆），对纯 C 程序较准；JVM 进程则意义不大，因为堆外内存走的是mmap匿名映射 - 注意：
VmRSS是全部驻留内存（含堆、栈、共享库、DirectByteBuffer 等），不能等同于堆大小
gdb 能不能直接看到 malloc 分配点
可以，但必须满足两个前提：程序用 -g 编译、且没开 -O2 以上激进优化（否则变量被内联或寄存器化，堆栈信息失真）。
常用操作链：
- 启动调试：
gdb -p [pid]或gdb ./a.out core - 监控分配：
(gdb) catch syscall brk或(gdb) catch syscall mmap，触发后用info registers看rdi/rsi（size 参数） - 回溯调用：
(gdb) bt查当前堆栈；若想捕获每次malloc，需设断点：break __libc_malloc（glibc 实现），再用commands; bt; continue; end - 别依赖
malloc_stats()：它只打印 arena 汇总，不带调用上下文；且多线程下输出可能错乱
为什么 pmap 比 top 更适合定位堆外泄漏
因为 top 的 RES 是进程所有物理内存之和，而 pmap -x [pid] 能按页、按映射类型拆解——你一眼就能看出哪类匿名映射在疯长。
重点关注这几列：
-
ANON列非零且持续增大 → 典型堆外泄漏（如DirectByteBuffer、mmap(MAP_ANONYMOUS)、C++new） -
mapped列对应文件映射，通常稳定；若它涨了，检查是否反复mmap同一文件却没munmap -
total行末尾的ANON总和，就是当前进程所有匿名内存占用，和RES差值大，说明大量内存被缓存或交换了
执行 pmap -x [pid] | tail -n 1 可快速抓总览；配合 watch -n 5 'pmap -x [pid] | tail -n 1' 动态观察变化。
gdb + pmap 组合排查时最容易忽略的细节
真实泄漏往往藏在“合法但失控”的行为里，比如日志缓冲区不断 realloc、连接池未 close 导致 mmap 积累、甚至 pthread_create 后线程栈未回收。
务必确认以下三点：
- 目标进程是否启用了
LD_PRELOAD替换 malloc（如 tcmalloc、jemalloc）？此时__libc_malloc断点无效，得查对应库的符号，例如break tc_malloc -
pmap输出中的地址范围是否与gdb里info proc mappings一致？不一致说明进程内存已重映射，需重新 attach - 用
gdb查到可疑指针后，别只看print *ptr；要结合info proc mappings确认该地址落在哪个映射段，再反查/proc/[pid]/maps判断它是堆、栈还是 mmap 区
堆外泄漏没有 GC 帮你兜底，每一块漏掉的 mmap 都会实实在在吃掉物理内存。工具只是眼睛，关键还是理解进程地址空间里谁有权申请、谁负责释放。
