引用计数无法解决循环引用，因互相持有引用导致计数永不归零；CPython 依赖 gc 模块通过分代回收检测并清理容器型对象的循环引用，而不可变类型等不受 GC 管理。
引用计数为什么不能解决循环引用
Python 主要靠 sys.getrefcount() 背后的引用计数机制实时释放对象，但一旦两个或多个对象互相持有对方的引用（比如 A.b = B 且 B.a = A），它们的引用计数就永远不会降到 0，即使外部已无任何变量指向它们。
这种情况下，引用计数失效，对象内存无法被立即回收——这是设计使然，不是 bug。CPython 的引用计数只看“直接持有”，不追踪跨对象关系。
- 常见场景：树节点父子互指、观察者模式中回调绑定、类实例与闭包之间形成强引用环
- 验证方式：用
gc.get_objects()查看疑似残留对象，再用gc.get_referrers(obj)追踪谁在引用它 - 注意：
sys.getrefcount(x)本身会让 x 的计数 +1（因为参数传递产生临时引用），结果比真实值大 1
gc 模块如何检测并清理循环引用
Python 启动时自动启用 gc 模块，它采用「分代回收」策略：把对象按“存活时间”分为三代（0/1/2），新对象进第 0 代；每次第 0 代回收后，未被清除的对象升入第 1 代，依此类推。越老的对象越少被扫描，降低开销。
关键点在于，gc.collect() 不是简单遍历所有对象，而是只检查“可能成环”的容器类型（如 list、dict、class 实例），跳过不可变或无引用字段的类型（如 int、tuple）。
立即学习“Python免费学习笔记（深入）”；
- 手动触发：调用
gc.collect(0)强制清理第 0 代，gc.collect()清理全部三代 - 禁用自动回收：
gc.disable()，但需自行管理，否则内存缓慢泄漏 - 对象若定义了
__del__方法，GC 会将其放入“不可达但带析构器”的特殊队列，延迟处理——这可能导致循环中部分对象无法及时清理
哪些对象会被 gc 模块忽略
gc 模块只管理“可被 Python 代码动态修改引用关系”的对象，即具备 PyObject_GC_New 标记的容器型对象。以下情况不会进入 GC 跟踪：
- 内置不可变类型：
int、str、tuple（不含可变元素时）、frozenset - 由 C 扩展直接分配、未调用
PyObject_GC_New的对象（如某些 NumPy 数组底层 buffer） - 显式从跟踪中移除的对象：
gc.untrack(obj)，常用于性能敏感路径，但需确保它不参与循环 - 函数、类型、模块等单例对象通常也不在 GC 队列中——它们生命周期与解释器一致
这意味着，哪怕你写了个 list 包着一堆 int，只有 list 本身受 GC 管理，里面的 int 仍走纯引用计数。
调试循环引用的实用技巧
真正卡住的往往不是“有没有循环”，而是“哪一层漏掉了 weakref 或 __del__ 导致清理链断裂”。推荐组合使用几个低开销工具：
- 启用调试标志：
gc.set_debug(gc.DEBUG_SAVEALL)，让所有不可达对象保留在gc.garbage列表中，便于后续 inspect - 用
objgraph.show_backrefs([obj], max_depth=3)（需安装objgraph）可视化引用路径，比手写gc.get_referrers直观得多 - 对频繁创建销毁的类，加一行
__slots__ = ()可减少 GC 跟踪开销（因无__dict__，不被视为通用容器） - 避免在
__del__中访问其他可能已被 GC 的对象——此时执行顺序不确定，容易引发AttributeError或静默失败
最麻烦的情况是 C 扩展与 Python 对象交叉持有引用，这时 gc 看不见 C 层的指针，只能靠扩展作者正确实现 tp_traverse 和 tp_clear。
