Java 垃圾收集深度解析：对象存活判定、回收流程与内存策略

objA 与 objB相互引用，虽无实际访问路径，但引用计数不为 0，算法无法回收，故主流 Java 虚拟机弃用该算法。

可达性分析算法

主流商用语言（如 Java、C#）采用的对象存活判定算法。以'GC Roots'为起始节点集，依据引用关系遍历搜索，无引用链连接的对象判定为可回收。Java 中，GC Roots 涵盖：

• 虚拟机栈本地变量表引用对象，如方法内参数、局部变量。
• 方法区静态属性与常量引用对象，像类的静态变量、字符串常量池引用。
• 本地方法栈 JNI（Native 方法）引用对象。

虚拟机内部核心引用，包括 Class 对象、常驻异常对象（如 NullPointerException ）等。

引用分类及特性（JDK 1.2+）

JDK 1.2 拓展引用概念，按强度分为四类，各有独特内存管理行为：

强引用

程序中最常见，如 Object obj = new Object()。只要引用有效，对象不会被回收，是对象强存活的保障，支撑程序基本对象引用逻辑。

软引用

用于描述非必需但仍具使用价值的对象，内存不足即将抛出溢出异常前，会触发软引用对象回收。通过 SoftReference 实现，代码示例：

SoftReference<Object> softRef = new SoftReference<>(new Object());
Object obj = softRef.get();

适用于缓存场景，内存紧张时释放非必需对象，平衡内存使用与功能需求。

弱引用

强度弱于软引用，垃圾收集时，无论内存是否充足，弱引用关联对象都会被回收。借助 WeakReference 实现：

WeakReference<Object> weakRef = new WeakReference<>(new Object());
Object obj = weakRef.get();

常用于弱关联对象管理，如观察者模式中临时关联，避免因对象弱引用导致内存无法释放。

虚引用

又称幽灵 / 幻影引用，不影响对象生命周期，也无法通过其获取对象，主要用于接收对象回收系统通知，由 PhantomReference 实现。是内存回收事件监听的特殊手段，可在对象回收时执行特定资源清理等操作。

对象回收流程与机制

对象经可达性分析判定为不可达后，需历经两次标记才会被回收：

第一次标记与筛选

对象无 GC Roots 引用链时，触发首次标记。随后筛选是否需执行 finalize() 方法，未重写该方法或方法已执行过的对象，直接判定为可回收。

第二次标记与挽救

需执行 finalize() 的对象，被移入 F-Queue队列，由 Finalizer 线程执行该方法。若对象在 finalize() 中重新建立引用链（如关联到类变量），二次标记时会被移出回收队列；否则，执行回收。但 finalize() 存在运行代价高、不确定性大、无法保证调用顺序等问题，推荐以 try-finally 替代，示例代码展现对象自我拯救过程：

public class FinalizeEscapeGC {
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public void isAlive() {
        System.out.println("yes, i am still alive :)");
    }

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed!");
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    public static void main(String[] args) throws Throwable {
        // 首次拯救逻辑
        SAVE_HOOK = new FinalizeEscapeGC();
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead :(");
        }
        // 二次拯救（失败，因 finalize 仅执行一次）
        SAVE_HOOK = null;
        System.gc();
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead :(");
        }
    }
}

方法区的回收机制

方法区（如 HotSpot 的元空间 / 永久代）常被误解为无垃圾收集，实则不然，其回收聚焦以下两部分：

常量池回收

若常量池中的常量（如字符串）无对象引用，且虚拟机无其他引用，可被回收。如字符串'java'，若系统无对应引用，内存回收时可能被清理，优化常量池内存占用。

无用类回收

判定类为'无用'需满足三个条件：

1. 类及派生子类无实例，Java 堆中不存在该类相关实例。
2. 加载该类的类加载器被回收，此条件在自定义类加载器场景中较难满足，需精心设计。
3. 该类对应的 java.lang.Class 对象无引用，无法通过反射访问类方法。

Java 虚拟机允许回收满足条件的类，但非强制。在反射、动态代理等场景，需虚拟机具备类型卸载能力，可通过 -verbose:class、-XX:+TraceClassLoading、-XX:+TraceClassUnLoading（部分需 FastDebug 版支持）查看类加载 / 卸载信息，保障方法区内存健康。

总结

Java 垃圾收集器与内存分配策略，构建起自动内存管理的核心体系。从对象存活判定的算法演进，到引用分类的精细管控，再到对象回收流程的严谨执行与方法区回收的特殊处理，共同保障程序内存高效利用。深入理解该体系，是优化程序性能、解决内存问题的关键。后续将进一步探究具体垃圾收集器（如 Serial、G1 等）的实现与内存分配策略细节，持续深化 Java 内存管理研究，为 Java 开发者筑牢技术根基，助力打造更高效、稳定的 Java 应用。