Python 内存泄漏定位的系统流程

冰川箭仙

发布时间：2026-02-19 17:55:24

799人浏览过

来源于php中文网

原创

gc.get_objects()是定位python内存泄漏的首选方法，先gc.collect()再统计各类型对象数量，重点检查dict、list、自定义类等是否随请求稳定增长，并排查循环引用和全局容器中的幽灵引用。

python 内存泄漏定位的系统流程

用 `gc.get_objects()` 快速定位可疑对象类型

Python 的内存泄漏往往不是“对象没被删”，而是“不该活的对象被意外引用着”。gc.get_objects() 能拿到当前所有可追踪对象，是排查起点。别一上来就上 tracemalloc——它只记分配点，不告诉你谁在持有着。

先调用 gc.collect() 强制清理，再用 gc.get_objects() 拿快照，避免临时对象干扰
按类型统计数量：Counter(type(o).__name__ for o in gc.get_objects())，重点盯住 dict、list、function、自定义类名（比如 HttpRequest）
如果某类对象数量随请求/循环稳定增长，基本可以锁定方向；但注意：weakref、deque 等自带缓存的类型也可能假阳性

查循环引用和全局容器里的“幽灵引用”

90% 的真实泄漏来自两类地方：一是类实例之间形成循环引用（尤其带 __del__ 时 gc 不敢动），二是往模块级 list、dict、weakref.WeakKeyDictionary（误用成强引用）里不断 append 或 setdefault。

检查所有全局变量：搜索 = \[、= \{、= defaultdict(，看有没有在函数内无条件 .append() 或 [key] =
对疑似泄漏类，加一句 print(gc.get_referrers(instance))，看谁还拿着它——常见凶手是日志 handler、信号回调、装饰器闭包、线程 local 存储
用 objgraph.show_backrefs([obj], max_depth=3)（需装 objgraph）可视化引用链，比纯文本快得多

`tracemalloc` 只在启动时开，且限定 top N 行

tracemalloc 开销不小，长期开着会拖慢程序、掩盖真实泄漏节奏。它真正有用的是对比“泄漏前后”的分配差异，而不是实时监控。

hstshop鸿思特商城系统

鸿思特商城系统HstShop是一款B2C独立网店系统，由拥有十年互联网开发经验的牛头带队开发完成，完全免费开源，适合大中型网站平台快速构建立强大的网上商城平台网店系统。HstShop悉心听取每一位商家的需求与建议，根据中国人的购物习惯改进了购物流程，实现更好的用户购物体验。HstShop网店系统无论在产品功能、稳定性、执行效率、负载能力、安全性和搜索引擎优化等方面都居国内同类产品领先地位，成为国内

下载

启动时立刻调用 tracemalloc.start(25)（25 是栈深度，够用就行，别设 100）
不要每秒 tracemalloc.take_snapshot()——改用关键节点拍：比如处理完 100 个请求后、或检测到内存 RSS 上涨 50MB 后
对比快照时用 snapshot.compare_to(prev, 'lineno')，直接定位到哪行代码新分配了最多内存，而非泛泛看文件
注意：C 扩展（如 numpy 数组、requests 的 Response.content）不进 tracemalloc，得靠 psutil.Process().memory_info().rss 辅助验证