📚 课程目录第4章内存优化（一）

内存优化（一）：内存泄漏检测与修复，内存分配策略

说到 SDK 的内存优化，我第一个要聊的就是内存泄漏。你可能觉得，“不就是忘了 delete 吗？现在的 GC 语言不常见了”。但做 C/C++ SDK 的人都清楚，哪怕只漏了 4 个字节，长期跑下来就是灾难。我接手过一个音视频 SDK，用户反映跑 8 小时后声音开始卡顿——一查，每帧泄露了 120 字节。8 小时积累了多少？你自己算算。

内存泄漏——SDK 的慢性病

内存泄漏不是 bug，它是“慢性病”。症状很隐蔽：刚启动时一切正常，跑久了响应变慢、内存飙高，最后 OOM 被系统杀掉。在移动端，App 被系统强杀对用户体验是毁灭性的。

常见的泄漏模式：

回调注册后没取消——我见过最频繁的元凶。注册 listener，SDK 被销毁时忘了注销，外部对象还持有 SDK 内部指针。
循环引用——尤其在使用 shared_ptr 的代码中，两个对象互相持有引用，放不掉。
原生层 & Java/ObjC 跨语言引用——JNI 全局引用创建后不释放，或者 C# 侧的 delegate 绑定原生函数未解绑。
资源泄露——不是你自己的内存，是文件描述符、GPU 纹理、数据库连接，本质上也是内存。

一句话总结：内存泄漏的可怕之处在于它无法通过一次测试发现，必须在真实场景下长时间运行才暴露。

静态检测——把错误扼杀在编译时

我个人习惯在 CI 里就跑静态分析工具，比如 Clang Static Analyzer、PVS-Studio、Cppcheck。这些工具能帮你发现明显的泄漏路径。

举个例子，你用 Clang 的 -fsanitize=leak 编译后，任何未释放的堆内存都会在退出时被报告。但别忘了，这个工具只在退出时输出——对长时间运行的服务来说，你不能等它退出才看到问题。

// 示例：Clang 检测到的典型泄漏
void leak_example() {
    int* p = new int(42);
    // 忘了 delete
} // clang-tidy 会报：Potential leak of memory pointed to by 'p'

注意：静态分析不能发现所有泄漏。它基于代码路径分析，遇到虚函数调用、条件分支特别多时就容易漏报。

运行时检测——真正的“抓现行”

运行时要抓泄漏，我常用的方案是重载 `new`/`delete`，挂接 `malloc`/`free`，记录每次分配的调用栈和大小，定期扫描未释放的内存块。这在 SDK 内部实现一个轻量的内存追踪器并不复杂。

// 简化版内存追踪器核心结构
struct AllocationRecord {
    void* ptr;
    size_t size;
    void* callstack[64];
    int depth;
};

static std::unordered_map<void*, AllocationRecord> s_allocations;
static std::mutex s_mutex;

void* track_malloc(size_t size) {
    void* ptr = malloc(size);
    if (ptr) {
        std::lock_guard<std::mutex> lock(s_mutex);
        AllocationRecord& rec = s_allocations[ptr];
        rec.ptr = ptr;
        rec.size = size;
        rec.depth = backtrace(rec.callstack, 64); // 需要链接 -lbacktrace
    }
    return ptr;
}

void track_free(void* ptr) {
    if (ptr) {
        std::lock_guard<std::mutex> lock(s_mutex);
        s_allocations.erase(ptr);
    }
    free(ptr);
}

然后你在 SDK 的某个触发点（比如每 10 秒或收到外部指令）打印所有未释放的记录：

void dump_leaks() {
    std::lock_guard<std::mutex> lock(s_mutex);
    if (s_allocations.empty()) return;
    printf("=== Memory Leak Report ===\n");
    for (auto& [ptr, rec] : s_allocations) {
        printf("Leak %p size=%zu callstack:\n", ptr, rec.size);
        for (int i = 0; i < rec.depth; ++i) {
            void* addr = rec.callstack[i];
            // 可以用 addr2line 解析符号名
            printf("  #%d %p\n", i, addr);
        }
    }
}

经验之谈：这个追踪器增加了一定的运行开销。我一般在 DEBUG 或内部测试版本中启用，Release 版本通过宏关闭。另外，记得在 SDK 的生命周期结束时自动调用 dump，避免遗漏。

表格：常见泄漏场景与检测方法对比

泄漏场景	最佳检测时机	推荐工具
忘记释放堆内存	编译时 / 退出时	Clang Static Analyzer、AddressSanitizer
回调未取消	运行中	自定义追踪器 + 断言检查引用计数
循环引用 (shared_ptr)	编译时 / 代码审查	weak_ptr 断链、静态分析
JNI 全局引用	运行时	JNI 引用计数监控、Android Studio Memory Profiler
资源泄露（FD、纹理）	运行中	Lsof、GPU 调试器、自定义句柄追踪

内存分配策略——从源头控制

泄漏修了，分配效率也得跟上。SDK 里频繁 new/delete 会产生大量碎片和性能损耗。我这里分享三个常用的优化策略。

1. 对象池 —— 复用代替重复分配

适合固定大小的对象（如网络包、事件对象）。我曾在 SDK 里封装了一个对象池：

template<typename T>
class ObjectPool {
    std::vector<T*> pool_;
    std::mutex mtx_;
public:
    T* acquire() {
        std::lock_guard<std::mutex> lock(mtx_);
        if (pool_.empty()) {
            return new T();           // 池空时创建
        }
        T* obj = pool_.back();
        pool_.pop_back();
        return obj;
    }
    void release(T* obj) {
        std::lock_guard<std::mutex> lock(mtx_);
        pool_.push_back(obj);         // 不析构，放回池子
    }
    ~ObjectPool() {
        for (auto p : pool_) delete p;
    }
};

使用对象池后，SDK 中频繁分配的小对象（比如每秒成千上万的帧元数据）不再触发系统堆操作，性能提升很明显。

2. 预分配 + 静态缓冲区

对于能预估峰值用量的场景，一次性提前分配好内存，运行时只在预分配区域内滑动指针。典型的例子是环形缓冲区（RingBuffer）。我在处理音视频流时常用——预分配一块连续内存，生产者和消费者只移动索引，零动态分配。

核心思路：把“运行时分配”变成“初始化时分配”，把“free”变成“复位指针”。

3. 小对象分配器的定制

如果你的 SDK 需要大量 tiny 对象（比如 32 字节以下），通用的 malloc 效率很低。我建议实现一个固定大小分配器，内部维护多个 free list，每个 list 对应一种固定尺寸。这个方法在 C++ 标准库的 `std::allocator` 基础上可以进一步定制。

实践案例：一次 SDK 内存优化实录

我记得去年帮一个直播 SDK 做优化。仪表盘显示，推流过程内存持续增长，但退出后还能回收——典型的“速度泄漏”。用我上面写的追踪器一查，发现是“转码器”里每帧音频会 new 一个 `AudioFrame`，但从未 delete，只是放进了队列。队列消费完就丢掉指针。修复很简单，改成对象池复用。内存曲线从一路爬升变成了平稳水平线。你可别笑，这种问题在职场上太常见了。

避坑指南：我曾经在修复泄漏时犯过一次大忌——全局替换智能指针，结果引入循环引用，反而更糟。好的做法是：先用追踪器明确泄漏点，再选择最轻量的修复方式。

内存优化不是一次性工作。我把检测工具集成到 SDK 的 CI 流水线里，每次提交自动跑，新泄漏会被拦住。分配策略根据业务场景灵活选型——没有银弹，但上面这些方法覆盖了 80% 的优化空间。