8. 资源管理：内存分配与释放策略、句柄管理、避免资源泄漏

资源管理，说白了就是「谁分配，谁释放」这六个字。但就这六个字，我在项目里见过无数种死法——内存泄漏、句柄耗尽、野指针崩溃……嗯，今天咱们就把这块硬骨头啃干净。

8.1 内存分配与释放策略

插件化架构里，内存管理比普通程序要复杂得多。为什么？因为主程序和插件可能用的是不同的运行时库，甚至不同的编译器。你想想看，主程序用 malloc 分配的内存，插件用 free 释放——这在 Windows 上大概率直接崩掉。

⚠️ 跨模块内存分配警告

不同模块（主程序 vs 插件）必须使用同一套内存分配器。否则轻则内存泄漏，重则堆损坏。

我个人习惯的做法是：统一分配接口。主程序暴露一组内存操作函数给插件使用，而不是让插件直接调用 malloc/free。

// 插件接口定义
typedef struct {
    void* (*alloc)(size_t size);
    void  (*free)(void* ptr);
    void* (*realloc)(void* ptr, size_t new_size);
} plugin_memory_api_t;

// 主程序实现
static void* plugin_alloc(size_t size) {
    return malloc(size);  // 统一走主程序的堆
}

static void plugin_free(void* ptr) {
    free(ptr);
}

static plugin_memory_api_t g_mem_api = {
    .alloc   = plugin_alloc,
    .free    = plugin_free,
    .realloc = plugin_realloc
};

// 插件初始化时传入
int plugin_init(const plugin_memory_api_t* mem_api);

我在项目中遇到过一个问题：某个第三方插件自己偷偷用了 new/delete，结果和主程序的 malloc/free 混着用。排查了两天才发现，最后强制要求所有插件必须通过接口分配内存。

8.2 句柄管理

句柄（Handle）是什么？说白了就是一个不透明的 ID，用来代表某个资源。你想想看，如果直接把指针暴露给插件，插件乱写怎么办？句柄就是一层保护。

我建议用 索引 + 序列号 的方式实现句柄。这样既能快速查找，又能检测到野句柄。

typedef struct {
    uint32_t index;    // 在句柄表中的索引
    uint32_t serial;   // 序列号，防止重用
} handle_t;

#define INVALID_HANDLE { 0xFFFFFFFF, 0 }

typedef struct {
    void*    ptr;      // 实际资源指针
    uint32_t serial;   // 当前序列号
    bool     in_use;   // 是否被占用
} handle_entry_t;

static handle_entry_t g_handle_table[MAX_HANDLES];
static uint32_t       g_handle_count = 0;

handle_t handle_create(void* resource) {
    for (uint32_t i = 0; i < MAX_HANDLES; i++) {
        if (!g_handle_table[i].in_use) {
            g_handle_table[i].ptr    = resource;
            g_handle_table[i].serial = g_handle_count++;
            g_handle_table[i].in_use = true;
            return (handle_t){ i, g_handle_table[i].serial };
        }
    }
    return INVALID_HANDLE;  // 句柄表满了
}

void* handle_resolve(handle_t h) {
    if (h.index >= MAX_HANDLES) return NULL;
    handle_entry_t* entry = &g_handle_table[h.index];
    if (!entry->in_use || entry->serial != h.serial) return NULL;
    return entry->ptr;
}
💡 句柄管理的经验之谈

句柄表的大小要可配置。我曾经在一个嵌入式项目里把 MAX_HANDLES 设成 64，结果插件一多就满了。后来改成动态扩展的哈希表，才彻底解决。

8.3 避免资源泄漏

资源泄漏是插件化架构的「慢性病」。一开始看不出问题，跑个几天几夜后，内存涨上去了，句柄耗尽了，系统就挂了。

我总结了一套 RAII 风格 的资源管理策略。虽然 C 语言没有 RAII，但我们可以用结构体封装 + 回调来模拟。

// 资源包装器
typedef struct {
    void* resource;
    void (*cleanup)(void*);
} resource_guard_t;

#define RESOURCE_GUARD_INIT { NULL, NULL }

void resource_guard_init(resource_guard_t* guard, 
                         void* res, 
                         void (*cleanup_fn)(void*)) {
    guard->resource = res;
    guard->cleanup  = cleanup_fn;
}

void resource_guard_destroy(resource_guard_t* guard) {
    if (guard->resource && guard->cleanup) {
        guard->cleanup(guard->resource);
        guard->resource = NULL;
    }
}

// 使用示例
void process_data(plugin_t* plugin) {
    resource_guard_t guard = RESOURCE_GUARD_INIT;
    
    void* buffer = plugin->mem_api->alloc(1024);
    resource_guard_init(&guard, buffer, plugin->mem_api->free);
    
    // ... 处理数据，即使中间 return，guard 也会自动释放
    
    resource_guard_destroy(&guard);
}
🔑 资源泄漏的三大根源
  1. 异常路径未释放：函数中间 return 或 goto 时，忘了释放已分配的资源
  2. 跨模块所有权不清：主程序以为插件会释放，插件以为主程序会释放
  3. 循环引用：插件 A 持有插件 B 的资源，插件 B 又持有插件 A 的资源，谁也释放不了

我曾经在一个网络协议栈的插件里，遇到过一个极其隐蔽的泄漏：插件每次处理完数据包后，会释放数据包本身，但忘了释放数据包里的一个子缓冲区。这个子缓冲区只有 64 字节，但每秒处理 10000 个包……嗯，跑了一天，内存就爆了。

8.4 资源管理的核心流程

下面这张图，是我在项目里总结出来的资源管理全流程。你看一遍，基本就能避免 90% 的资源问题。

资源管理核心流程 1. 资源分配 2. 创建句柄 3. 使用资源 4. 释放资源 5. 句柄失效 ⚠️ 常见陷阱 • 跨模块分配器不一致 • 异常路径未释放 • 句柄序列号溢出 • 忘记释放子资源 • 循环引用 • 多线程竞争 ✅ 最佳实践 • 统一分配接口 • RAII 风格封装 • 句柄有效性检查 • 资源泄漏检测工具 核心原则 1. 谁分配，谁释放 2. 句柄代替裸指针 3. 统一分配器 4. 尽早释放 5. 避免跨模块传递 资源类型 • 堆内存 • 文件句柄 • 网络连接 • 锁/信号量 • 插件实例

8.5 资源泄漏检测

光靠人眼审查代码是不够的。我建议在开发阶段就引入 资源泄漏检测机制。最简单的方法：在分配和释放时打桩统计。

// 资源泄漏检测器
typedef struct {
    const char* file;
    int         line;
    void*       ptr;
    size_t      size;
} alloc_record_t;

static alloc_record_t g_alloc_records[MAX_ALLOCS];
static int            g_alloc_count = 0;

void* tracked_malloc(size_t size, const char* file, int line) {
    void* ptr = malloc(size);
    if (ptr && g_alloc_count < MAX_ALLOCS) {
        g_alloc_records[g_alloc_count].file = file;
        g_alloc_records[g_alloc_count].line = line;
        g_alloc_records[g_alloc_count].ptr  = ptr;
        g_alloc_records[g_alloc_count].size = size;
        g_alloc_count++;
    }
    return ptr;
}

void tracked_free(void* ptr) {
    // 查找记录并移除
    for (int i = 0; i < g_alloc_count; i++) {
        if (g_alloc_records[i].ptr == ptr) {
            g_alloc_records[i] = g_alloc_records[--g_alloc_count];
            break;
        }
    }
    free(ptr);
}

void dump_leaks(void) {
    if (g_alloc_count == 0) {
        printf("✅ 无资源泄漏\n");
        return;
    }
    printf("❌ 发现 %d 处资源泄漏:\n", g_alloc_count);
    for (int i = 0; i < g_alloc_count; i++) {
        printf("  %s:%d - %zu bytes\n",
               g_alloc_records[i].file,
               g_alloc_records[i].line,
               g_alloc_records[i].size);
    }
}

// 使用宏简化
#define MALLOC(size) tracked_malloc(size, __FILE__, __LINE__)
#define FREE(ptr)    tracked_free(ptr)
💡 生产环境怎么办？

调试版本打开泄漏检测，发布版本关闭。用宏控制：#ifdef DEBUG 时启用跟踪，#else 时直接调用 malloc/free。

8.6 总结

资源管理这件事，说白了就是「有借有还，再借不难」。但插件化架构让这个「借还」变得复杂了——借的人可能不是还的人，借的方式可能和还的方式不匹配。

我个人最深的体会是：尽早建立规则，严格执行。不要等到项目后期再来补资源管理的坑，那时候改起来成本太高了。

嗯，记住这几点：统一分配接口、句柄代替裸指针、RAII 风格封装、泄漏检测工具。做到这些，你的插件系统就能跑得稳、跑得久。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →