内存泄漏典型表现为程序运行时间越长内存持续增长、GC后不释放、RSS单向爬升；可用sys.getrefcount对比引用数变化，gc.get_referrers定位持有者，objgraph可视化引用链追踪源头。
内存泄漏的典型表现
程序运行时间越长，占用内存持续增长，即使反复执行相同操作也不释放；GC（垃圾回收）后内存仍不下降；使用 psutil 或系统监控工具观察到 RSS（常驻内存集）单向爬升。这不是 CPU 占用高或响应慢的问题，而是对象被意外持有、无法被回收。
用 sys.getrefcount 快速定位可疑对象
该函数返回对象当前被直接引用的次数（注意：传参本身会临时增加一次引用）。适合在关键逻辑前后对比引用数变化：
- 对怀疑泄漏的对象（如某个类实例、大字典、缓存容器），调用 sys.getrefcount(obj)
- 执行一段业务代码后再次检查，若引用数明显上升且未回落，说明有新引用未被清理
- 注意避开闭包、lambda、装饰器、日志记录器等隐式持有可能——它们常悄悄把对象塞进函数环境或模块级变量中
用 gc.get_referrers 追踪谁在引用它
当发现某个对象引用数异常偏高，可用 gc.get_referrers(obj) 查看所有直接引用它的对象。这是定位“谁 hold 住了它”的核心手段：
- 先确保 import gc 并调用 gc.collect() 避免新生代干扰
- 对目标对象调用 gc.get_referrers(obj)，返回一个列表，每个元素都是引用它的对象
- 重点检查：模块级变量（如 _cache、_registry）、类属性、全局列表/字典、线程局部存储（threading.local()）、未清除的回调（如 signal handler、atexit、weakref callbacks）
- 可配合 type(x) 和 repr(x)[:50] 快速识别引用来源类型和大致内容
用 objgraph 可视化引用链（推荐）
安装 pip install objgraph 后，能直观看到对象及其引用关系图，特别适合复杂嵌套场景：
立即学习“Python免费学习笔记（深入）”；
- objgraph.show_most_common_types(limit=20)：查看当前最多实例的类型，快速发现堆积类（如大量未关闭的 io.StringIO 或自定义 Model 实例）
- objgraph.find_backref_chain(obj, objgraph.is_proper_module, max_depth=10)：从目标对象向上追溯到模块级的完整引用路径
- objgraph.show_growth()：在两个时间点调用，输出新增最多的类型及数量差，直击泄漏源头
- 生成图片需额外装 graphviz，但即使只用文本模式也足够定位问题
