引用计数法因无法处理循环引用而被jvm弃用：对象a与b互相引用时计数器始终大于0，导致内存泄漏；jvm采用可达性分析法，从gc roots出发全局遍历，可准确回收整个不可达环。

引用计数法的基本逻辑很简单

每个对象内部维护一个整数计数器，每当有新变量或字段指向它，计数器就 +1；当某个引用被置为 null、离开作用域或重新赋值时，计数器就 -1。一旦计数归零，系统立刻认定该对象“已死”，可立即回收。

循环引用是它无法绕开的硬伤

两个或多个对象彼此持有对方的引用，但外部再无任何活引用指向它们——此时它们实际已不可达、应被回收，但计数器始终大于 0，导致内存泄漏。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 比如 Parent 持有 Child 的引用，Child 又反向持有 Parent 的引用
• 即使把外部变量全部设为 null，这两个对象的计数器仍各为 1（互相维持）
• JVM 无法识别这种“逻辑死亡”，只能持续保留它们占用的堆空间

Java 虚拟机不采用它的根本原因

不是实现难度高，而是这种缺陷在真实业务中极易发生——尤其在使用监听器、内部类、缓存容器或 ORM 关系映射时，稍不留神就会形成隐式循环引用。JVM 必须保证内存回收的可靠性与一致性，不能容忍“本该回收却一直驻留”的情况。

• 所有主流 JVM（HotSpot、OpenJ9 等）都弃用引用计数法
• 取而代之的是 可达性分析算法：从 GC Roots 出发做图遍历，只认“是否能被根到达”，不依赖局部计数
• 哪怕对象间存在环状引用，只要整个环脱离 GC Roots，就能被准确判定并回收

为什么其他语言还能用引用计数？

像 Python、Objective-C（ARC 模式）确实在用，但它们通过额外机制来补救：

• Python 引入了专门的循环检测器（cycle detector），定期扫描并打破引用环
• Objective-C 的 ARC 编译器要求开发者手动标注 weak 或 unowned 来切断环
• Java 选择不做这种妥协，直接用更健壮的全局可达性模型，避免运行时不确定性

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南