嵌入式运维态内存泄漏检测：基于dlmalloc的轻量级线上监控方案

嵌入式设备在现场运行后，最令人头疼的问题之一便是偶现的死机和设备运行时间一长就“越来越慢”。后者通常与内存泄漏或内存碎片有关，但现场环境往往只有串口日志和有限的Flash存储，无法使用gdb调试器或Valgrind等重型工具。

开发阶段的内存泄漏可以通过单元测试、静态分析和PC端工具来解决。真正的挑战来自于以下运维场景：

• 设备运行数天甚至数周后才缓慢耗尽内存。
• 某些异常的网络数据包或罕见的业务逻辑分支才会触发泄漏。
• 线下复现成本极高，且客户现场环境复杂多变。

这类问题的共性是：只在真实负载下出现，难以在实验室完整模拟；触发条件组合复杂；设备重启后现象消失，证据难以留存。

因此，合理的思路是：在设备上常驻一套轻量级、低开销、非侵入式的内存监控与泄漏记录机制。它无需调试器和源码修改，不影响业务运行，却能在问题发生时留下关键证据。dlmalloc库提供的mallinfo/malloc_stats接口，配合一个简单的追踪表，就能构建这套基础设施。

一、dlmalloc简介与关键接口

dlmalloc是一个开源的轻量级内存分配器实现，在嵌入式领域应用广泛。它代码精简（仅几百行），无外部依赖，并自带了有用的内存统计接口。

对于运维而言，其头文件中两个接口至关重要：

• struct mallinfo mallinfo(void);：返回堆的当前统计信息结构体。
• void malloc_stats(void);：将详细的统计信息打印到stderr（在嵌入式系统中常被重定向到串口或日志文件）。

mallinfo结构体中的几个关键字段如下：

• uordblks：当前已分配的总字节数。这是监控内存消耗的核心指标。
• fordblks：当前空闲的总字节数。
• ordblks：空闲块的数量。结合fordblks可以大致评估堆的碎片化程度。
• arena：从系统申请的总堆空间大小。

仅凭这几个数字，我们就能在设备上完成一项重要工作：绘制“内存水位曲线”，宏观把握内存健康状况。

二、构建双层运维态泄漏检测机制

一个完整的运维态检测方案可以分两层构建：

1. 宏观层：使用mallinfo监控堆的整体健康状况（内存使用量是否持续增长、碎片是否增多）。
2. 微观层：在malloc/free外层包裹一个带有来源信息的“追踪表”，最终精确定位“谁分配了内存但没有释放”。

1. 宏观层：内存水位监控“看门狗”

我们可以创建一个简单的监控任务，定期采样mallinfo数据，观察趋势。

#include "malloc.h"
#include <stdio.h>

typedef struct {
    int peak_uordblks;   // 历史峰值已分配内存
    int last_uordblks;   // 上一次记录的已分配内存
} mem_watch_t;

static mem_watch_t g_mem_watch;

void memory_watchdog_task(void) {
    struct mallinfo info = mallinfo();

    // 更新峰值
    if (info.uordblks > g_mem_watch.peak_uordblks) {
        g_mem_watch.peak_uordblks = info.uordblks;
    }

    // 计算本次采样与上次的变化量
    int delta = info.uordblks - g_mem_watch.last_uordblks;
    g_mem_watch.last_uordblks = info.uordblks;

    // 输出关键信息到日志（例如每秒或每分钟一次）
    printf("[MEM] used=%dB free=%dB blocks=%d delta=%dB peak=%dB\n",
           info.uordblks, info.fordblks, info.ordblks,
           delta, g_mem_watch.peak_uordblks);
}

将上述函数集成到你的Linux系统或RTOS的定时任务中，就能观察到：

• 特定业务场景结束后，uordblks是否回落到接近初始水平。
• 在长时间运行后，uordblks是否存在缓慢但持续上升的趋势，这是内存泄漏的典型标志。

2. 微观层：基于追踪表的泄漏定位

仅知道“在漏”还不够，关键是找到“谁在漏”。思路是：用宏包装所有的分配/释放操作，并记录分配发生时的源文件和行号，存入一个追踪表。

#define USE_DL_PREFIX       // 使用 dlmalloc 前缀
#include "malloc.h"

// 分配记录结构
typedef struct {
    void       *ptr;        // 分配返回的指针地址
    size_t      size;       // 分配的字节数
    const char *file;       // 分配发生的源文件名
    int         line;       // 分配发生的源代码行号
} alloc_record_t;

#define MAX_RECORDS 256
static alloc_record_t g_records[MAX_RECORDS];
static int g_record_count = 0;

void *tracked_malloc(size_t size, const char *file, int line) {
    void *p = dlmalloc(size);
    if (p && g_record_count < MAX_RECORDS) {
        g_records[g_record_count].ptr  = p;
        g_records[g_record_count].size = size;
        g_records[g_record_count].file = file;
        g_records[g_record_count].line = line;
        g_record_count++;
    }
    return p;
}

void tracked_free(void *ptr) {
    if (!ptr) return;
    // 从追踪表中移除记录
    for (int i = 0; i < g_record_count; i++) {
        if (g_records[i].ptr == ptr) {
            // 用最后一条记录覆盖当前记录，然后总数减一
            g_records[i] = g_records[g_record_count - 1];
            g_record_count--;
            break;
        }
    }
    dlfree(ptr);
}

// 供业务代码使用的宏
#define EM_MALLOC(sz)  tracked_malloc((sz), __FILE__, __LINE__)
#define EM_FREE(p)     tracked_free((p))

程序结束时，遍历g_records表中剩余的所有记录，它们就是未被释放的内存块，并附上了详细的定位信息。

三、实战演示与代码示例

下面是一个完整的演示程序leak_demo.c：

#include <stdio.h>
#include <string.h>
#define USE_DL_PREFIX
#include "malloc.h"

// ... (此处插入上面的tracked_malloc, tracked_free, EM_MALLOC, EM_FREE等定义)

// 故意制造泄漏的函数1
void test1(void) {
    // 正常分配并释放
    char *buf1 = (char *)EM_MALLOC(64);
    strcpy(buf1, "test1: buf1");
    EM_FREE(buf1);

    // 故意不释放
    char *buf2 = (char *)EM_MALLOC(128);
    strcpy(buf2, "test1: buf2");
}

// 故意制造泄漏的函数2
void test2(void) {
    void *pkt = EM_MALLOC(512);
    // 未释放 pkt
}

// 泄漏报告函数
void report_leaks(void) {
    printf("\n========== Memory Leak Report ==========\n");
    if (g_record_count == 0) {
        printf("No leaks found.\n");
        return;
    }
    size_t total = 0;
    for (int i = 0; i < g_record_count; i++) {
        printf(" [%d] %zu bytes @ %p  from %s:%d\n",
               i + 1,
               g_records[i].size,
               g_records[i].ptr,
               g_records[i].file,
               g_records[i].line);
        total += g_records[i].size;
    }
    printf("\nTotal leaked: %zu bytes (%.2f KB)\n", total, total / 1024.0);
}

int main(void) {
    printf("========== Memory Leak Test ==========\n");
    test1();
    test2();

    struct mallinfo info = mallinfo();
    printf("\nCurrent mallinfo - Allocated: %d bytes\n", info.uordblks);

    report_leaks();
    return 0;
}

编译与运行（假设malloc.c是dlmalloc的源码文件）：

gcc -O2 -DUSE_DL_PREFIX leak_demo.c malloc.c -o leak_demo
./leak_demo

运行后，控制台将输出类似以下的信息，清晰指出泄漏发生在哪个文件的哪一行：

========== Memory Leak Report ==========
 [1] 128 bytes @ 0x55a1e7d6e2c0  from leak_demo.c:54
 [2] 512 bytes @ 0x55a1e7d6e310  from leak_demo.c:60

Total leaked: 640 bytes (0.62 KB)

这已经构成了一个最小可用的泄漏定位工具：它能报告泄漏的大小和精确的代码位置，不依赖特定操作系统或glibc。

四、生产环境注意事项

1. 性能与开销：追踪所有malloc/free会带来额外开销。建议通过编译开关（如#ifdef MEM_LEAK_TRACE）控制其启用，仅在调试版本或现场问题定位阶段开启。
2. 追踪表大小：MAX_RECORDS需要根据设备可用RAM合理设置。记录满后可采用策略：停止记录、覆盖旧记录，或只记录最大的若干次分配。
3. 选择性监控：在全量监控影响性能时，可以只对疑似问题模块的[malloc/free](https://yunpan.plus/f/34-1)调用替换为EM_MALLOC/EM_FREE。
4. 与监控系统集成：memory_watchdog_task输出的数据应接入设备的现有日志或监控系统，便于进行长期趋势分析和告警。

通过结合宏观水位监控与微观来源追踪，这套基于dlmalloc的方案为嵌入式设备提供了一种切实可行的运维态内存泄漏检测与定位手段，能够有效应对那些在实验室难以复现的线上内存问题。