做视频剪辑插件时卡顿严重？音频实时处理突然崩掉？后台加载贴图时内存占用一路飙红？这些现象背后，往往不是硬件不够，而是内存没管好。
为什么媒体软件特别吃内存管理？
和普通办公软件不同，媒体类程序动不动就要处理几MB甚至几百MB的原始帧数据、解码后的YUV缓冲区、GPU纹理缓存、音频采样缓冲……而且很多操作要求低延迟——比如直播推流，你不能让系统等个几毫秒才把一帧塞进编码队列。这时候，内存分配速度、碎片控制、释放时机，全成了硬指标。
几种真正在用的内存管理算法
1. 首次适应（First Fit）
从堆起始位置开始扫描，找到第一个足够大的空闲块就分配。简单粗暴，实现快，在嵌入式音视频模块里很常见。比如某款机顶盒固件的音频解码器，就用它配合固定大小内存池，避免频繁调用malloc。
2. 最佳适应（Best Fit）
遍历所有空闲块，挑出最接近请求大小的那个。听起来省空间？其实副作用明显：容易留下大量难以利用的微小碎片。有团队在开发4K视频预览组件时试过这个策略，结果跑半小时后，明明还有200MB空闲，却连一个8MB的帧缓冲都分不出来。
3. 伙伴系统（Buddy System）
Linux内核默认用它管理物理页，媒体服务容器也常借鉴。核心是“拆分-合并”逻辑：内存按2的幂次划分（如4KB、8KB、16KB……），申请10KB就给16KB；释放时若相邻“伙伴”也空着，立刻合并成32KB。适合大块连续内存需求，像FFmpeg中AVFrame的data缓冲区分配就倾向这类策略。
4. slab分配器
专治“小对象反复创建销毁”的场景。比如VST插件里每秒生成上千个AudioBufferRef结构体，用slab就能把同类型对象预先切好、挂链表、复用内存，不走通用堆。实际代码里常封装成类似这样的接口：
audio_buf_t *buf = audio_slab_alloc();
// 使用完直接归还，不free
audio_slab_free(buf);别光盯着算法，看实际怎么搭
真实项目里很少单用某一种。更常见的组合是：
• 大块媒体数据（YUV帧、PCM块）走伙伴系统或定制内存池；
• 中小结构体（metadata、event、filter参数）用slab或对象池；
• 临时计算缓冲（FFT中间数组、色彩空间转换暂存区）则用栈分配或线程局部存储（TLS），避免锁竞争。
某开源字幕渲染库改用双层内存池后，GC暂停时间从平均12ms压到0.3ms以内——因为所有字形纹理对象都在预分配池里周转，根本不需要触发系统级回收。