对象存活判定：引用计数 vs 可达性分析

垃圾回收的第一步不是"怎么回收"，而是"怎么判断一个对象还活着"。如果判错了，要么把活对象删了（程序崩溃），要么把死对象留着（内存泄漏）。这是 GC 最底层的问题。

业界有两种主流方案：

Java 选择了可达性分析，Python 选择了引用计数（加上循环引用检测）。为什么它们做了不同的选择？ 这就是本文要讲清楚的事。

引用计数的规则非常简单：

• 每个对象有一个整型字段 refCount
• 有新的引用指向它 → refCount++
• 引用离开作用域或被置空 → refCount--
• refCount == 0 → 立即回收

class RefCountedObject {
    int refCount = 0;

    void retain()  { refCount++; }
    void release() {
        refCount--;
        if (refCount == 0) {
            deallocate(this);   // 立即回收内存
        }
    }
}

优点

• 实时性好：计数归零的那一刻就回收，不需要等 GC 周期
• 实现简单：不需要暂停程序，不需要复杂的图遍历
• 回收粒度细：每次只处理单个对象，停顿极短

致命缺陷：循环引用

当 A 引用 B、B 又引用 A 时，即使外部没有任何变量再指向它们，两者的 refCount 都是 1，永远不会归零。这两个对象就成了"孤岛"——活着但永远无法到达。

Java、C#、Go、JavaScript 的 GC 都采用可达性分析（Reachability Analysis）。核心思路只有一句话：

哪些东西可以作为 GC Roots？

• 栈帧中的局部变量（每个线程的虚拟机栈中引用的对象）
• 方法区中的静态变量（static 字段引用的对象）
• 方法区中的常量（final static 引用的对象）
• JNI（Native 方法）引用的对象
• 同步监视器（synchronized 持有的对象）

注意图中 Obj6 和 Obj7 互相引用，但没有任何 GC Root 能遍历到它们。可达性分析天然免疫循环引用——只要从根走不到，不管你内部怎么互指，都会被回收。这就是 Java 选择可达性分析的核心原因。

在可达性分析判定一个对象"不可达"之后，JVM 并不会立刻回收它。如果这个对象重写了 Object.finalize() 方法，它会获得一次"复活"的机会。

逃逸流程

1. 对象被判定不可达，进入 F-Queue（Finalizer 队列）
2. Finalizer 线程（低优先级守护线程）执行对象的 finalize() 方法
3. 如果 finalize() 中把 this 赋给了某个 GC Root 可达的变量 → 对象复活
4. 如果没复活 → 第二次标记后真正回收

public class EscapeDemo {
    public static EscapeDemo SAVE_HOOK = null;

    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize() 被执行，尝试自救");
        SAVE_HOOK = this;   // 把 this 挂到一个静态变量上 → 重新可达
    }

    public static void main(String[] args) throws Exception {
        SAVE_HOOK = new EscapeDemo();
        SAVE_HOOK = null;    // 断开引用
        System.gc();          // 触发 GC
        Thread.sleep(1000);   // 等 Finalizer 线程执行

        if (SAVE_HOOK != null) {
            System.out.println("对象复活了！");   // 会打印
        }
    }
}

为什么 finalize() 被废弃？

JDK 9 将 Object.finalize() 标记为 @Deprecated，JDK 18+ 的 JEP 421 进一步讨论移除。原因：

Java 在可达性分析的基础上，还提供了四种不同强度的引用类型，让你可以精细控制对象的生命周期：

软引用：内存敏感的缓存

Map<String, SoftReference<Bitmap>> cache = new HashMap<>();

// 存入缓存
cache.put("avatar", new SoftReference<>(bitmap));

// 读取缓存
SoftReference<Bitmap> ref = cache.get("avatar");
Bitmap bmp = (ref != null) ? ref.get() : null;
if (bmp == null) {
    bmp = loadFromDisk("avatar");  // 缓存被回收了，重新加载
}

JVM 保证：在抛出 OutOfMemoryError 之前，所有软引用对象都会被回收。所以它非常适合做"有就用，没有也能活"的缓存。

弱引用：ThreadLocal 的坑与解

ThreadLocalMap 的 key 就是 WeakReference<ThreadLocal>。当 ThreadLocal 实例不再有强引用时，下次 GC 就会回收 key，但 value 仍然被线程持有。如果线程长期存活（如线程池），value 就泄漏了——这就是经典的 ThreadLocal 内存泄漏。解法是每次用完手动 remove()。

虚引用：比 finalize() 更好的替代品

PhantomReference 的 get() 永远返回 null，它唯一的用途是配合 ReferenceQueue 来获知对象何时被回收，从而执行清理操作。JDK 9 的 Cleaner 底层就是基于虚引用实现的。

很多人以为 GC 只管堆，其实方法区（元空间 / Metaspace）也会被回收。回收的对象主要是两类：废弃的类和不再使用的字符串常量。

类卸载的三个条件

一个类要被卸载，必须同时满足以下三个条件：

1. 该类的所有实例都已经被回收（堆中不存在该类的任何对象）
2. 加载该类的 ClassLoader 已经被回收
3. 该类的 java.lang.Class 对象不再被任何地方引用（无法通过反射访问）

在实际场景中，类卸载主要发生在：

• 大量使用反射生成动态代理类（如 CGLIB、ByteBuddy）后，旧的代理类可以被卸载
• OSGi / 热部署：模块卸载时，对应的 ClassLoader 被回收，类随之卸载
• JSP 编译：每次修改 JSP 都会生成新的类，旧的需要被卸载

字符串常量池回收

JDK 7+ 字符串常量池从永久代移到了堆中（JDK 8 彻底移除永久代）。常量池中的字符串如果不再被引用，也可以被 GC 回收。不过实际开发中很少需要关注这一点——除非你在大量使用 String.intern()。

两种方案对比

面试回答模板

// 1. 先说结论
"JVM 用可达性分析判定对象是否存活，不是引用计数。"

// 2. 解释为什么
"引用计数无法处理循环引用——两个对象互相持有引用时，
 即使外部没有引用指向它们，计数也不会归零。
 可达性分析从 GC Roots 出发做图遍历，
 只要从根走不到，不管对象之间怎么互指，都会被回收。"

// 3. 补充 GC Roots
"GC Roots 包括栈帧局部变量、静态变量、常量引用、JNI 引用等。"

// 4. 延伸到四种引用（如果面试官追问）
"Java 还提供了软/弱/虚引用来精细控制生命周期，
 比如 SoftReference 做缓存、WeakReference 在 ThreadLocal 中的应用。"

实战避坑清单