Java中System.gc()为何需显式置对象为null才触发finalize？

这个现象本质是两个层面的规则完全不匹配导致的：

• Java语法层面的局部变量作用域是编译期的约束，只负责在编码、编译阶段限制你不能在匿名块之外访问obj这个变量名，不会自动修改运行时栈帧里的实际数据。
• JVM垃圾回收判定对象是否存活，看的是运行时可达性分析结果，和你源码里能不能访问到某个变量没有直接绑定关系。

具体到测试场景的细节 #

Java方法运行时，局部变量会存在栈帧的局部变量表里，每个局部变量对应表中的一个槽位（slot），引用类型变量的槽位存着对应堆对象的内存指针：

1. 匿名代码块结束后，编译器只是禁止你再用obj这个变量名，但是不会主动往局部变量表对应槽位写null清空引用，这个槽位里还是存着之前创建的MyObject实例的指针。
2. Java 8在Windows环境下默认JIT优化等级不高时，可达性分析会直接扫描整个局部变量表的所有被占用槽位，只要槽位里还有对象引用，就会判定这个对象是GC Roots可达的，不会回收。
3. 当你手动写obj = null时，编译器会生成对应的字节码，主动把局部变量表对应槽位的引用清空，这时候再调用System.gc()，MyObject实例没有任何引用链相连，自然会被标记回收，触发重写的finalize()方法。你可以用javap -c命令反编译两个版本的字节码对比，能明确看到这个字节码层面的差异。

补充说明 #

这个行为不是Java语言规范规定的强制逻辑，是具体JVM实现的优化策略决定的，换个运行环境可能结果完全不一样。

• 如果你给JVM加上服务端模式启动参数-server，开启C2编译器的激进优化，哪怕不手动写obj = null，编译器通过逃逸分析能判断出匿名块之后这个对象再也不会被访问，会直接把它判定为不可达，这时候不置null也能触发finalize。
• 局部变量表的槽位是可以复用的，如果匿名块结束后你又定义了新的局部变量，刚好占用了原来obj对应的槽位，原来的引用会被直接覆盖，这时候不手动置null，对象也会被回收，比如下面的代码大概率也能打出gc日志：

public static void main(String[] args) throws Exception{
    {
        MyObject obj=new MyObject();
        System.out.println("No null assign, but slot reused");
    }
    long placeholder = 0L; // 新变量复用原obj的槽位，覆盖旧引用
    System.gc();
    Thread.sleep(500);
}

• 日常写业务代码完全没必要刻意给局部变量手动置null，这属于过度优化：正常方法的局部变量会随着方法出栈自动销毁，只有那种生命周期极长的方法（比如main方法跑满整个程序生命周期）、局部变量持有占内存极大的对象、且变量定义位置和后续逻辑隔得非常远的极端场景，手动置null才可能有实际效果。
• 额外提一句：System.gc()只是给JVM发送一个垃圾回收的建议，不是强制命令，JVM可以直接忽略这个调用；finalize()方法的执行时机更是没有任何确定性保证，生产环境永远不要依赖这两个机制做资源释放。

内容的提问来源于stack exchange，提问作者Troskyvs