Python 内存占用过高问题排查

python内存占用过高需定位持续吃内存的源头，用tracemalloc抓分配热点，结合gc状态、objgraph分析引用堆积，关注大对象缓存与rss趋势判断真实泄漏。

Python 内存占用过高，关键不是“看总用量”，而是快速定位谁在持续吃内存、为什么没被释放。多数情况并非代码写错，而是对引用机制和对象生命周期理解偏差导致的隐性堆积。

用 tracemalloc 快速抓出内存增长源头

这是最轻量、最直接的内置方案，适合开发阶段快速验证。

• 启动追踪后执行可疑逻辑，再拍快照对比，能精确到哪一行代码分配了最多内存
• 重点关注 statistics('lineno') 排序结果，前几条往往就是问题核心（比如反复 append 到全局列表、未关闭的文件读取缓存）
• 若发现某函数调用前后内存明显上涨，可进一步用 compare_to() 对比两个快照，只看新增分配

检查循环引用与 GC 状态

引用计数归零才回收，但类实例、嵌套容器相互持有引用时，计数卡在 ≥1，GC 又未及时触发，对象就滞留内存。

• 运行 import gc; gc.get_stats() 查看各代回收次数——如果第0代几乎不触发，说明新对象没被清理，可能有泄漏
• 用 objgraph.show_most_common_types(limit=20) 看哪些类型数量异常多（如几百个未释放的 dict 或自定义类实例）
• 确认是否存在闭包捕获、信号回调注册、全局事件监听器等长生命周期引用场景

盯住大对象和缓存行为

一个 500MB 的 DataFrame 或缓存字典，比上万个小对象更值得优先处理。

立即学习“Python免费学习笔记（深入）”；

• 用 sys.getsizeof() 测基础大小，对嵌套结构配合递归函数或 pympler.asizeof 获取真实开销
• 检查是否用了 lru_cache 却没设 maxsize，或手动实现的缓存没做淘汰策略
• 读取大文件时，避免 pd.read_csv() 全量加载，改用 chunksize 迭代，或用 dask/polars 延迟计算

观察进程级 RSS 而非对象估算值

内存是否真高，最终看操作系统分配给该进程的物理内存（RSS），而不是 Python 自己算出来的“理论大小”。

• 用 psutil.Process().memory_info().rss 每隔几秒打印一次，画趋势图——平稳上升即为泄漏，阶梯式跳变则对应大对象创建
• 对比 rss 和 vms：若 RSS 持续涨而 VMS 不变，大概率是 Python 层引用未释放；若两者同步暴涨，可能是底层 C 扩展（如某些图像库）分配未回收
• 生产环境可用 psutil + 日志定时采样，无需侵入业务代码