java判断对象是否可回收采用可达性分析算法而非引用计数法，因后者无法处理循环引用且有额外开销；jvm以gc roots为起点遍历引用链判定存活，引用类型仅影响回收时机而非存活判定。
Java 中判断对象是否可被回收，核心在于“对象是否还存活”，而实现这一判断的两种主流思路，就是引用计数法和可达性分析算法。Java 虚拟机（JVM）实际采用的是后者，但理解前者有助于看清设计取舍。
引用计数法：直观但有硬伤
它给每个对象维护一个整数计数器：
- 每新增一处引用（比如变量赋值、参数传入），计数器 +1；
- 每失效一处引用（比如变量重新赋值、作用域退出），计数器 −1；
- 计数器归零时，对象即判定为“不可达”，可立即回收。
这种机制简单高效，Python、PHP、Flash Player 等确实用它。但它在 JVM 中被弃用，关键原因有两个：
循环引用无法处理
比如 A.instance = B，B.instance = A，之后 A 和 B 都不再被外部引用。此时二者计数器仍为 1，永远不为 0，导致内存泄漏。额外开销明显
每个对象都要多存一个计数字段（哪怕只占 2 字节），大量小对象下空间浪费显著；每次引用变更都要原子更新计数器，带来频繁的读写与同步成本。
可达性分析算法：JVM 的实际选择
JVM 以一组被称为 GC Roots 的对象为起点，沿着引用链向下遍历。能被访问到的对象视为“存活”，否则标记为“待回收”。
常见的 GC Roots 包括：
- 虚拟机栈中局部变量引用的对象
- 方法区中静态变量（static field）引用的对象
- 方法区中常量池引用的对象（如字符串字面量）
- 本地方法栈（JNI）中引用的对象
- 正在被 synchronized 锁住的对象
这个算法天然规避了循环引用问题：只要 A 和 B 都不再被任何 GC Root 间接引用，哪怕它们彼此引用，也会被一并回收。
引用类型影响的是回收时机，不是存活判定逻辑
Java 中的强、软、弱、虚引用，并不改变“是否可达”的基本判定——它们都基于可达性分析。区别在于：
- 强引用：只要可达，绝不回收；
- 软引用：内存不足时才尝试回收；
- 弱引用：下一次 GC 就回收（不管内存是否紧张）；
- 虚引用：仅用于跟踪对象被回收的时机，本身不阻止回收。
也就是说，引用类型是“可达性分析后的策略层”，不是“判定是否可达的底层机制”。
不复杂但容易忽略
