探索 Java 垃圾收集：对象存活判定、回收流程与内存策略-EW帮帮网

一、引言

在 Java 技术体系里，垃圾收集器（Garbage Collection，GC）与内存分配策略是自动内存管理的核心支撑。深入探究其原理与机制，对优化程序内存性能、规避内存泄漏与溢出等问题意义重大，是理解 Java 运行时环境的关键环节

二、GC 基础与核心问题

（一）GC 概念溯源

垃圾收集技术并非 Java 首创，早在 1960 年，Lisp 语言已应用内存动态分配与垃圾收集。GC 需解决三个核心问题：

识别待回收内存：确定哪些对象已 “死亡”，即无被使用可能。
抉择回收时机：依据内存使用状况，选择合适时机触发回收。
选定回收方式：不同垃圾收集器采用各异的回收算法与实现逻辑。

（二）对象存活判定算法

1. 引用计数算法

原理为给对象绑定引用计数器，引用建立时计数器加 1，引用失效时减 1，计数器为 0 则判定对象可回收。但存在循环引用缺陷，如代码所示：

public class ReferenceCountingGC {
    public Object instance = null;
    private static final int _1MB = 1024 * 1024;
    private byte[] bigSize = new byte[2 * _1MB];
    public static void testGC() {
        ReferenceCountingGC objA = new ReferenceCountingGC();
        ReferenceCountingGC objB = new ReferenceCountingGC();
        objA.instance = objB;
        objB.instance = objA;
        objA = null;
        objB = null;
        System.gc();
    }
}

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

2. 可达性分析算法

主流商用语言（如 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” ，若系统无对应引用，内存回收时可能被清理，优化常量池内存占用。

（二）无用类回收

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

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

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

六、结论

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

探索 Java 垃圾收集：对象存活判定、回收流程与内存策略

个人主页-爱因斯晨

文章专栏-JAVA学习笔记

热门文章-赛博算命