Java 对象不再使用时，为什么要赋值为 null ？

本文原载于 SegmentFault 社区

作者：TopJavaer

---

前言

许多 Java 开发者都曾听说过“不使用的对象应手动赋值为 null“这句话，而且好多开发者一直信奉着这句话； 问其原因，大都是回答“有利于 GC 更早回收内存，减少内存占用”，但再往深入问就回答不出来了。

鉴于网上有太多关于此问题的误导，本文将通过实例，深入 JVM 剖析“对象不再使用时赋值为 null”这一操作存在的意义，供君参考。 本文尽量不使用专业术语，但仍需要你对 JVM 有一些概念。

示例代码

我们来看看一段非常简单的代码：

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
    }
    System.gc();
}

我们在 if 中实例化了一个数组 placeHolder，然后在if的作用域外通过 System.gc();手动触发了 GC，其用意是回收 placeHolder，因为 placeHolder 已经无法访问到了。 来看看输出：

65536
[GC 68239K->65952K(125952K), 0.0014820 secs]
[Full GC 65952K->65881K(125952K), 0.0093860 secs]

Full GC 65952K->65881K(125952K) 代表的意思是： 本次 GC 后，内存占用从 65952K 降到了 65881K。 意思其实是说 GC 没有将 placeHolder 回收掉，是不是不可思议？

下面来看看遵循“不使用的对象应手动赋值为 null“的情况：

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte




    
[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
        placeHolder = null;
    }
    System.gc();
}

其输出为：

65536
[GC 68239K->65952K(125952K), 0.0014910 secs]
[Full GC 65952K->345K(125952K), 0.0099610 secs]

这次 GC 后内存占用下降到了 345K，即 placeHolder 被成功回收了！ 对比两段代码，仅仅将 placeHolder 赋值为 null 就解决了 GC 的问题，真应该感谢“不使用的对象应手动赋值为 null“。

等等，为什么例子里 placeHolder 不赋值为 null，GC 就“发现不了”placeHolder 该回收呢？ 这才是问题的关键所在。

运行时栈

典型的运行时栈

如果你了解过编译原理，或者程序执行的底层机制，你会知道方法在执行的时候，方法里的变量 （局部变量） 都是分配在栈上的；当然，对于 Java 来说，new 出来的对象是在堆中，但栈中也会有这个对象的指针，和 int 一样。

比如对于下面这段代码：

public static void main(String[] args) {
    int a = 1;
    int b = 2;
    int c = a + b;
}

其运行时栈的状态可以理解成：

索引          变量
1              a
2              b
3              c

“索引”表示变量在栈中的序号，根据方法内代码执行的先后顺序，变量被按顺序放在栈中。

再比如：

public static void main(String[] args) {
    if (true) {
        int a = 1;
        int b = 2;
        int c = a + b;
    }
    int d = 4;
}

这时运行时栈就是：

索引          变量
1              a
2              b
3              c
4              d





    

容易理解吧？ 其实仔细想想上面这个例子的运行时栈是有优化空间的。

Java 的栈优化

上面的例子，main() 方法运行时占用了 4 个栈索引空间，但实际上不需要占用这么多。 当 if 执行完后，变量 a、b 和 c 都不可能再访问到了，所以它们占用的 1～3 的栈索引是可以“回收”掉的，比如像这样：

索引          变量
1              a
2              b
3              c
1              d

变量 d 重用了变量 a 的栈索引，这样就节约了内存空间。

提醒

上面的“运行时栈”和“索引”是为方便引入而故意发明的词，实际上在 JVM 中，它们的名字分别叫做“局部变量表”和“Slot”。 而且局部变量表在编译时即已确定，不需要等到“运行时”。

GC 一瞥

这里来简单讲讲主流 GC 里非常简单的一小块： 如何确定对象可以被回收。 另一种表达是，如何确定对象是存活的。

仔细想想，Java 的世界中，对象与对象之间是存在关联的，我们可以从一个对象访问到另一个对象。 如图所示。

再仔细想想，这些对象与对象之间构成的引用关系，就像是一张大大的图； 更清楚一点，是众多的树。

如果我们找到了所有的树根，那么从树根走下去就能找到所有存活的对象，那么那些没有找到的对象，就是已经死亡的了！ 这样 GC 就可以把那些对象回收掉了。

现在的问题是，怎么找到树根呢？ JVM 早有规定，其中一个就是： 栈中引用的对象。 也就是说，只要堆中的这个对象，在栈中还存在引用，就会被认定是存活的。

提醒

上面介绍的确定对象可以被回收的算法，其名字是“可达性分析算法”。

JVM 的“bug”

我们再来回头看看最开始的例子：

public static void main(String[] args) {
    if (true) {
        byte[] placeHolder = new byte[64 * 1024 * 1024];
        System.out.println(placeHolder.length / 1024);
    }
    System.gc();
}

看看其运行时栈：

LocalVariableTable:
Start  Length  Slot  Name   Signature
    0      21