现代JVM采用可达性分析法而非引用计数法，因后者无法解决循环引用导致的内存泄漏，且频繁更新计数器带来性能开销；前者通过GC Roots全局遍历判定对象存活，天然规避循环引用问题。
引用计数法和可达性分析法是判断对象是否存活的两种根本不同的思路，它们在设计逻辑、运行开销、适用场景上差异显著。现代JVM（如HotSpot）全部采用可达性分析法，而引用计数法仅见于Python、Objective-C等语言中——这不是偶然选择，而是由各自本质缺陷决定的。
判定逻辑完全不同
引用计数法依赖“局部计数”：每个对象自带一个整型计数器，被引用一次就+1，引用断开就-1；只要计数归零，立刻认定为垃圾。它不关心对象在整个内存图中的位置，只看“谁还指着我”。
可达性分析法则基于“全局连通性”：从一组固定的GC Roots（如栈帧里的局部变量、静态字段、活跃线程等）出发，沿着所有引用链做深度或广度遍历；最终未被触达的对象才被标记为不可达，进而回收。
循环引用问题无法绕过
这是引用计数法被JVM弃用的核心原因：
• 两个对象A和B互相持有对方引用（A.instance = B; B.instance = A），即使外部所有引用都已置为null，它们的计数器仍为1，永远无法归零。
• 可达性分析法天然规避该问题：只要A和B都不在GC Roots的任何引用路径上，哪怕彼此引用，也会被一并判定为不可达并回收。
• 某些语言（如Python）通过周期性执行“循环检测器”来补救，但这属于额外机制，并非引用计数本身的能力。
性能与资源开销对比鲜明
引用计数法的代价：
• 每次赋值操作（如obj = new Obj()、obj = null、field = obj）都需原子更新计数器，带来频繁的读-改-写开销。
• 每个对象头多占4~8字节存储计数器，在堆内存紧张时尤为明显。
可达性分析法的代价：
• 不需要修改对象头，节省空间。
• 但必须暂停用户线程（Stop-The-World）执行完整扫描，尤其在老年代大堆场景下停顿明显。
• 后续优化（如三色标记、增量更新、写屏障）都是为缓解这一停顿而设计。
实际应用中的取舍依据
• 实时性要求极高且对象生命周期短的系统（如游戏脚本、嵌入式逻辑），引用计数法的即时回收特性有优势。
• 需要稳定吞吐与可控停顿的通用应用（Java服务端），可达性分析法配合分代收集更可靠。
• 引用类型支持（强/软/弱/虚引用）只能在可达性分析框架下实现，因为其语义依赖于GC Roots的遍历过程与时机控制。
• JVM规范未限定具体算法，但HotSpot等主流实现从未将引用计数作为主路径——不是不能做，而是它解决不了Java典型场景下的根本矛盾。
