引用计数通过对象内部计数器实时追踪引用数量，归零即刻回收，体现“无引用即垃圾”的基础思想；但无法处理循环引用，需配合标记-清除等机制弥补。
对象引用计数是理解垃圾回收最直观的入口——它不依赖复杂扫描或暂停程序，而是靠“谁还在用我”这个简单逻辑判断对象是否还能存活。
引用计数是怎么工作的
每个对象内部带一个整数计数器（比如 Python 的 ob_refcnt），记录当前有多少变量、容器或参数正指向它：
- 创建对象或新增引用（如 a = obj、lst.append(obj)、func(obj)）→ 计数器 +1
- 引用被删除（del a）、重赋值（a = 42）、离开作用域（函数返回）、从容器移除 → 计数器 -1
- 计数器归零 → 对象立刻被释放，内存即时回收
为什么它能体现“基础回收思想”
它把“垃圾”的定义收束到一个可量化、可追踪的指标上：没有引用 = 没人需要 = 可安全清理。这种实时性让开发者能清晰感知生命周期：
- 不需要等待 GC 线程启动，也不依赖运行时状态分析
- 对象何时创建、何时销毁，和代码中引用的增减严格对应
- 调试时可用 sys.getrefcount()（Python）直接观察计数变化，验证预期行为
它的局限恰恰揭示了更深层问题
引用计数本身无法处理循环引用，而这正是推动后续算法出现的关键动因：
- 两个对象互相持有（如 a.ref = b，b.ref = a），计数器始终 ≥1，即使外部已无任何引用
- 这类对象实际已“失联”，但计数机制看不见，导致内存泄漏
- 所以 Python 在引用计数之外叠加了 标记-清除来专扫这类环；JVM 则完全跳过计数，直接采用 可达性分析，从根出发判定真实可达性
它不是万能的，但它是起点
理解引用计数，就抓住了垃圾回收最朴素的动机：自动管理“不再被需要的资源”。后续所有优化——分代收集、并发标记、GC Roots 构建、三色标记——都是在它暴露的问题基础上，为兼顾效率、准确与低延迟所做的演进。不复杂但容易忽略。
