排查Python应用内存泄漏：解析内存分配异常问题

未被统计的内存去向 #

• Numpy/Pandas底层C内存：tracemalloc和PYTHONMALLOCSTATS仅统计Python对象内存，而Numpy数组、Pandas DataFrame的核心数据存储在C层分配的内存块中，这部分内存完全脱离Python内存池监控，是RSS与统计值差距大的核心原因。
• 系统页缓存：htop/psutil显示的RSS包含进程映射的文件缓存（如读取大CSV/Parquet文件时的系统缓存），这部分属于操作系统管理，并非应用泄漏的内存。
• 第三方C扩展内存：若应用依赖其他C编写的扩展库，其自行分配的内存也不会被Python内存工具统计。
• 内存碎片：Python内存池或C层分配器产生的碎片，会导致实际占用内存远大于已使用内存，但这属于内存碎片化而非泄漏。

准确排查内存泄漏对象的方法 #

Python对象层面排查 #

• 使用objgraph追踪引用链：定期生成对象快照，对比不同时间点的对象数量，定位持续增长的对象类型（如DataFrame、ndarray），并通过objgraph.show_backrefs()查看对象的引用来源，找出未被释放的原因。
• 用pympler统计对象内存：pympler.Tracker可跟踪所有Python对象的创建与销毁，summary.print_summary()能输出各类对象的内存占用，帮助定位内存占比高的对象；pympler.refbrowser可可视化对象引用关系。

Numpy/Pandas专属排查 #

• 统计DataFrame实际内存：调用df.memory_usage(deep=True)获取DataFrame的真实内存占用（包括object类型列的嵌套对象内存），定期检查哪些DataFrame未被及时回收。
• 监控Numpy内存分配器：通过numpy.show_config()查看Numpy使用的内存分配器（如MKL、OpenBLAS），部分分配器会维护自己的内存池，需结合其自带工具监控（如MKL的内存监控接口）。

系统级工具排查 #

• 用pmap分析内存映射：执行pmap -x <进程PID>，查看Anonymous列的内存大小，若该值持续增长，则说明存在C层内存泄漏。
• valgrind追踪C层分配：通过valgrind --leak-check=full python your_script.py运行程序，可捕获所有C层内存泄漏，但该方法会大幅降低程序运行速度，仅适合小场景测试。

代码层面自查 #

• 检查全局变量、类属性是否持有DataFrame/数组引用，导致对象无法被GC回收。
• 排查循环逻辑：确认循环内创建的临时DataFrame是否在循环结束后被del或让其超出作用域。
• 检查闭包、异步任务、装饰器等场景，是否存在对象被意外引用的情况。

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