最近在做直播推流的VP9编码模块，发现跑起来没半小时，进程的内存就从几百兆涨到了3G多，而且还在慢慢往上飘，编码速率倒是没降，就是内存像脱缰的野马，怎么都压不住。一开始以为是自己写的代码有内存泄漏，或者是libvpx的参数没配对，后来一步步排查，终于摸清楚了问题，下面把整个排查过程写出来，给踩过坑的同行参考。
一、内存突然涨起来的现场
1.1 肉眼可见的异常
那段时间我写的是一个小工具，用来批量编码视频为VP9格式，每次编码一个视频就启动一次编码器。跑了几个样本视频后，我在任务管理器里看，每次编码完一个视频，内存应该降下来才对，但实际是，编码过程中内存涨，编码完也不下来，下一个视频又接着涨，很快就占满了服务器的内存，差点把其他服务挤挂了。我当时第一反应是，自己写的代码里哪里申请了内存没释放，后来又怀疑是不是libvpx这个编码器本身的问题。
1.2 先排除参数的问题
我记得libvpx的编码器有一堆参数，比如码率控制、编码速度、延迟这些，会不会有某个参数设置得太激进，导致内存被占满？我当时就把所有自定义的参数都改成了默认值，重新跑了一遍测试。结果发现，内存还是一直涨，说明参数配置的问题暂时可以排除，那问题应该出在代码或者编码器的内部逻辑里，不是我配错了参数。
二、从代码堆栈里找破绽
2.1 怎么找到内存泄漏的位置
既然参数没问题，那肯定是哪里的内存没释放。我用了常用的排查工具，先拿到了编码进程的PID，然后让进程暂停，查看了调用堆栈。不过打印的堆栈都是内存地址，看起来懵懵的，后来换了个思路：libvpx这个库，其实有自己的内存分配和释放的函数，比如它不会直接用系统的malloc/free，而是用自己封装的vpx_malloc和vpx_free。那如果我在编译libvpx的时候，开了调试模式，就能看到内存分配的记录，这样就能知道哪些内存块没被释放。
这里我写了一个完整的示例，技术栈是C，代码是简单的VP9编码程序，带注释，方便大家复现问题：
// 技术栈：C + libvpx v1.10.0
#include <stdio.h>
#include <stdlib.h>
#include <vpx/vpx_encoder.h>
#include <vpx/vp8cx.h>
int main() {
vpx_codec_ctx_t codec;
vpx_codec_enc_cfg_t cfg;
vpx_codec_err_t res;
// 初始化编码器的默认配置
res = vpx_codec_enc_config_default(vpx_codec_vp9_cx(), &cfg, 0);
if (res != VPX_CODEC_OK) {
fprintf(stderr, "获取默认配置失败: %s\n", vpx_codec_err_to_string(res));
return -1;
}
// 配置基础视频参数，比如分辨率、帧率
cfg.g_w = 1920; // 视频宽度（1080p的宽）
cfg.g_h = 1080; // 视频高度（1080p的高）
cfg.g_timebase.num = 1;
cfg.g_timebase.den = 30; // 帧率设为30fps，符合日常视频标准
// 初始化编码器上下文，这一步会分配内存
res = vpx_codec_enc_init(&codec, vpx_codec_vp9_cx(), &cfg, 0);
if (res != VPX_CODEC_OK) {
fprintf(stderr, "初始化编码器失败: %s\n", vpx_codec_err_to_string(res));
return -1;
}
// 模拟编码一帧的操作，实际项目中这里需要填充视频帧数据，简化版就跳过具体数据处理
printf("已完成一帧的编码模拟\n");
// 错误操作：忘记销毁编码器！这是本次示例的内存泄漏根源，大家可以把下面这行注释去掉，就能释放内存
// vpx_codec_destroy(&codec);
return 0;
}
2.2 验证是不是这个问题
我把这个示例代码编译运行，然后用内存检测工具检查，结果发现确实有一块内存没被释放，就是编码器上下文对应的内存，原因就是没调用vpx_codec_destroy函数。那回到我的实际项目里，我翻了一圈代码，果然，在循环处理多个视频的逻辑里，只做了一些变量清零的操作，完全忘记调用销毁编码器的函数，导致每次编码完一个视频，都泄漏一点内存，累积起来就变得特别大。
三、libvpx编码器内部的内存管理逻辑
3.1 它的内存是怎么来的
libvpx这个编码器，不会凭空生成内存，而是在初始化编码器上下文的时候，会根据你设置的参数（比如视频分辨率、帧率、延迟参数这些），自己分配对应的内存块，用来存编码需要的临时数据，比如帧缓存、参考帧的空间、线程相关的内存这些。这些内存块，必须在你不用的时候，调用vpx_codec_destroy函数一次性释放，就像你租了个储物盒，用完必须还给管理员，不然管理员没地方放新盒子，就会一直堆得越来越多。
3.2 容易忽略的细节
还有一个容易忽略的点，就是编码完帧的处理。比如你每次把视频帧传给编码器编码，编码器会把帧的数据存到自己的缓存里，要是你没把这个缓存正确释放，也会导致内存上涨。不过这个情况一般会在调用专门的API后自动处理，但要是你用错了旧版本的libvpx，或者传参不对，也会出问题。另外，要是你开了多线程编码，每个线程都会分配自己的内存，要是线程没正确退出，也会有内存泄漏，不过这个概率比忘记销毁编码器要小很多。
四、参数配置里的隐形陷阱
4.1 延迟编码帧数的坑
还有一个我踩过的坑，就是参数里的“延迟编码帧数”，英文叫lag in frames，这个参数是什么意思呢？就是编码器会先缓存一定数量的帧，等攒够了再一起编码，这样编码效率会更高，尤其是对帧间预测的算法来说，效率提升明显。但是要是你把这个值设得太大，比如设成100，那编码器要存100帧的视频数据，要是你的视频分辨率是1080p，一帧就有几MB，100帧就是几百MB，要是你开了多个编码器实例，这个内存就会很快涨起来。我之前没注意这个参数，设成了默认的25，后来改成适合直播场景的10，内存就降了不少。
4.2 其他容易踩的参数
还有一些参数不会直接导致内存暴涨，但会影响编码效率，比如码率控制的最大码率，要是设得太高，不仅会增加带宽，还会让编码器缓存更多帧来保证质量，间接增加内存占用。另外，线程数的设置，要是开的线程太多，每个线程的栈内存会占一点，但这个是很小的部分，不会像刚才说的那样涨成几个G，主要还是和销毁编码器、延迟参数这两个问题有关。
五、完整的排查步骤总结
5.1 第一步：缩小范围，排除参数问题
先把所有自定义参数改成默认值，跑测试，要是内存还是涨，说明不是参数的问题，要是不涨，就是参数设错了，这时候再查libvpx的官方文档，找哪个参数可能导致内存涨。比如刚才说的延迟编码帧数，官方文档里明确说了这个参数会影响内存占用，超过50就需要注意。
5.2 第二步：检查代码的生命周期
核心就是检查两个地方：每次编码器初始化后，用完有没有调用vpx_codec_destroy；每次传给编码器的帧，有没有正确处理（比如释放自己分配的帧数据，或者让libvpx的API自动处理）。我就是因为忘记调用销毁函数，导致每次都泄漏一点，累积起来就大了。
5.3 第三步：用工具辅助验证
用valgrind或者libvpx的调试模式，检查内存泄漏的位置，这样能快速定位问题，不用自己盲找。比如valgrind会告诉你哪一行代码分配的内存没释放，这样很快就能找到问题点，节省大量的排查时间。
六、应用场景、优缺点和注意事项
6.1 应用场景
这个问题主要出在视频编码的场景，比如直播推流、视频转码、在线教育的视频处理，这些场景都需要用libvpx或者其他编码器，要是编码器的内存没管理好，就会导致服务器OOM，服务崩溃，所以这个排查过程对这些场景非常有用，能帮助开发者快速解决内存问题，保障服务稳定。
6.2 技术优缺点
libvpx的VP9编码，优点是编码质量高，比H.264的压缩效率高，而且是开源的，跨平台，适合各种视频场景，不需要授权费；缺点就是底层的内存管理需要开发者自己注意，要是没管好，就会有内存泄漏的问题，而且参数很多，容易踩坑，需要对编码器的内部逻辑有一定了解才能用好。
6.3 注意事项
- 每次使用完libvpx编码器，必须调用vpx_codec_destroy函数销毁上下文，释放所有分配的内存，这是最基础也最重要的一点；
- 延迟编码帧数（lag in frames）不要设得太大，根据实际场景调整，比如直播场景建议设成10左右，转码场景可以设高一点但不要超过50；
- 编码完成后，要正确处理帧数据，不要自己残留内存，比如用API获取编码后的帧后，要按照官方指引释放；
- 可以在调试模式下编译libvpx，方便排查内存问题，编译的时候加--enable-debug参数即可。
评论
围绕“使用libvpx编码VP9时内存占用不断攀升，是参数配置不当还是程序漏洞？从堆栈分析到编码器内部机制的排查实录”参与讨论