Python内存泄漏排查技巧与步骤详解

本文深入解析了Python内存泄漏定位的核心方法与实战流程，强调gc.get_objects()作为首选工具的价值——通过强制垃圾回收后统计各类对象数量变化，快速锁定dict、list及自定义类等可疑增长源；同时揭示泄漏本质常是“幽灵引用”而非对象未删除，重点剖析循环引用（尤其含__del__时）和全局容器误用两大主因，并给出gc.get_referrers、objgraph可视化等精准追踪手段；文章还理性指出tracemalloc的适用边界与高效用法，警示gc.set_debug()在生产环境的风险，并强调需通过多次gc.collect()与对象数量回落验证释放真实性——这是一份兼顾原理深度与落地细节、专为开发者突破内存排查困局而写的硬核指南。

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

• 启动时立刻调用 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 辅助验证

生产环境别依赖 gc.set_debug()

gc.set_debug(gc.DEBUG_SAVEALL) 会让所有无法回收的对象塞进 gc.garbage，看似方便，实则危险：它本身会阻止 gc 正常工作，导致内存只增不减，还可能让程序卡死在 debug 日志输出上。

• 仅限本地复现时临时开启，且必须配 gc.DEBUG_UNCOLLECTABLE 单独使用
• 线上若真要诊断，优先用 gdb attach + py-bt 查线程堆栈，或导出 /proc/PID/smaps 看内存分布
• 更稳妥的做法是：用 faulthandler.dump_traceback_later(30) 在内存超阈值时自动 dump 堆栈，不干预运行逻辑

最难的不是找到泄漏点，而是确认“它真的被释放了”——Python 的引用计数+分代 GC 让释放时机不可控，得靠多次 gc.collect() + 观察对象数量是否回落来交叉验证。别信单次快照结果。

理论要掌握，实操不能落！以上关于《Python内存泄漏排查技巧与步骤详解》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！