Java未采用引用计数法，因其无法解决循环引用导致的内存泄漏问题；该方法在A与B相互引用时使计数器无法归零，造成内存无法释放，而可达性分析可整体判定并回收不可达对象环。
Java 没有采用引用计数法，根本原因在于它无法正确处理循环引用导致的内存泄漏问题。
引用计数法的基本逻辑与表面优势
引用计数法为每个对象维护一个计数器，每当有新变量指向该对象，计数加 1；当变量脱离作用域或被赋值为 null，计数减 1。一旦计数归零，对象立即可被回收。这种方法实现简单、回收及时，在某些脚本语言（如 Python 的部分场景）中确实有效。
但它隐含一个关键前提：所有引用关系都必须被精确、实时地追踪和更新——而这个前提在复杂运行环境中极易被打破。
循环引用直接导致计数“卡死”
当两个或多个对象相互持有对方的引用（例如 A 引用 B，B 又引用 A），即使外部再无任何变量指向它们，它们各自的引用计数也不会归零。
立即学习“Java免费学习笔记（深入）”；
- A 的计数至少为 1（来自 B 的引用）
- B 的计数至少为 1（来自 A 的引用）
- 即使整个对象图已不可达，计数器仍“虚假活跃”
结果就是：内存无法释放，形成事实上的内存泄漏。这种问题不是边缘情况——在事件监听、树形结构、缓存映射、ORM 关联等常见编程模式中频繁出现。
增量式更新开销大且易出错
为缓解循环引用问题，有人设想配合弱引用或手动调用解引用接口。但这就引入新负担：
- 每次赋值、传参、作用域退出都要更新计数，显著拖慢执行速度
- 多线程环境下需对计数器加锁，进一步降低并发性能
- 开发者必须时刻关注引用生命周期，违背 Java “自动内存管理”的设计初衷
更严重的是，一旦某处漏掉一次减计数（比如异常提前退出、忘记置 null），整个对象链就永久滞留。
可达性分析天然规避循环引用缺陷
Java 采用基于 GC Roots 的可达性分析算法（如标记-清除、G1 的 RSet 等），从线程栈、静态字段、本地方法栈等可信起点出发，递归扫描所有能到达的对象。
只要 A 和 B 构成的环无法从任意 GC Root 到达，整组对象就会被整体判定为“不可达”，进而统一回收——完全绕开了计数机制的逻辑盲区。
这种方式虽带来 STW（Stop-The-World）或写屏障等额外成本，但换来了语义清晰、行为确定、无需人工干预的内存安全保证。
不复杂但容易忽略：循环引用本身不是错误，而是对象建模的自然结果；真正需要解决的，是内存回收机制能否正确认知“哪些对象真的不再需要”。Java 选择放弃引用计数，正是为了把这个问题交给更可靠、更抽象的图遍历逻辑来回答。
