引用计数法为何无法处理循环引用？

引用计数法虽能高效即时回收孤立对象，却因“只见局部、不见全局”的本质缺陷，在面对A与B相互强引用的循环场景时彻底失灵——二者计数器始终不归零，即便已完全脱离程序逻辑、不可达、毫无用处，仍被误判为活跃对象而长期驻留内存，引发隐蔽而顽固的内存泄漏；这揭示了单纯依赖引用数量无法替代对真实可达性的系统性判断，也正因此，现代主流运行时（如V8、JVM、Python的CPython在循环检测辅助下）纷纷转向标记-清除等基于根可达分析的垃圾回收策略，或辅以弱引用、手动解引等工程化手段来主动打破这种自我担保的引用闭环。

引用计数法无法解决循环引用导致的内存泄漏，核心在于它只看“谁指着我”，不看“我还能不能被程序真正用到”。

引用计数是怎么工作的

每个对象内部维护一个数字（引用计数器）：

• 变量赋值、属性赋值、函数传参等操作 → 计数器 +1
• 变量重赋值、属性删除、作用域退出等操作 → 计数器 −1
• 计数器归零时，对象立刻被回收

循环引用为什么卡住计数器

当对象 A 持有对象 B 的引用，B 同时也持有 A 的引用，而外部再没有任何其他变量指向 A 或 B 时：

• A 的计数器 ≥1（因为 B 还指着它）
• B 的计数器 ≥1（因为 A 还指着它）
• 两者实际已脱离程序逻辑，不可达，但计数器永远不为 0
• 垃圾回收器认为它们“还活着”，拒绝释放内存

本质缺陷：局部视角 vs 全局可达性

引用计数是一种“近视”算法：

• 它只统计直接指向自己的引用数量，不追踪“从全局根（如全局变量、调用栈）出发能否走到我”
• 循环引用构成一个封闭小圈子，彼此“互相担保”，把不可达对象伪装成活跃对象
• 这就像两个人互相作保贷款，谁都没收入也没资产，但银行只看担保关系，就以为他们信用良好

现实中的典型场景

以下情况容易触发该问题：

• DOM 元素与 JavaScript 对象双向绑定（如事件处理器中保存 element 引用，element 又存 handler 引用）
• 父子组件、观察者模式、缓存结构中未断开的强引用链
• C++ 中裸指针或 std::shared_ptr 不当使用；Python 中普通 dict/list 相互嵌套；早期 IE 的 COM 对象交互

怎么绕过或解决

不是靠“修计数器”，而是换思路或加约束：

• 用弱引用（WeakReference / weakref.ref）替代其中一个强引用，让它不参与计数
• 手动解引用：在生命周期结束前，显式将某一方的引用设为 null 或 None
• 改用可达性分析（如 JVM 的 GC Roots 标记、V8 的标记-清除）——从根出发扫描，自动识别并回收整个不可达闭环

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《引用计数法为何无法处理循环引用？》文章吧，也可关注golang学习网公众号了解相关技术文章。