嵌入式Linux下top命令RES常驻内存只增不减问题咨询

你观察到的RES指标不会随free调用回落是Linux系统用户态内存分配器的正常行为，top展示的RES是当前时刻进程实际驻留物理内存的大小，并非历史峰值：

• Linux下malloc/free默认不直接和内核交互申请/释放物理内存，而是由C标准库自带的内存分配器（嵌入式场景常用musl、uclibc，桌面/服务器常用glibc的ptmalloc）管理用户态内存池：
  • 当申请的内存块小于分配器阈值（默认128KB，可通过M_MMAP_THRESHOLD参数调整）时，分配器会先通过sbrk系统调用向内核申请一块更大的连续内存作为堆区，再将堆区内的小内存块返回给业务代码，这一步会触发RES上涨。
  • 业务调用free释放小内存块时，分配器仅将该内存标记为空闲，归入进程内的内存池复用，不会主动将堆区内存返还给内核，因此RES不会下降。
  • 后续再次申请同等或更小的内存时，分配器直接复用内存池内的空闲块，无需向内核申请新内存，因此RES也不会继续上涨。
• 仅当释放的内存块大于阈值、且分配器是通过mmap单独为该块申请的映射内存时，free才会直接调用munmap将内存返还内核，触发RES下降。

1. 区分分配器缓存与真实泄漏 #

在业务逻辑的所有已申请内存都完成free调用的测试节点，手动调用malloc_trim(0)接口强制内存分配器将堆区的空闲内存返还给内核，再观察RES变化：

若调用malloc_trim后RES回落到预期值，说明之前的RES上涨是分配器缓存导致，不存在内存泄漏；若RES仍居高不下，才说明存在真实的内存泄漏。

2. 嵌入式场景常用排查工具 #

• 轻量级资源受限场景：使用C标准库自带的mtrace工具，仅需在代码入口添加setenv("MALLOC_TRACE", "mtrace.log", 1); mtrace();，编译时开启-g调试参数，运行程序后执行mtrace 程序路径 mtrace.log即可直接输出泄漏内存的分配位置。
• 开发板资源充足场景：使用valgrind的memcheck检测功能，执行valgrind --leak-check=full ./目标程序，程序退出后会输出完整的泄漏点调用栈、泄漏内存大小等信息，注意valgrind运行时会占用10倍以上的内存和CPU资源，仅适合开发测试阶段使用。
• 长期运行程序排查：定期采集/proc/[进程PID]/smaps文件中的Anonymous内存大小变化趋势，或使用jemalloc/tcmalloc替换默认分配器，开启自带的内存 profiling 功能统计分配释放数据，判断是否存在随运行时间持续增长的内存块。

内容的提问来源于stack exchange，提问作者peregrinus