关于java:对象不使用时为什么要赋值为null

送大家以下 java 学习材料，文末有支付形式

前言

许多 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;
}

其运行时栈的状态能够了解成：

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

再比方：

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

这时运行时栈就是：

容易了解吧？

其实认真想想下面这个例子的运行时栈是有优化空间的。

Java 的栈优化

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

变量 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     0  args   [Ljava/lang/String;
    5      12     1 placeHolder   [B

栈中第一个索引是办法传入参数 args，其类型为 String[]；第二个索引是 placeHolder，其类型为 byte[]。

分割后面的内容，咱们推断 placeHolder 没有被回收的起因：System.gc(); 触发 GC 时，main() 办法的运行时栈中，还存在有对 args 和 placeHolder 的援用，GC 判断这两个对象都是存活的，不进行回收 。

也就是说，代码在来到 if 后，尽管曾经来到了 placeHolder 的作用域，但在此之后，没有任何对运行时栈的读写，placeHolder 所在的索引还没有被其余变量重用，所以 GC 判断其为存活。

为了验证这一推断，咱们在 System.gc(); 之前再申明一个变量，依照之前提到的“Java 的栈优化”，这个变量会重用 placeHolder 的索引。

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

看看其运行时栈：

LocalVariableTable:
Start  Length  Slot  Name   Signature
    0      23     0  args   [Ljava/lang/String;
    5      12     1 placeHolder   [B
   19       4     1 replacer   I

不出所料，replacer 重用了 placeHolder 的索引。来看看 GC 状况：

65536
[GC 68239K->65984K(125952K), 0.0011620 secs]
[Full GC 65984K->345K(125952K), 0.0095220 secs]

placeHolder 被胜利回收了！咱们的推断也被验证了。

再从运行时栈来看，加上 int replacer = 1; 和将 placeHolder 赋值为 null 起到了同样的作用：断开堆中 placeHolder 和栈的分割，让 GC 判断 placeHolder 曾经死亡。

当初算是理清了“不应用的对象应手动赋值为 null“的原理了，所有本源都是来自于 JVM 的一个“bug”：代码来到变量作用域时，并不会主动切断其与堆的分割。为什么这个“bug”始终存在？你不感觉呈现这种状况的概率太小了么？算是一个 tradeoff 了。

总结

心愿看到这里你曾经明确了“不应用的对象应手动赋值为 null“这句话背地的奥义。

我比拟同意《深刻了解 Java 虚拟机》作者的观点：在须要“ 不应用的对象应手动赋值为 null“时大胆去用， 但不该当对其有过多依赖，更不能当作是一个广泛规定来推广。