扫码关注
INTERVIEW PLAYBOOK / 07 · 嵌入式Linux
Linux设备连续运行几天后内存持续增长，面试官常会问：怎样证明真的是应用内存泄漏，怎样定位具体的分配代码？
30秒回答
先建立可复现的增长趋势，区分进程匿名内存、页缓存和共享内存；在可运行的架构和环境里使用带调试符号的程序及Valgrind Memcheck，关注definitely lost、indirectly lost、invalid read/write等信息，追踪到分配路径并复测。不要把所有RSS上涨都认定为“malloc忘记free”。
面试官继续追问：从原理到工程验证
01先确认到底是哪种内存变化
用top、ps、/proc/PID/status、smaps_rollup等观察进程RSS/匿名内存变化，同时检查系统缓存和其他进程。操作系统会缓存文件页，系统used内存上升不一定代表应用泄漏；另外还要排除线程栈增长、内存池、映射文件和持续累积的队列数据。
02Valgrind命令和编译信息
在支持的目标架构或可复现的Linux主机环境，编译时加入-g以保留调试信息，运行valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./program。Memcheck通常会显著降低运行速度，对实时设备应谨慎选择测试环境。
03如何读LEAK SUMMARY与调用栈
definitely lost通常代表已无法通过可达指针找到分配块；indirectly lost常是由于上层拥有对象泄漏连带造成；still reachable仍可被程序找到，并非自动等于业务Bug。invalid read/write则提示越界或非法访问，需要看栈追踪、源码行号及复现输入。
04如何证明已经修复？
修改后用相同输入和运行周期复测泄漏数量与峰值内存，关注退出时清理、异常路径、重复调用和线程安全。Valgrind发现的栈只描述测试中触发的路径，没有覆盖的代码仍可能存在问题。
常见失分点
直接把free系统页缓存当成解决用户态泄漏的方案。
看到still reachable就立即判断是严重泄漏，忽略全局缓存和退出行为。
面试官可能再问一句
一个程序Valgrind检查没有泄漏，但在开发板跑两天RSS还在涨，你下一步查什么？
相关高频问答
Valgrind能直接检测内核驱动里的全部泄漏吗？
它主要是用户态内存检查工具。内核内存问题应结合内核适用的debug配置、kmemleak等工具排查。
Valgrind是否可以在所有嵌入式板上运行？
不一定，取决于架构支持、系统资源和运行环境。必要时使用ASan或主机可复现测试。
