做C/C服务端的人几乎都被“内存缓慢上涨”这个幽灵折磨过。我最开始遇到线上进程RSS不断爬升、重启后恢复时第一反应是上valgrind结果程序跑了十几分钟还没跑完一轮正常业务换ASan重新编译链接时间翻倍不说还因为全局替换new/delete导致一堆第三方库冲突。后来偶然在预发环境用jemalloc跑了一趟从编译到拿到PDF报告前后不到5分钟直接定位到一个配置模块每次刷新都泄漏一块结构体。这篇文章就把这套流程完整拆开讲清楚怎么让jemalloc变成泄漏检测器、怎么配置采样参数、怎么生成一份能直接扔给团队的PDF报告。1. 为什么把“内存分配器”当“泄漏检测器”用jemalloc的prof机制1.1 valgrind、ASan与jemalloc的适用边界先给结论三种手段不是替代关系而是不同场景下的取舍。valgrind的memcheck走的是二进制插桩每条指令都会被翻译执行程序运行速度普遍掉一个数量级内存开销也大我实测过一个中等规模的网关程序正常处理1000个请求需要2秒valgrind下跑了近40秒还没完成在预发环境凑合能用生产环境根本挂不起。ASan是编译期插桩性能和内存开销比valgrind小但要求你重新编译所有目标文件和依赖库而且ASan会拦截所有malloc/free调用有些用dlopen动态加载、自己实现内存池的项目和ASan的runtime冲突起来排查成本也不低。jemalloc的思路完全不同。它本质上就是malloc的替代实现在提供内存分配功能的同时内置了一套基于采样的profiling子系统。你不需要重编译业务代码也不需要改动任何源码只要让程序加载libjemalloc再通过环境变量把prof开关打开jemalloc就会在每次内存分配时随机做采样记录当前调用栈、分配字节数、分配次数。程序跑完后这些采样数据可以导成heap profile文件再交给jeprof工具产出可读性极强的PDF调用图。这个机制最值钱的地方是低侵入、低开销。因为prof功能走的是采样不是全量记录线上服务长时间挂着也不至于被拖垮预发环境开起来基本无感。这正好补上了valgrind和ASan在“生产环境/大规模程序”上的短板。1.2 jemalloc能检测什么、不能检测什么先泼一盆冷水jemalloc的检测能力集中在“堆内存泄漏”和“内存占用异常增长”这两个维度它测不了越界写、野指针、double free这类问题——那些还是得靠ASan或valgrind。它能做的有两件很实际的事程序退出时如果开了prof_leak:truejemalloc会对比启动以来所有采样到的活跃分配找出那些“分配了但从未释放”的对象按调用栈聚合并输出摘要滚动抓取热点通过prof_prefix配置jemalloc可以每隔一段时间或每分配指定字节数就自动dump一次当前堆快照。拿两个时间点的快照做对比就能看出哪条调用路径的内存在持续增长。我实际用得最多的是第二种能力。很多线上泄漏不是“分配了就不释放”而是“释放速度赶不上分配速度”直接看退出时的leak摘要往往看不出问题但对比两个时间点的heap profile增长热点马上浮出水面。提示如果你的问题是越界写导致堆结构被破坏jemalloc帮不上忙。它的定位是“哪里分配了不该分配的内存”不是“谁写坏了内存”。先分清楚问题类型再选工具能省不少时间。2. 从源码编译带profiling的jemallocconfigure参数与常见踩坑2.1 为什么必须带--enable-prof很多Linux发行版默认装的jemalloc或者某些软件内嵌的jemalloc编译时并没有打开prof功能。你可以通过jemalloc-config --config检查当前版本支持哪些编译选项jemalloc-config --config输出里如果没有--enable-prof那你用LD_PRELOAD把这套库塞进去MALLOC_CONF里配prof:true也不会生效甚至可能被静默忽略——因为参数解析时prof开关根本没编译进库jemalloc会跳过这个未知选项。所以稳妥做法是自己从源码编译一份专门用于排查的版本。jemalloc的源码在GitHub官方仓库有release不需要依赖一堆第三方库configure阶段也比较传统稳健wget https://github.com/jemalloc/jemalloc/releases/download/5.3.0/jemalloc-5.3.0.tar.bz2 tar xjf jemalloc-5.3.0.tar.bz2 cd jemalloc-5.3.0 ./configure --enable-prof --enable-stats make -j$(nproc) sudo make install--enable-stats顺手打开统计功能后面用mallctl接口读取一些运行时指标时用得上。安装完成后默认会装到/usr/local/lib/libjemalloc.so可执行文件jeprof在/usr/local/bin。2.2 如何验证prof已经生效验证最直接的办法是配置一个带prof的环境变量跑个最小C程序。如果prof没生效jemalloc会直接忽略所有prof相关的MALLOC_CONF项程序不会报错但也不会生成heap文件。这个“静默失败”太坑了我一开始就被坑过一次以为程序有问题折腾半天发现是系统自带的jemalloc版本没编prof。推荐一上来就用这个检查动作MALLOC_CONFprof:true,lg_prof_sample:0,prof_prefix:/tmp/proftest LD_PRELOAD/usr/local/lib/libjemalloc.so ./any_small_program echo $? ls /tmp/proftest.*如果/tmp下出现了proftest.pid.*.heap文件说明prof链路是通的。这里lg_prof_sample:0表示每次分配都采样测试时最直观后面正式跑业务时再按需调大。2.3 Docker镜像与静态链接场景的坑还有两种常见场景要单独提一下。第一种是Docker容器里跑的程序如果基础镜像里的jemalloc版本老旧或没开prof你宿主机上装的新版通过LD_PRELOAD不一定能灌进容器正确做法是把这个步骤写进Dockerfile在镜像内编译或安装带prof的jemalloc。第二种是业务二进制用了全静态链接或者编译时强制-Wl,-Bstatic把jemalloc链死进可执行文件这时候LD_PRELOAD注入的动态库不会生效你需要在编译命令里显式链接你的prof版本jemalloc链接前确认ldd的目标是/usr/local/lib/libjemalloc.so。3. 让目标程序“挂上钩子”静态链接、LD_PRELOAD与MALLOC_CONF配置3.1 两种加载方式怎么选接入jemalloc有两种方式静态链接和运行时注入。静态链接是最可控的。编译时加-ljemalloc程序从第一条malloc开始就由jemalloc接管gcc -g -O0 -fno-omit-frame-pointer -o leak_demo leak_demo.c -I/usr/local/include -L/usr/local/lib -ljemalloc注意这里强制加了-fno-omit-frame-pointer目的是让jemalloc采样时能拿到完整调用栈。如果编译时开了-O2优化编译器可能省略frame pointer采样到的调用栈会缺层甚至只显示一个函数名定位价值大打折扣。排查泄漏的二进制建议统一用-O0或至少保留frame pointer。运行时注入则适合“不想重新链接或源码都找不全”的历史项目LD_PRELOAD/usr/local/lib/libjemalloc.so ./leak_demo用ldd ./leak_demo确认一下libjemalloc确实被加载。如果程序用的是动态加载外部模块、再回调自身逻辑的架构LD_PRELOAD是个很省事的手段不需要动构建脚本。3.2 MALLOC_CONF每个参数都什么意思MALLOC_CONF是jemalloc的运行时配置入口用逗号分隔多个key:value项。排查泄漏最常用的一套配置如下export MALLOC_CONFprof:true,lg_prof_sample:20,prof_leak:true,lg_prof_interval:30,prof_prefix:/tmp/jeprof逐个拆开解释prof:true总开关打开profiling子系统的采样记录lg_prof_sample:20采样间隔的log2值20表示每分配2^20 1,048,576字节约1MB采样一次。这个值越采样越密集结果越接近真实分配分布但性能开销也越高prof_leak:true程序退出正常return或exit时输出未被释放内存的leak summary如果没有这项jemalloc默认会在退出时丢弃所有采样信息lg_prof_interval:30每累积分配2^30字节约1GB自动dump一次heap文件用于观察内存增长趋势。不需要趋势分析时可以不加prof_prefix:/tmp/jeprof指定dump文件的前缀生成的heap文件会形如/tmp/jeprof.pid.随机数.heap。3.3 自动dump与信号触发dump除了按字节数自动dump和退出时dumpjemalloc还支持用信号触发即时dump。这个在线上救过我好几次命程序跑着跑着内存涨起来了你又不想等它跑完或者重启直接kill -USR2 pid只要编译时开了profjemalloc注册的SIGUSR2处理器就会立刻生成一份当前堆快照。连续触发两次间隔一两分钟就能拿两份快照做增量对比看出哪个调用路径的内存在持续增长。如果你想把触发时机控制在程序内部比如在某个业务流程结束后主动记录可以用mallctl接口#include jemalloc/jemalloc.h void dump_heap(const char *prefix) { mallctl(prof.dump, NULL, NULL, prefix, sizeof(prefix)); }mallctl是jemalloc的控制面APIprof.dump是它的一个可写节点传入字符串指针作为文件前缀调用后异步写heap文件。这个接口配合定时器或者管理后台接口能做到“按需采样”。4. 程序跑完怎么导出报告jeprof生成PDF的完整链路4.1 jeprof其实是gperftools pprof的亲戚jemalloc安装后自带一个叫jeprof的工具它的命令行风格和gperftools的pprof很接近核心作用是把heap文件解析成人类能看懂的形式。heap文件本身是一个文本协议文件记录了每个采样调用栈的分配字节数、对象数和调用栈符号理论上你可以自己写脚本解析但那纯属重复造轮子。jeprof支持多种输出格式--text在终端直接打印调用栈排行适合快速瞄一眼--dot输出graphviz点图--svg输出矢量图--pdf输出我们目标中的PDF报告。我第一次用的时候只装了jemalloc没装graphvizjeprof报了个dot命令找不到的错误把graphviz装上就好# Ubuntu/Debian sudo apt-get install graphviz # CentOS/RHEL sudo yum install graphvizgraphviz提供的是dot命令jeprof生成PDF实际是先把内存分配树转换成dot格式文本再调用dot把文本渲染成PDF。所以graphviz缺失--pdf必然失败。4.2 一条命令出PDF完整流程三句话就能说清写一个带-g和-fno-omit-frame-pointer的二进制用带prof:true,prof_leak:true的MALLOC_CONF运行它拿到heap文件用jeprof生成PDF。具体命令长这样# 运行目标程序生成heap文件 LD_PRELOAD/usr/local/lib/libjemalloc.so \ MALLOC_CONFprof:true,lg_prof_sample:0,prof_leak:true,prof_prefix:/tmp/jeprof \ ./leak_demo # 生成泄漏报告PDF--leak表示重点关注未释放对象 jeprof --leak --pdf ./leak_demo /tmp/jeprof.*.heap leak.pdf--leak这个参数值得单独强调它会过滤heap文件里的记录只保留“到dump时刻仍然活跃”的分配。对于程序退出时的终态泄漏检测--leak几乎是必加项如果只是看全局内存分布热点去掉--leak直接看所有采样分配。4.3 报告太乱怎么聚焦--focus、--nodefraction、--edgefraction程序一旦功能复杂PDF调用图可能密密麻麻几百个节点根本看不出重点。jeprof提供了几个聚焦参数我用得最多的是jeprof --leak --pdf --nodefraction0.01 --edgefraction0.01 \ --focusload_config ./leak_demo /tmp/jeprof.*.heap leak.pdf--nodefraction0.01忽略那些占比小于1%的节点过滤噪点--edgefraction同理过滤调用边--focusload_config只看与某个函数相关的子图适合确定可疑函数后做定向分析。实际经验是先不加--focus看全貌锁定最粗的那个调用路径再用--focus钻进去看内部细节。这样比一步到位更不容易漏信息。如果只想快速在终端确认一下“最大分配点是谁”可以先跑jeprof --leak --text ./leak_demo /tmp/jeprof.*.heap | head -40文本模式下前几行就会列出占用最高的调用栈PDF只是把这份数据渲染成了更好分享的形态。5. 一个内存泄漏的完整定位过程从怀疑到PDF报告出图5.1 复现用的泄漏程序为了让你能完整复现走一遍流程我准备了一个经典的“配置模块反复加载导致内存增长”的例子。这类问题在真实项目中太常见了某个配置对象每次刷新都分配新内存但旧的没有释放#include stdio.h #include stdlib.h #include string.h char *load_config(void) { char *config (char *)malloc(4096); if (config NULL) { return NULL; } snprintf(config, 4096, version1.0;modeprod;cache_size%d;, 4096); return config; } int main(void) { for (int i 0; i 10000; i) { char *config load_config(); if (config) { // 模拟使用配置后忘记释放 // free(config); } if (i % 1000 0) { printf(iteration %d\n, i); } } return 0; }循环10000次每次泄漏4096字节一共泄漏约40MB。这个量级在真实线上服务里不算大但非常典型因为它分散在一次次小分配里靠监控RSS根本看不出是哪一行。5.2 编译、运行、出图三步走编译时保留符号和frame pointergcc -g -O0 -fno-omit-frame-pointer -o leak_demo leak_demo.c注意我这里没有显式加-ljemalloc而是选择用LD_PRELOAD注入。这样能演示“不动构建系统也能排查”的场景。运行LD_PRELOAD/usr/local/lib/libjemalloc.so \ MALLOC_CONFprof:true,lg_prof_sample:0,prof_leak:true,prof_prefix:/tmp/jeprof_demo \ ./leak_demo程序运行结束后/tmp下会出现类似jeprof_demo.12345.xxx.heap的文件。同时stderr会有leak摘要输出大致长这样Leak summary: 40960000 bytes in 10000 objects, 10000 sampled这行字其实已经告诉你有10000个对象共40960000字节被泄漏了。但摘要只告诉你有泄漏不告诉你在哪接下来的PDF才是指路地图。生成PDFjeprof --leak --pdf ./leak_demo /tmp/jeprof_demo.*.heap /tmp/leak_demo_report.pdf用ls -lh /tmp/leak_demo_report.pdf看一下文件存在且大于0就说明出图成功。5.3 PDF报告怎么看打开PDF你会看到一张从main开始、向下舒展的调用树。节点是函数调用栈节点内部标着该函数及其子调用链上累计的泄漏字节数和对象数节点之间的边表示调用关系边上也标注了字节数。优先看两条信息最粗的那条路径通常是从根节点到叶子节点路径上累计值最大的那条就是泄漏的“主航道”叶子节点如果某个叶子函数本身累计分配了大量字节且没有向下的子调用说明泄漏发生在该函数直接分配的堆内存上。在示例里你会在报告里看到load_config节点的累计值接近40MB箭头指向malloc数量10000次。这时候代码审查范围就缩小到了load_config这一行分配了4KB但没释放。提示如果PDF里函数名显示为0x7f...之类的十六进制地址说明二进制被strip过符号表。解决办法是重新编一个带-g的版本或者用objcopy --only-keep-debug把符号单独提出来配合jeprof --symbols手动指定调试文件。6. 采样率与报告解读控制开销的同时保证定位精度6.1 lg_prof_sample该怎么选前面演示为了追求100%准确用了lg_prof_sample:0也就是每次分配都采样。在小程序或短时间内测试没问题但如果是长跑的服务会产生两个副作用性能开销大、heap文件体积膨胀。每次分配都记录几十分钟就能生成几百MB甚至几个GB的heap文件解析起来也慢。生产或预发环境推荐从lg_prof_sample:20起步也就是约1MB采样一次。jemalloc的采样是伯努利分布式的样本量足够大时统计结果能比较接近真实分配分布对于定位某条调用栈持续增长的问题这个精度完全够用。如果跑了半小时报告太稀、看不出热点再把lg_prof_sample调到18或16相当于更密集地采样。我的经验是先用20跑如果报告top10节点分布明显且稳定就不用动如果top节点稀疏、看起来像是随机抖动说明采样点太少逐步调低。一定要避免一上来就lg_prof_sample:0跑全量大流量业务那会让采样本身成为瓶颈。6.2 两份快照对比才是增长型泄漏的正确姿势很多线上泄漏不是“分配了就永久拿在手里”而是“新分配的速度超过释放速度”比如请求处理中创建临时对象、处理完却少释放了一部分。这类泄漏程序退出时的--leak摘要往往不明显因为很多分配最终其实被释放了只是释放得不干净。正确做法是利用自动或信号触发的dump在运行中抓两份快照# 运行中先dump一份 kill -USR2 pid sleep 120 kill -USR2 pid然后用jeprof对比两份文件jeprof --pdf --base/tmp/jeprof.前一个pid.前一个随机数.heap \ ./leak_demo /tmp/jeprof.后一个pid.后一个随机数.heap diff.pdf--base表示以前一份快照为基线报告里显示的是“从基线到当前这份”之间的净增长。哪条调用路径的字节数在增长、增长了多少一目了然。对于那种“每次请求都涨一点但退出前又释放大半”的场景这种方式比盯着终态leak摘要可靠得多。6.3 网上还有个Win10 C盘清理的场景这里顺带提醒那个热搜词列表里混了不少无关内容type c、c盘清理之类的和本文主题不搭。我只想提醒一点做内存检测时注意给prof_prefix所在的磁盘留够空间特别是lg_prof_sample调小以后heap文件膨胀速度比你想象得快。别等到磁盘满了才发现那会儿进程已经被写挂了。6.4 一个亲身教训别忽略“信号处理函数”里的malloc有一次我排一个服务端程序线程A持有某个锁线程B的代码路径里包含一个内存泄漏点。jemalloc报告成功定位到了泄漏函数但那个函数明明不是业务流程里最常见的调用甚至文档里都说不推荐在生产调用。后来仔细读代码才发现它被注册成了定时任务的回调每次老定时任务触发时都会执行一次。这个案例给我的教训是jeprof能告诉你“泄漏发生在哪”但“为什么这个函数会被反复调用”仍然需要你熟读业务代码。工具帮你缩小范围真正下结论的还得是人。7. 一点个人使用体会这套方案我现在基本固化成新服务上线前的必做检查了。流程很简单编译一个带--enable-prof的jemalloc备用跑一次业务回归用lg_prof_sample:20挂半小时中间用SIGUSR2抓两次快照对比生成PDF人工确认top10调用路径没有异常增长。整个流程大概就几分钟但它能发现的潜在问题比上线后被监控报警逼着半夜起来查要幸福得多。另外jemalloc的prof功能其实不止能查泄漏。它还可以用来做内存分配热点分析——比如某个模块分配次数特别频繁、导致锁竞争严重报告里同样看得出来。分配次数多但总量小的节点往往提示你的代码在做不合理的重复分配这时候缓存复用反而是更好的优化方向。把这些场景都纳入日常性能巡检jemalloc就不只是一个“应急排查工具”了。 
长河君 · 2026/9/18 11:04:01 · 阅读 1.2k 用jemalloc当泄漏检测器：C++服务内存缓慢上涨的定位指南
做C/C服务端的人几乎都被“内存缓慢上涨”这个幽灵折磨过。我最开始遇到线上进程RSS不断爬升、重启后恢复时第一反应是上valgrind结果程序跑了十几分钟还没跑完一轮正常业务换ASan重新编译链接时间翻倍不说还因为全局替换new/delete导致一堆第三方库冲突。后来偶然在预发环境用jemalloc跑了一趟从编译到拿到PDF报告前后不到5分钟直接定位到一个配置模块每次刷新都泄漏一块结构体。这篇文章就把这套流程完整拆开讲清楚怎么让jemalloc变成泄漏检测器、怎么配置采样参数、怎么生成一份能直接扔给团队的PDF报告。1. 为什么把“内存分配器”当“泄漏检测器”用jemalloc的prof机制1.1 valgrind、ASan与jemalloc的适用边界先给结论三种手段不是替代关系而是不同场景下的取舍。valgrind的memcheck走的是二进制插桩每条指令都会被翻译执行程序运行速度普遍掉一个数量级内存开销也大我实测过一个中等规模的网关程序正常处理1000个请求需要2秒valgrind下跑了近40秒还没完成在预发环境凑合能用生产环境根本挂不起。ASan是编译期插桩性能和内存开销比valgrind小但要求你重新编译所有目标文件和依赖库而且ASan会拦截所有malloc/free调用有些用dlopen动态加载、自己实现内存池的项目和ASan的runtime冲突起来排查成本也不低。jemalloc的思路完全不同。它本质上就是malloc的替代实现在提供内存分配功能的同时内置了一套基于采样的profiling子系统。你不需要重编译业务代码也不需要改动任何源码只要让程序加载libjemalloc再通过环境变量把prof开关打开jemalloc就会在每次内存分配时随机做采样记录当前调用栈、分配字节数、分配次数。程序跑完后这些采样数据可以导成heap profile文件再交给jeprof工具产出可读性极强的PDF调用图。这个机制最值钱的地方是低侵入、低开销。因为prof功能走的是采样不是全量记录线上服务长时间挂着也不至于被拖垮预发环境开起来基本无感。这正好补上了valgrind和ASan在“生产环境/大规模程序”上的短板。1.2 jemalloc能检测什么、不能检测什么先泼一盆冷水jemalloc的检测能力集中在“堆内存泄漏”和“内存占用异常增长”这两个维度它测不了越界写、野指针、double free这类问题——那些还是得靠ASan或valgrind。它能做的有两件很实际的事程序退出时如果开了prof_leak:truejemalloc会对比启动以来所有采样到的活跃分配找出那些“分配了但从未释放”的对象按调用栈聚合并输出摘要滚动抓取热点通过prof_prefix配置jemalloc可以每隔一段时间或每分配指定字节数就自动dump一次当前堆快照。拿两个时间点的快照做对比就能看出哪条调用路径的内存在持续增长。我实际用得最多的是第二种能力。很多线上泄漏不是“分配了就不释放”而是“释放速度赶不上分配速度”直接看退出时的leak摘要往往看不出问题但对比两个时间点的heap profile增长热点马上浮出水面。提示如果你的问题是越界写导致堆结构被破坏jemalloc帮不上忙。它的定位是“哪里分配了不该分配的内存”不是“谁写坏了内存”。先分清楚问题类型再选工具能省不少时间。2. 从源码编译带profiling的jemallocconfigure参数与常见踩坑2.1 为什么必须带--enable-prof很多Linux发行版默认装的jemalloc或者某些软件内嵌的jemalloc编译时并没有打开prof功能。你可以通过jemalloc-config --config检查当前版本支持哪些编译选项jemalloc-config --config输出里如果没有--enable-prof那你用LD_PRELOAD把这套库塞进去MALLOC_CONF里配prof:true也不会生效甚至可能被静默忽略——因为参数解析时prof开关根本没编译进库jemalloc会跳过这个未知选项。所以稳妥做法是自己从源码编译一份专门用于排查的版本。jemalloc的源码在GitHub官方仓库有release不需要依赖一堆第三方库configure阶段也比较传统稳健wget https://github.com/jemalloc/jemalloc/releases/download/5.3.0/jemalloc-5.3.0.tar.bz2 tar xjf jemalloc-5.3.0.tar.bz2 cd jemalloc-5.3.0 ./configure --enable-prof --enable-stats make -j$(nproc) sudo make install--enable-stats顺手打开统计功能后面用mallctl接口读取一些运行时指标时用得上。安装完成后默认会装到/usr/local/lib/libjemalloc.so可执行文件jeprof在/usr/local/bin。2.2 如何验证prof已经生效验证最直接的办法是配置一个带prof的环境变量跑个最小C程序。如果prof没生效jemalloc会直接忽略所有prof相关的MALLOC_CONF项程序不会报错但也不会生成heap文件。这个“静默失败”太坑了我一开始就被坑过一次以为程序有问题折腾半天发现是系统自带的jemalloc版本没编prof。推荐一上来就用这个检查动作MALLOC_CONFprof:true,lg_prof_sample:0,prof_prefix:/tmp/proftest LD_PRELOAD/usr/local/lib/libjemalloc.so ./any_small_program echo $? ls /tmp/proftest.*如果/tmp下出现了proftest.pid.*.heap文件说明prof链路是通的。这里lg_prof_sample:0表示每次分配都采样测试时最直观后面正式跑业务时再按需调大。2.3 Docker镜像与静态链接场景的坑还有两种常见场景要单独提一下。第一种是Docker容器里跑的程序如果基础镜像里的jemalloc版本老旧或没开prof你宿主机上装的新版通过LD_PRELOAD不一定能灌进容器正确做法是把这个步骤写进Dockerfile在镜像内编译或安装带prof的jemalloc。第二种是业务二进制用了全静态链接或者编译时强制-Wl,-Bstatic把jemalloc链死进可执行文件这时候LD_PRELOAD注入的动态库不会生效你需要在编译命令里显式链接你的prof版本jemalloc链接前确认ldd的目标是/usr/local/lib/libjemalloc.so。3. 让目标程序“挂上钩子”静态链接、LD_PRELOAD与MALLOC_CONF配置3.1 两种加载方式怎么选接入jemalloc有两种方式静态链接和运行时注入。静态链接是最可控的。编译时加-ljemalloc程序从第一条malloc开始就由jemalloc接管gcc -g -O0 -fno-omit-frame-pointer -o leak_demo leak_demo.c -I/usr/local/include -L/usr/local/lib -ljemalloc注意这里强制加了-fno-omit-frame-pointer目的是让jemalloc采样时能拿到完整调用栈。如果编译时开了-O2优化编译器可能省略frame pointer采样到的调用栈会缺层甚至只显示一个函数名定位价值大打折扣。排查泄漏的二进制建议统一用-O0或至少保留frame pointer。运行时注入则适合“不想重新链接或源码都找不全”的历史项目LD_PRELOAD/usr/local/lib/libjemalloc.so ./leak_demo用ldd ./leak_demo确认一下libjemalloc确实被加载。如果程序用的是动态加载外部模块、再回调自身逻辑的架构LD_PRELOAD是个很省事的手段不需要动构建脚本。3.2 MALLOC_CONF每个参数都什么意思MALLOC_CONF是jemalloc的运行时配置入口用逗号分隔多个key:value项。排查泄漏最常用的一套配置如下export MALLOC_CONFprof:true,lg_prof_sample:20,prof_leak:true,lg_prof_interval:30,prof_prefix:/tmp/jeprof逐个拆开解释prof:true总开关打开profiling子系统的采样记录lg_prof_sample:20采样间隔的log2值20表示每分配2^20 1,048,576字节约1MB采样一次。这个值越采样越密集结果越接近真实分配分布但性能开销也越高prof_leak:true程序退出正常return或exit时输出未被释放内存的leak summary如果没有这项jemalloc默认会在退出时丢弃所有采样信息lg_prof_interval:30每累积分配2^30字节约1GB自动dump一次heap文件用于观察内存增长趋势。不需要趋势分析时可以不加prof_prefix:/tmp/jeprof指定dump文件的前缀生成的heap文件会形如/tmp/jeprof.pid.随机数.heap。3.3 自动dump与信号触发dump除了按字节数自动dump和退出时dumpjemalloc还支持用信号触发即时dump。这个在线上救过我好几次命程序跑着跑着内存涨起来了你又不想等它跑完或者重启直接kill -USR2 pid只要编译时开了profjemalloc注册的SIGUSR2处理器就会立刻生成一份当前堆快照。连续触发两次间隔一两分钟就能拿两份快照做增量对比看出哪个调用路径的内存在持续增长。如果你想把触发时机控制在程序内部比如在某个业务流程结束后主动记录可以用mallctl接口#include jemalloc/jemalloc.h void dump_heap(const char *prefix) { mallctl(prof.dump, NULL, NULL, prefix, sizeof(prefix)); }mallctl是jemalloc的控制面APIprof.dump是它的一个可写节点传入字符串指针作为文件前缀调用后异步写heap文件。这个接口配合定时器或者管理后台接口能做到“按需采样”。4. 程序跑完怎么导出报告jeprof生成PDF的完整链路4.1 jeprof其实是gperftools pprof的亲戚jemalloc安装后自带一个叫jeprof的工具它的命令行风格和gperftools的pprof很接近核心作用是把heap文件解析成人类能看懂的形式。heap文件本身是一个文本协议文件记录了每个采样调用栈的分配字节数、对象数和调用栈符号理论上你可以自己写脚本解析但那纯属重复造轮子。jeprof支持多种输出格式--text在终端直接打印调用栈排行适合快速瞄一眼--dot输出graphviz点图--svg输出矢量图--pdf输出我们目标中的PDF报告。我第一次用的时候只装了jemalloc没装graphvizjeprof报了个dot命令找不到的错误把graphviz装上就好# Ubuntu/Debian sudo apt-get install graphviz # CentOS/RHEL sudo yum install graphvizgraphviz提供的是dot命令jeprof生成PDF实际是先把内存分配树转换成dot格式文本再调用dot把文本渲染成PDF。所以graphviz缺失--pdf必然失败。4.2 一条命令出PDF完整流程三句话就能说清写一个带-g和-fno-omit-frame-pointer的二进制用带prof:true,prof_leak:true的MALLOC_CONF运行它拿到heap文件用jeprof生成PDF。具体命令长这样# 运行目标程序生成heap文件 LD_PRELOAD/usr/local/lib/libjemalloc.so \ MALLOC_CONFprof:true,lg_prof_sample:0,prof_leak:true,prof_prefix:/tmp/jeprof \ ./leak_demo # 生成泄漏报告PDF--leak表示重点关注未释放对象 jeprof --leak --pdf ./leak_demo /tmp/jeprof.*.heap leak.pdf--leak这个参数值得单独强调它会过滤heap文件里的记录只保留“到dump时刻仍然活跃”的分配。对于程序退出时的终态泄漏检测--leak几乎是必加项如果只是看全局内存分布热点去掉--leak直接看所有采样分配。4.3 报告太乱怎么聚焦--focus、--nodefraction、--edgefraction程序一旦功能复杂PDF调用图可能密密麻麻几百个节点根本看不出重点。jeprof提供了几个聚焦参数我用得最多的是jeprof --leak --pdf --nodefraction0.01 --edgefraction0.01 \ --focusload_config ./leak_demo /tmp/jeprof.*.heap leak.pdf--nodefraction0.01忽略那些占比小于1%的节点过滤噪点--edgefraction同理过滤调用边--focusload_config只看与某个函数相关的子图适合确定可疑函数后做定向分析。实际经验是先不加--focus看全貌锁定最粗的那个调用路径再用--focus钻进去看内部细节。这样比一步到位更不容易漏信息。如果只想快速在终端确认一下“最大分配点是谁”可以先跑jeprof --leak --text ./leak_demo /tmp/jeprof.*.heap | head -40文本模式下前几行就会列出占用最高的调用栈PDF只是把这份数据渲染成了更好分享的形态。5. 一个内存泄漏的完整定位过程从怀疑到PDF报告出图5.1 复现用的泄漏程序为了让你能完整复现走一遍流程我准备了一个经典的“配置模块反复加载导致内存增长”的例子。这类问题在真实项目中太常见了某个配置对象每次刷新都分配新内存但旧的没有释放#include stdio.h #include stdlib.h #include string.h char *load_config(void) { char *config (char *)malloc(4096); if (config NULL) { return NULL; } snprintf(config, 4096, version1.0;modeprod;cache_size%d;, 4096); return config; } int main(void) { for (int i 0; i 10000; i) { char *config load_config(); if (config) { // 模拟使用配置后忘记释放 // free(config); } if (i % 1000 0) { printf(iteration %d\n, i); } } return 0; }循环10000次每次泄漏4096字节一共泄漏约40MB。这个量级在真实线上服务里不算大但非常典型因为它分散在一次次小分配里靠监控RSS根本看不出是哪一行。5.2 编译、运行、出图三步走编译时保留符号和frame pointergcc -g -O0 -fno-omit-frame-pointer -o leak_demo leak_demo.c注意我这里没有显式加-ljemalloc而是选择用LD_PRELOAD注入。这样能演示“不动构建系统也能排查”的场景。运行LD_PRELOAD/usr/local/lib/libjemalloc.so \ MALLOC_CONFprof:true,lg_prof_sample:0,prof_leak:true,prof_prefix:/tmp/jeprof_demo \ ./leak_demo程序运行结束后/tmp下会出现类似jeprof_demo.12345.xxx.heap的文件。同时stderr会有leak摘要输出大致长这样Leak summary: 40960000 bytes in 10000 objects, 10000 sampled这行字其实已经告诉你有10000个对象共40960000字节被泄漏了。但摘要只告诉你有泄漏不告诉你在哪接下来的PDF才是指路地图。生成PDFjeprof --leak --pdf ./leak_demo /tmp/jeprof_demo.*.heap /tmp/leak_demo_report.pdf用ls -lh /tmp/leak_demo_report.pdf看一下文件存在且大于0就说明出图成功。5.3 PDF报告怎么看打开PDF你会看到一张从main开始、向下舒展的调用树。节点是函数调用栈节点内部标着该函数及其子调用链上累计的泄漏字节数和对象数节点之间的边表示调用关系边上也标注了字节数。优先看两条信息最粗的那条路径通常是从根节点到叶子节点路径上累计值最大的那条就是泄漏的“主航道”叶子节点如果某个叶子函数本身累计分配了大量字节且没有向下的子调用说明泄漏发生在该函数直接分配的堆内存上。在示例里你会在报告里看到load_config节点的累计值接近40MB箭头指向malloc数量10000次。这时候代码审查范围就缩小到了load_config这一行分配了4KB但没释放。提示如果PDF里函数名显示为0x7f...之类的十六进制地址说明二进制被strip过符号表。解决办法是重新编一个带-g的版本或者用objcopy --only-keep-debug把符号单独提出来配合jeprof --symbols手动指定调试文件。6. 采样率与报告解读控制开销的同时保证定位精度6.1 lg_prof_sample该怎么选前面演示为了追求100%准确用了lg_prof_sample:0也就是每次分配都采样。在小程序或短时间内测试没问题但如果是长跑的服务会产生两个副作用性能开销大、heap文件体积膨胀。每次分配都记录几十分钟就能生成几百MB甚至几个GB的heap文件解析起来也慢。生产或预发环境推荐从lg_prof_sample:20起步也就是约1MB采样一次。jemalloc的采样是伯努利分布式的样本量足够大时统计结果能比较接近真实分配分布对于定位某条调用栈持续增长的问题这个精度完全够用。如果跑了半小时报告太稀、看不出热点再把lg_prof_sample调到18或16相当于更密集地采样。我的经验是先用20跑如果报告top10节点分布明显且稳定就不用动如果top节点稀疏、看起来像是随机抖动说明采样点太少逐步调低。一定要避免一上来就lg_prof_sample:0跑全量大流量业务那会让采样本身成为瓶颈。6.2 两份快照对比才是增长型泄漏的正确姿势很多线上泄漏不是“分配了就永久拿在手里”而是“新分配的速度超过释放速度”比如请求处理中创建临时对象、处理完却少释放了一部分。这类泄漏程序退出时的--leak摘要往往不明显因为很多分配最终其实被释放了只是释放得不干净。正确做法是利用自动或信号触发的dump在运行中抓两份快照# 运行中先dump一份 kill -USR2 pid sleep 120 kill -USR2 pid然后用jeprof对比两份文件jeprof --pdf --base/tmp/jeprof.前一个pid.前一个随机数.heap \ ./leak_demo /tmp/jeprof.后一个pid.后一个随机数.heap diff.pdf--base表示以前一份快照为基线报告里显示的是“从基线到当前这份”之间的净增长。哪条调用路径的字节数在增长、增长了多少一目了然。对于那种“每次请求都涨一点但退出前又释放大半”的场景这种方式比盯着终态leak摘要可靠得多。6.3 网上还有个Win10 C盘清理的场景这里顺带提醒那个热搜词列表里混了不少无关内容type c、c盘清理之类的和本文主题不搭。我只想提醒一点做内存检测时注意给prof_prefix所在的磁盘留够空间特别是lg_prof_sample调小以后heap文件膨胀速度比你想象得快。别等到磁盘满了才发现那会儿进程已经被写挂了。6.4 一个亲身教训别忽略“信号处理函数”里的malloc有一次我排一个服务端程序线程A持有某个锁线程B的代码路径里包含一个内存泄漏点。jemalloc报告成功定位到了泄漏函数但那个函数明明不是业务流程里最常见的调用甚至文档里都说不推荐在生产调用。后来仔细读代码才发现它被注册成了定时任务的回调每次老定时任务触发时都会执行一次。这个案例给我的教训是jeprof能告诉你“泄漏发生在哪”但“为什么这个函数会被反复调用”仍然需要你熟读业务代码。工具帮你缩小范围真正下结论的还得是人。7. 一点个人使用体会这套方案我现在基本固化成新服务上线前的必做检查了。流程很简单编译一个带--enable-prof的jemalloc备用跑一次业务回归用lg_prof_sample:20挂半小时中间用SIGUSR2抓两次快照对比生成PDF人工确认top10调用路径没有异常增长。整个流程大概就几分钟但它能发现的潜在问题比上线后被监控报警逼着半夜起来查要幸福得多。另外jemalloc的prof功能其实不止能查泄漏。它还可以用来做内存分配热点分析——比如某个模块分配次数特别频繁、导致锁竞争严重报告里同样看得出来。分配次数多但总量小的节点往往提示你的代码在做不合理的重复分配这时候缓存复用反而是更好的优化方向。把这些场景都纳入日常性能巡检jemalloc就不只是一个“应急排查工具”了。