Java方法中不使用的对象应该手动赋值为NULL吗？

在java方法中，不使用的对象是否应该手动赋值为null？我们先来通过一个示例看一下。

垃圾回收示例一

public class GuoGuoTest {
    public static void main(String[] args) {
        byte[] placeholder = new byte[64 * 1024 * 1024];
        System.gc();
    }
}

上面代码向内存填充了64MB的数据，然后通知虚拟机进行垃圾回收。我们在运行代码启动的时候，加上参数 “-verbose:gc” ，观察一下虚拟机垃圾回收的情况。

运行完代码之后，发现64MB内存并没有被回收。这个结果很正常，因为System.gc()执行的时候placeholder还处于作用域范围以内，虚拟机自然不会回收它。

垃圾回收示例二

现在我们将示例一的代码稍作修改，给placeholder用花括号加了一个作用域。在代码执行之前我们可以猜测一下，现在placeholder和System.gc()不处于一个作用域范围，placeholder不会再被访问，所以当执行System.gc()时，placeholder应当被虚拟机认作可以回收的变量。

public class GuoGuoTest {
    public static void main(String[] args) {
        {
            byte[] placeholder = new byte[64 * 1024 * 1024];
        }
        System.gc();
    }
}

执行结果如下图，可以看到结果出乎我们的预料，placeholder并没有被回收，这是什么原因呢？

垃圾回收示例三

在解释原因之前，我们可以将上面代码再次修改，加入一行代码 int guoguo = 0。这次运行代码之后，placeholder会被垃圾回收吗？

public class GuoGuoTest {
    public static void main(String[] args) {
        {
            byte[] placeholder = new byte[64 * 1024 * 1024];
        }
        int guoguo = 0;
        System.gc();
    }
}

增加的这一行代码看起来很无厘头，但程序运行的结果居然是内存这次被回收了！

栈帧

想要知道上述现象的原因，就要从栈帧结构说起。栈帧（Stack Frame）是虚拟机用于方法调用和方法执行的数据结构，它是虚拟机运行时数据区中的虚拟机栈的栈元素。栈帧的结构包括：

方法的局部变量表
操作数栈
动态连接
方法返回地址

在编译程序代码时，需要多大的局部变量表，多深的操作数栈，是由Class文件结构中方法表的Code属性决定的，也就是在程序运行之前就已经约定好了。程序运行期间变量数据的大小并不会影响栈帧的内存分配，而取决于虚拟机的具体实现。

从逻辑概念上看，栈帧结构如图所示。在活动线程中，只有顶端的栈帧才是有效的，叫做当前栈帧（Current Stack Frame），与当前栈帧相关联的方法叫做当前方法（Current Method），每一个方法在从调用开始到结束的过程，就对应着栈帧在虚拟机栈里从入栈到出栈的过程。虚拟机的执行引擎执行的所有字节码指令都只针对当前栈帧进行操作。

局部变量表

局部变量表（Local Variable Table）是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。局部变量表容量的最小单元是变量槽（Variable Slot，简称Slot）。虚拟机规范并没有明确指明Slot占用的内存空间大小，只是向导性的表示应能存放一个boolean、byte、char、short、int、float、reference或returnAddress类型的数据，即32位及其以下的数据都可以存放。returnAddress类型现在已经很少见了。reference类型表示对一个对象实例的引用，虚拟机规范没有说明它的长度和它的结构，但虚拟机的实现至少应满足两点：

从此引用中直接或间接地查找到对象在Java堆中的数据存放的起始地址索引
从此引用中直接或间接地查找到对象所属数据类型在方法区中的存储的类型信息

对于64位的数据类型，虚拟机将用高位对齐的方式为其分配两个连续的Slot空间。64位的数据类型只有long和double两种，reference可能是32位也可能是64位。虽然long和double数据类型的一次读写会被分割称两次32位的读写，这样就有可能造成非原子性的数据安全问题。但是由于局部变量表是线程的堆栈元素，是线程私有的数据，所以读写两个连续的Slot无论是否原子操作，都不会造成数据安全问题。

虚拟机使用局部变量表通过索引定位，索引范围从0开始到Slot最大数量结束。对于32位数据类型的变量，索引n代表使用第n个Slot；对于64位数据类型的变量，则会使用第n和n+1个Slot。虚拟机规范不允许单独访问其中某一个。

如果虚拟机执行的是实例方法，而非static方法，局部变量表中索引为0的Slot默认用来传递方法所属实例对象的引用，在方法中用关键字“this”来访问这个隐含参数。其余参数按照参数表的顺序，从1开始占用其他Slot。

原理

以上对于虚拟机运行时数据区的栈帧和局部变量表做了简单介绍之后，我们回头再来看看本文一开始讲到的垃圾回收问题。示例三种加了一行 int guoguo = 0 的代码之后，就能正确回收placeholder变量了，这是什么原因呢？

在公布真相之前，我们首先要了解到一个事实，那就是局部变量表里的Slot是可以重用的。这么做的目的是为了节省更多的栈帧空间。在同一个方法体中，某个变量不可能覆盖整个方法。例如示例三种GuoGuoTest的main方法，placeholder变量被花括号包裹之后的作用域只限于花括号里面。此时，当字节码PC计数器的值已经超出placeholder的作用域时，那么placeholder对应的Slot就应该释放出来交由其他变量使用。

public class GuoGuoTest {
    public static void main(String[] args) {
        {
            byte[] placeholder = new byte[64 * 1024 * 1024];
        }
        int guoguo = 0;
        System.gc();
    }
}

placeholder能否被回收的根本原因是：局部变量表中的Slot是否还存有关于placeholder数组对象的引用。示例二中，当还没有 int guoguo = 0 这行代码的时候，代码虽然已经离开了placeholder变量的作用域，但之后没有对局部变量表的任何其他读写操作，placeholder占用的Slot也就不会被其他变量所复用，所以作为GC Roots一部分的局部变量表仍然保持着对它的关联。在绝大多数时候，这种情况造成的影响非常小。但是如果后面的代码非常耗时，而前面又定义了大量占用内存又实际不再使用的变量，那么手动将其设为null就变得非常具有意义。当然，这种情况非常罕见，一般我们也没有必要所有的变量都手动设为null，并且代码在经过JIT编译之后会将赋null值的操作给消除掉，所以从编码的角度来说，最优雅的解决方式还是通过变量的作用域来控制变量回收的时间。

局部变量初始化

文章最后，再写一点关于局部变量的小知识。类变量有两次赋初值的过程，准备阶段赋予系统初始值；初始化阶段赋予程序员定义的初始值。例如，int类型的类变量会首先被赋予系统初始值0，如果程序员的代码没有显式给其赋值，那么也没有关系，类变量仍然有一个确定的系统初始值。但是局部变量则不同，如果一个局部变量只声明没有初始化，编译器是会报错的，即使编译器不提示错误直接手动生成字节码，字节码校验的时候也会被虚拟机发现而类加载失败。