3、手动检测方法：代码审查技巧、printf调试法、封装malloc/free进行计数

说到内存泄漏检测，很多人第一反应就是上工具。Valgrind、AddressSanitizer确实好用，但说实话，我早年做嵌入式开发那会儿，这些工具压根跑不起来。资源受限、交叉编译环境复杂，你只能靠自己的双手和大脑。

手动检测方法，听起来很原始对吧？但恰恰是这些「笨办法」，能帮你建立对内存管理的深刻理解。今天我就把压箱底的三招教给你。

3.1 代码审查技巧：用眼睛「跑」代码

代码审查不是走马观花地看。你得带着问题去读。我个人习惯在审查内存相关代码时，脑子里始终绷着一根弦——「这个malloc，它的free在哪？」

具体怎么做？我总结了几个实用技巧：

配对检查法：每看到一个malloc/calloc/realloc，立刻在注释里写上对应的free位置。如果找不到，那就是潜在泄漏点。
路径分析法：重点关注错误处理路径。很多泄漏发生在「提前return」或「goto err」时，忘了释放已分配的内存。
生命周期追踪：问自己三个问题——谁分配？谁拥有？谁释放？所有权不清晰，泄漏就来了。

核心原则：分配和释放应该在同一抽象层。你在函数A里malloc，就别指望函数B去free。除非你明确传递了所有权。

我曾经在一个网络库的代码审查中，发现一个函数有7个return点，其中3个没有释放临时缓冲区。这种问题，工具不一定能100%抓到，但人眼可以。

3.2 printf调试法：最朴素的武器

别笑，printf调试法虽然土，但关键时刻真能救命。我记得有一次在RTOS上调试，所有高级工具都用不了，最后就是靠printf定位了泄漏。

核心思路很简单：在malloc和free处打印日志。记录每次分配和释放的地址、大小、调用位置。

// 调试版malloc
void* dbg_malloc(size_t size, const char* file, int line) {
    void* ptr = malloc(size);
    printf("[MEM] ALLOC %p size=%zu at %s:%d\n", ptr, size, file, line);
    return ptr;
}

// 调试版free
void dbg_free(void* ptr, const char* file, int line) {
    printf("[MEM] FREE  %p at %s:%d\n", ptr, file, line);
    free(ptr);
}

// 使用宏简化调用
#define MALLOC(size) dbg_malloc(size, __FILE__, __LINE__)
#define FREE(ptr)    dbg_free(ptr, __FILE__, __LINE__)

运行程序后，把所有日志重定向到文件。然后你手动检查：每个ALLOC是否都有对应的FREE？地址是否匹配？

小技巧：在程序退出前，打印一条「未释放内存汇总」。简单做法是维护一个全局链表，记录所有未释放的指针。退出时遍历打印，一目了然。

当然，这方法有局限。日志量太大时，人工分析很痛苦。但对付小规模程序或特定模块，效率反而比上工具高。

3.3 封装malloc/free进行计数：给内存上「计数器」

这是printf调试法的升级版。我们不打印每条记录，而是维护一个计数器。每次malloc加1，每次free减1。程序结束时，如果计数器不为0，说明有泄漏。

来看一个我常用的实现：

#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>

static int g_malloc_count = 0;
static int g_free_count = 0;
static pthread_mutex_t g_mutex = PTHREAD_MUTEX_INITIALIZER;

void* count_malloc(size_t size) {
    pthread_mutex_lock(&g_mutex);
    g_malloc_count++;
    pthread_mutex_unlock(&g_mutex);
    
    void* ptr = malloc(size);
    if (ptr == NULL) {
        fprintf(stderr, "[ERROR] malloc failed, size=%zu\n", size);
    }
    return ptr;
}

void count_free(void* ptr) {
    if (ptr == NULL) return;
    
    pthread_mutex_lock(&g_mutex);
    g_free_count++;
    pthread_mutex_unlock(&g_mutex);
    
    free(ptr);
}

void print_mem_status() {
    printf("[MEM] malloc calls: %d, free calls: %d\n", 
           g_malloc_count, g_free_count);
    if (g_malloc_count != g_free_count) {
        printf("[MEM] WARNING: potential memory leak detected!\n");
        printf("[MEM] Leaked blocks: %d\n", 
               g_malloc_count - g_free_count);
    }
}

// 在程序退出时调用
// atexit(print_mem_status);

注意：多线程环境下，计数器操作必须加锁。否则计数不准，你会被假阳性报警折磨疯。我当年就踩过这个坑，排查了两天才发现是竞态条件。

这个方法的优点是轻量、无侵入。你只需要替换malloc/free的调用点，不需要改业务逻辑。配合atexit注册退出回调，自动打印统计信息。

但缺点也很明显——它只能告诉你「有没有泄漏」，不能告诉你「泄漏在哪」。所以实际项目中，我通常把计数法和printf法结合使用：先用计数器快速判断是否有泄漏，如果有，再用日志定位具体位置。

3.4 三种方法对比

方法	优点	缺点	适用场景
代码审查	零成本、发现逻辑问题	依赖个人经验、耗时	代码评审、小规模项目
printf调试	直观、可定位具体位置	日志量大、人工分析累	调试阶段、模块验证
计数封装	轻量、自动化、适合集成	只能检测有无泄漏	持续集成、回归测试

这三种方法不是互斥的。我个人的工作流是：编码阶段用计数法做快速验证，代码审查时用配对检查法，遇到疑难杂症上printf法。三管齐下，基本能覆盖90%的内存泄漏场景。

嗯，手动方法虽然原始，但能让你真正理解内存管理的本质。下次遇到工具用不了的情况，别慌，你的大脑就是最好的检测器。

我的建议：别嫌手动方法麻烦。你花半小时封装一个计数模块，未来可能帮你省下三天排查时间。我在一个通信协议栈项目里，就是靠这个计数模块，上线前揪出了7个泄漏点——工具一个都没报。

手动检测的精髓不在于技术多高明，而在于你养成了「每次分配都想着释放」的习惯。这个习惯，比任何工具都值钱。

📚 课程目录

3、手动检测方法：代码审查技巧、printf调试法、封装malloc/free进行计数

3.1 代码审查技巧：用眼睛「跑」代码

3.2 printf调试法：最朴素的武器

3.3 封装malloc/free进行计数：给内存上「计数器」

3.4 三种方法对比