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

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

用 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 日志输出上。

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

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

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