del 只解除引用不立即释放内存，因引用计数未归零或存在循环引用、C扩展资源未释放；需用sys.getrefcount、gc.get_referrers、tracemalloc等工具定位并主动清理。
为什么 del 之后对象还在内存里
执行 del obj 并不等于立即释放内存，它只是解除了当前作用域对对象的引用。只要还有其他变量、容器、闭包、循环引用或 C 扩展持有该对象，引用计数就不会归零，gc 也不会立刻回收。
常见干扰源包括：logging 模块缓存了异常 traceback（含局部变量）、threading.local() 存储了对象、装饰器或类方法中意外保留了 self 引用、全局字典或缓存（如 functools.lru_cache）未清理。
实操建议：
- 用
sys.getrefcount(obj)查当前引用数（注意：传参本身会+1，结果要减1才准） - 用
gc.get_referrers(obj)找出谁在引用它——重点检查返回列表里的字典、模块、函数闭包和线程对象 - 避免在日志中记录包含大对象的异常，改用
traceback.format_exc(limit=1)截断
循环引用导致 gc.collect() 不生效
纯 Python 对象间的循环引用（比如 A 持有 B，B 又持有 A）无法靠引用计数释放，依赖 gc 的周期性扫描。但默认情况下，gc 可能被禁用，或对象被标记为“不可收集”（如定义了 __del__ 方法）。
立即学习“Python免费学习笔记（深入）”；
典型现象是：手动调用 gc.collect() 返回 0，且 gc.garbage 非空。
实操建议：
- 运行
gc.set_debug(gc.DEBUG_STATS | gc.DEBUG_UNCOLLECTABLE)开启调试，观察日志里哪些对象卡在 unreachable 状态 - 检查对象是否定义了
__del__——有它就会被gc排除在自动回收外；改用weakref.finalize替代 - 对已知易成环的结构（如树节点、观察者模式），主动用
weakref.ref替代强引用
排查 C 扩展或底层资源未释放
Python 对象只是“壳”，真正占内存的可能是底层 C 分配的 buffer、文件描述符、CUDA 显存或数据库连接。这些资源不会随 Python 对象销毁自动释放，必须显式调用 close()、free() 或上下文管理器退出。
常见例子：numpy.ndarray 背后是 malloc 分配的内存；cv2.VideoCapture 占着摄像头句柄；torch.Tensor 在 GPU 上时，del 不释放显存。
实操建议：
- 查文档确认对象是否有
close()、release()、detach()等清理方法，并确保被调用 - 用
tracemalloc定位内存分配源头：tracemalloc.start(); ... ; tracemalloc.get_top_locations(10) - 对 GPU 张量，检查
tensor.is_cuda和torch.cuda.memory_allocated()，必要时调用torch.cuda.empty_cache()
__slots__ 和弱引用的实际影响
加 __slots__ 能减少单个实例的内存占用，但它不解决释放问题；反而可能掩盖引用泄漏——因为少了 __dict__，gc.get_referrers() 找不到某些引用路径。
而 weakref 是主动破环的利器，但要注意：弱引用本身不阻止回收，可被随时失效；且不能用于内置类型（如 int、str）或没有 __weakref__ 的类（__slots__ 未显式声明 __weakref__ 就不支持）。
实操建议：
- 若用
__slots__，记得在定义中加入'__weakref__'才能支持弱引用 - 用
weakref.WeakKeyDictionary或WeakValueDictionary替代普通 dict 缓存，避免键/值成为回收障碍 - 别依赖
weakref.ref(obj)()的返回值做逻辑判断——它可能已经是None
最麻烦的情况往往是多种机制叠加：一个带 __del__ 的类，被日志 traceback 持有，又放进全局 weakref 字典，同时底层还 malloc 了一块内存。这时候得一层层剥开，先确认是 Python 对象没释放，还是底层资源卡住，再决定从 gc、weakref 还是 C API 入手。
