Python垃圾回收器不处理含__del__的循环引用，因其无法安全确定析构顺序，故将其移入gc.garbage永久封存；此类对象需手动破环或删除__del__方可释放。

Python 的垃圾回收器不是“无法释放”循环引用对象，而是根本不会去碰那些带 __del__ 方法的循环引用——它们被直接塞进 gc.garbage 永久封存。

为什么 __del__ 会让 GC 彻底放弃一个循环引用

这不是 bug，是 CPython 的主动规避策略：一旦对象定义了 __del__，且又陷入循环引用，GC 就无法安全决定谁的析构函数该先执行。它干脆不尝试，而是把整个循环体移入 gc.garbage 列表，后续所有 gc.collect() 调用都会跳过它们。

• gc.collect(0)、gc.collect(1)、gc.collect(2) 全部无效——只要对象在 gc.garbage 里，就永远不会被扫描
• 查 len(gc.garbage) > 0 是最直接的信号：你代码里肯定有类定义了 __del__，又和别的容器对象互相持有强引用
• 即使你手动 del 所有外部变量，只要这个循环还卡在 gc.garbage，内存就永远不归还

gc.collect() 返回值为 0 不代表没回收，可能只是没扫到第 2 代

默认 gc.collect() 只清理第 0 代。而循环引用对象往往跨多轮存活，早被升到了第 2 代——它压根不在本次扫描范围内。

• 用 gc.get_threshold() 查返回值类似 (700, 10, 10)：第 2 代触发需第 1 代回收满 10 次，实际业务中可能几小时都不触发一次
• 小规模循环（比如每秒只创建一对对象）几乎永远达不到第 2 代阈值，长期滞留内存
• 要真正清掉，必须显式调 gc.collect(2)，而不是 gc.collect()

弱引用破环失败的常见原因

很多人试过 weakref.ref 或 weakref.proxy，结果发现还是泄漏——问题往往出在组合使用上。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

• weakref.ref 本身不参与引用计数，但若目标对象定义了 __del__，弱引用会失效：CPython 禁止这种组合，运行时静默降级为普通强引用
• 用 weakref.WeakKeyDictionary 缓存时，如果 key 是自定义类实例且含 __del__，整个字典可能拒绝插入或行为异常
• 第三方库（如某些 ORM 或日志 handler）内部偷偷持有了强引用，weakref 根本没机会生效

真正泄漏高发场景：class 实例 + 容器嵌套 + __del__

纯 int、str、不含可变元素的 tuple 不进 GC；只有容器类型（list、dict、set、类实例）才参与循环检测。而泄漏最顽固的，就是同时满足三个条件的对象：

• 是类实例（即容器对象）
• 内部字段包含 list / dict 并相互引用（如树节点的 parent 和 children）
• 类里写了 __del__（哪怕只为了打个 log）

这时候别指望 GC 自动救场——要么删掉 __del__ 改用上下文管理器，要么在销毁前手动切断引用链。否则，gc.garbage 就是你内存泄漏的日志本，翻都懒得翻。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！