python内存泄漏主因是程序逻辑导致对象无法及时回收，常见于全局缓存未清理、回调未解绑、循环引用配合__del__及弱引用使用不当；应检查全局容器、用weakvaluedictionary、加清理策略、确保回调解绑、避免__del__、用tracemalloc等工具定位引用链。
Python 内存泄漏通常不是因为 CPython 的引用计数机制失效，而是程序逻辑导致对象无法被及时回收。最常见的情况是：本该释放的对象被意外地长期持有——比如全局字典缓存未清理、回调函数绑定未解绑、循环引用配合自定义 __del__ 方法，或使用了弱引用不当。
全局容器持续累积数据
把临时数据不断塞进模块级 list、dict 或 class-level 变量，却不清理，是最直观的泄漏源。例如日志缓冲区、统计计数器、连接池缓存等，若缺乏淘汰策略（如 LRU、TTL 或显式清空），内存会随运行时间线性增长。
- 检查所有
global、module-level容器，确认是否有自动清理逻辑 - 用
weakref.WeakValueDictionary替代普通 dict 缓存，让缓存项在无其他强引用时自动消失 - 对缓存添加 size 限制和定期清理钩子（如每 N 次操作后 trim）
未解除的回调或事件监听
GUI（如 PyQt/PySide）、异步框架（如 asyncio、Tornado）或自定义事件系统中，注册回调后忘记 unregister 或 disconnect，会导致被回调对象（如窗口、Handler 实例）一直被引用链持有着，无法 GC。
- 确保每个
connect()/add_callback()都有对应生命周期管理，尤其在对象销毁前调用解绑 - 使用上下文管理器（
with）封装监听注册与自动注销 - 避免在 lambda 或闭包中隐式捕获大对象（如整个 instance），改用弱引用或显式传参
循环引用 + 自定义 __del__
当两个或多个对象互相持有强引用，且其中至少一个定义了 __del__ 方法时，CPython 的循环垃圾收集器（gc）会将它们放入“不可达但带析构器”的特殊集合，延迟回收甚至永久驻留——这是 Python 2.7 和部分旧版本中最经典的泄漏陷阱，虽在较新 CPython 中已大幅改善，但仍需警惕。
立即学习“Python免费学习笔记（深入）”；
- 尽量避免实现
__del__；优先用contextlib.closing、__exit__或weakref.finalize - 若必须用
__del__，确保不引发异常，也不访问可能已被 GC 的其他对象 - 启用
gc.set_debug(gc.DEBUG_UNCOLLECTABLE)观察是否产生无法回收的循环引用
排查工具与关键步骤
定位泄漏不能只靠猜测。先确认现象是否真是内存泄漏（而非正常缓存增长），再聚焦可疑对象。
- 用
psutil.Process().memory_info().rss定期记录进程内存，观察是否随请求/时间单调上升 - 用
gc.get_objects()获取当前所有活动对象，按类型统计数量变化（如collections.Counter(type(o).__name__ for o in gc.get_objects())） - 用
objgraph库：绘制对象引用图（objgraph.show_backrefs([leaked_obj], max_depth=5)），快速定位谁在持有着它 - 启动时加
-m tracemalloc（如python -m tracemalloc -t your_script.py），之后用tracemalloc.take_snapshot()对比内存分配源头
内存泄漏的本质是引用关系失控，不是语言缺陷。盯住“谁还拿着它”，比猜“它为什么没被删”更有效。多数问题在加几行清理代码或换一种引用方式后就能解决。
