gc.collect()有时无效，因它只回收循环引用对象，而内存泄漏常源于长期容器、闭包或c扩展资源未释放；需用psutil、objgraph等工具定位真实泄漏源。
为什么 gc.collect() 有时没用？
调用 gc.collect() 后内存没降，不代表没泄漏——它只回收「可到达但循环引用」的对象，而真正的问题常藏在：长期存活的容器（如全局 list、dict）、被意外绑定的闭包、或 C 扩展中未释放的资源。Python 的垃圾回收器默认启用，但不会主动扫描所有对象；它依赖引用计数 + 分代回收策略，对某些强引用链（比如日志缓冲区不断 append()）完全无感。
实操建议：
- 先确认是否真泄漏：用
psutil.Process().memory_info().rss在关键节点打点，比看任务管理器更准 - 禁用 gc 调试模式再测一次：
gc.disable()后运行相同逻辑，若内存增长变快，说明 gc 原本就在努力救场 - 别在循环里频繁调用
gc.collect()——它本身有开销，且可能干扰分代判断
用 objgraph.show_growth() 定位新增对象类型
这是最轻量的泄漏初筛方式。它不分析引用关系，只对比两次快照间的类实例数量变化，能快速指出“什么对象越积越多”。注意它默认只统计“可达对象”，所以得在疑似泄漏路径执行前后各调一次。
常见误用场景：
- 在交互式环境（如 IPython）中运行，会把临时变量、历史记录对象也计入，干扰判断 → 改用干净的脚本进程跑
- 没过滤内置类型：
objgraph.show_growth(limit=10)会刷出大量tuple、function，实际应加filter=lambda x: not x.__module__ or not x.__module__.startswith('builtins') - 忽略生命周期：某个类每秒新建 10 个、销毁 9 个，
show_growth()仍显示 +1 —— 需配合时间维度观察趋势
示例：在 Web 请求处理函数前后插入
import objgraph objgraph.show_growth() # 请求前 handle_request() objgraph.show_growth() # 请求后
用 objgraph.find_backref_chain() 追根溯源
当确认某类实例异常增多，下一步是查“谁一直拿着它的引用”。find_backref_chain(obj, predicate, max_depth=20) 会从目标对象反向爬引用链，直到满足 predicate（比如找到全局模块或线程局部存储）。这是定位泄漏源的关键一步，但容易卡死或返回过长链路。
实用技巧：
- 先缩小范围：
objs = objgraph.by_type('MyClass')拿到全部实例，选最老的那个（objs[0]）来追踪，避免分析刚创建就被清理的对象 - 限制深度和数量：
objgraph.find_backref_chain(obj, inspect.ismodule, max_depth=5)，避免陷入sys.modules或大型框架内部 - 警惕“假阳性”：Django 的
RequestContext、Flask 的g对象常持有请求相关对象，它们本身生命周期就长，需结合业务逻辑判断是否合理
哪些对象 gc 和 objgraph 都看不见？
这两者都基于 Python 对象头信息工作，对以下情况完全失效：
- C 扩展分配的内存（如 NumPy 数组底层 buffer、PIL 图像数据、Cython 类中手动 malloc 的空间）→ 查对应库的文档，找
.close()、.free()或上下文管理协议 - 被
ctypes或cffi持有的裸指针 → 必须显式调用libc.free()或对应释放函数 - 子进程或线程中创建但未 join/terminate 的资源 →
threading.Thread实例本身会被回收，但它启动的 C 级线程可能仍在运行并占内存 - 文件描述符、socket、数据库连接等 OS 级句柄 → 它们不计入 Python 堆内存，但会拖垮系统资源，用
lsof -p $(pidof python)辅助排查
真正难缠的泄漏，往往发生在 Python 对象和底层资源的交接处——比如一个封装了 sqlite3.Connection 的类忘了在 __del__ 中 close()，或者异步回调里捕获了 self 导致整个实例无法被释放。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
