OpenJDK 使用可达性分析而非引用计数来判断对象是否可回收，从GC Roots出发遍历引用链，不可达对象才可能被回收；但还需经分代收集流程和Finalizer等检查。
OpenJDK 用可达性分析判断对象是否可回收
OpenJDK（包括 HotSpot VM）不使用引用计数，而是严格依赖可达性分析（Reachability Analysis）来判定一个对象是否“已死”。核心逻辑是：从一组固定的 GC Roots 出发，沿着所有引用链向下遍历；任何无法被到达的对象，即视为可回收。
常见 GC Roots 包括：
- Java 虚拟机栈中局部变量表引用的对象
- 方法区中类静态属性（static 字段）引用的对象
- 方法区中常量池（StringTable、Class 常量等）引用的对象
- 本地方法栈中 JNI（Native）引用的对象
- 正在被同步锁持有的对象（ObjectMonitor::owner）
注意：堆内存本身不是 GC Roots——这是高频误解。堆上对象只能被 Roots 引用，不能反过来作为 Root。
为什么不用引用计数？它在 OpenJDK 中根本不存在
引用计数看似直观，但 OpenJDK 没有实现它，也不支持配置启用。原因很实际：
-
循环引用问题无法自动解决（如objA.instance = objB且objB.instance = objA），导致内存泄漏 - 多线程下
计数器增减需要原子操作或锁，开销大且易引发竞争 - 每个对象额外携带计数字段，增加
对象头大小，影响内存布局与缓存效率 - HotSpot 的设计哲学是“用更精确的遍历换更少的运行时开销”，可达性分析虽需暂停（STW），但结果确定、无歧义
对象真的“不可达”就立刻回收吗？不，还要过几道关
即使一个对象在某次 GC 开始前被判定为不可达，它也未必马上消失。OpenJDK 会按分代模型走完整生命周期流程：
- 新生代对象若未被 Young GC 清理，可能先晋升到
Survivor区，再熬过几次 GC 才进老年代 - 老年代对象即使不可达，也要等
Full GC或对应收集器（如G1的 Mixed GC）触发才会真正清理 - 某些对象（如重写了
finalize()方法的）会被临时放入Finalizer队列，延迟一到两轮 GC 才回收——但finalize()在 JDK 9+ 已标记为@Deprecated，JDK 21 起默认禁用
如何验证某个对象是否真被回收了？别信日志，看行为
GC 日志里出现 GC pause 或 Evacuation 并不等于你的对象一定被清掉了。真正能说明问题的是：
- 对象的
finalize()（不推荐）或Cleaner回调是否执行（注意：Cleaner 是PhantomReference的封装，仅表示“已不可达”） - 用
java.lang.ref.WeakReference包裹对象后，调用ref.get() == null且System.gc()后仍为null - 通过
JFR（Java Flight Recorder）录制G1HeapSummary或ObjectCount事件，观察特定类实例数是否下降 - 避免用
Runtime.getRuntime().freeMemory()判断——它反映的是 JVM 可用堆空间，和单个对象存活无关
最常被忽略的一点：对象是否可回收，只取决于当前 GC 周期开始瞬间的引用图快照，而不是你代码里“看起来没用了”。哪怕你在 if 分支里把引用设为 null，只要该对象还在栈帧或寄存器中被隐式持有（比如 JIT 编译后优化保留了引用），它就不会被回收。
