JVM 内存管理中的引用计数和根搜索算法

JVM采用可达性分析法而非引用计数法，因其无法解决循环引用导致的内存泄漏且并发更新计数器开销大；后者从GC Roots出发遍历引用链判定对象存活，天然规避循环问题。

JVM 并不使用引用计数法来判断对象是否可回收，而是采用根搜索算法（即可达性分析算法）。这是因为引用计数法在 Java 这类需要强内存安全的语言中存在根本缺陷，而根搜索能准确识别真正不可达的对象。

引用计数法的原理与局限

引用计数法为每个对象维护一个整型计数器：每当有新引用指向它，计数加1；引用失效（如变量置为 null 或超出作用域），计数减1。计数归零时，对象立即可被回收。

• 优点是实现简单、回收及时，适合对响应延迟敏感的场景
• 致命问题是无法处理循环引用——比如 A 持有 B 的引用，B 又持有 A 的引用，且外部已无任何引用指向 A 或 B。此时二者计数均为 1，但实际已成“孤岛”，应被回收却永远滞留
• 还需承担额外内存开销（每个对象多存一个整数）和并发更新时的同步成本

根搜索算法如何工作

根搜索算法以一组可信的“GC Roots”为起点，沿着所有引用链向下遍历。凡未被遍历到的对象，即判定为不可达，标记为待回收。

• GC Roots 包括：虚拟机栈中正在使用的局部变量所引用的对象、方法区中静态变量（static 字段）引用的对象、方法区中常量池引用的对象、本地方法栈中 JNI 引用的对象、以及正在运行的 Java 线程本身
• 该算法不依赖对象自身状态，只关注“从根能否到达”，天然规避了循环引用问题
• 注意：不可达对象不会立刻被清除。JVM 会进行两次标记——第一次筛选出不可达对象，第二次检查其 finalize() 方法是否有必要执行（若已执行过或被显式取消，则跳过），最终才进入回收队列

为什么 JVM 坚持用根搜索而非引用计数

Java 应用普遍依赖复杂对象图和动态反射机制，循环引用在框架（如 Spring Bean 依赖注入）、集合容器（如双向链表节点）、闭包或事件监听器中极为常见。引用计数法在此类场景下极易引发隐蔽内存泄漏，而根搜索算法稳定可靠，与分代收集、并发标记等现代 GC 策略天然兼容。

• HotSpot 等主流 JVM 完全基于可达性分析设计，包括 CMS、G1、ZGC、Shenandoah 等收集器均以此为基础
• 引用计数并未被完全抛弃——Python 和 Objective-C 使用它，但需配合弱引用（weakref）或周期性垃圾收集器来补救循环问题；Java 选择更彻底的方案：从根源上杜绝误判可能

开发中需要注意的实际影响

理解这两种算法差异，有助于写出更健壮的内存使用代码：

• 避免手动制造长生命周期的循环引用，例如在缓存 Map 中同时保存父子对象并互相强引用
• 对监听器、回调、内部类等易产生隐式引用的结构，及时解绑或使用 WeakReference/SoftReference
• 不要依赖对象“被置 null”就立刻释放——JVM 不保证立即回收，真正触发取决于 GC 周期和可达性分析结果