Linux环境下如何定位进程匿名内存映射的产生来源

所有用户态匿名内存映射最终都来源于mmap(MAP_ANONYMOUS)系统调用、或是glibc等内存分配器通过brk扩展的堆区，基于这个底层逻辑可以通过以下几种方法定位来源：

• 首选valgrind的massif工具：直接运行valgrind --tool=massif 你的应用路径，运行结束后会生成massif.out.文件，用ms_print massif.out.<pid>即可查看所有堆内存分配的调用栈、分配大小和对应代码位置，所有malloc/calloc/realloc产生的匿名映射都会被完整追踪。
• 高负载场景可以使用gperftools的tcmalloc采样：编译时链接tcmalloc库，运行时加环境变量HEAPPROFILE=./heap_profile ./你的应用路径，生成的堆快照用pprof工具即可查看分配调用栈，性能损耗远低于valgrind，适合生产环境或大流量场景使用。

所有匿名内存映射本质最终都通过mmap系统调用生成（glibc的malloc分配超过默认128K的大块内存时也会直接走mmap），可以直接追踪进程的mmap调用匹配映射地址：

• 只需查看调用时机和参数用strace：运行strace -f -e trace=mmap,munmap,mremap -p <你的进程PID>，或者启动应用时直接加strace前缀，就能看到所有内存映射操作的参数、返回的地址范围，对比/proc/<pid>/smaps里的映射地址区间就能对应上生成时机。
• 需要查看调用栈定位代码位置用perf：执行perf record -g -e syscalls:sys_enter_mmap -p <你的进程PID>，运行一段时间后按Ctrl+C结束，用perf report即可查看每次mmap调用的完整用户态调用栈，直接定位到对应的代码逻辑。

如果是小于默认128K（MMAP_THRESHOLD）的小内存，glibc malloc会用brk扩展堆区来分配，属于同一块匿名映射里的子块，可通过glibc自带的调试接口定位：

• 在代码的怀疑点位插入malloc_stats()调用，运行时会在标准错误输出当前堆的总分配大小、空闲块占比等统计数据，对比操作前后的统计变化即可确认对应逻辑是否产生了内存分配。
• 也可以使用gdb的malloc调试扩展：启动gdb attach到进程后，执行set print pretty on，再执行call malloc_stats()或者dump binary memory ./heap_dump <堆起始地址> <堆结束地址>，配合gdb的符号解析可以定位具体分配的内容对应的代码逻辑。

如果怀疑是依赖的静态/动态库产生的映射，可以用LD_PRELOAD钩子拦截mmap和malloc调用：

• 自己实现一个简单的预加载库，重写malloc、mmap等内存分配相关函数，在函数内部打印调用栈或者写入日志，运行时用LD_PRELOAD=./your_hook.so ./你的应用路径，即可区分是自己的代码还是依赖库发起的内存分配请求。

内容的提问来源于stack exchange，提问作者Moon_Raven