经常听说“不使用的对象应手动赋值为null”，但是要问原因，大都回答“有利于GC更早回收内存，减少内存占用”，但再往深入问就回答不出来了。所以这里做一点深入研究。
一、将对象赋值为null，对垃圾回收有用吗？
网上很多java性能优化里都会有这么一条：尽量把不使用的对象显式得置为null，这样有助于内存回收。
可以明确的说，这个观点是基本没必要的。sun jdk 远比我们想象中的机智，完全能判断出对象是否已经 no ref。但是我上面用的词是"基本"，也就是说，有例外的情况。这个例外的情况是：方法前面中有定义大的对象，然后又跟着非常耗时的操作，且没有触发JIT编译。总结这句话就是：
除非在一个方法中，定义了一个非常大的对象，并且在后面又跟着一段非常耗时的操作，并且该方法没有满足 JIT 编译条件，否则显式得设置 obj = null 是完全没必要的。上面这句话有点绕，但是上面说的每一个条件都是有意义的，这些条件分别是：
（1）同一个方法中
（2）定义了一个大对象(小对象没有意义)
（3）之后跟着一个非常耗时的操作
（4）没有满足JIT编译条件
上面4个条件缺一不可，这样把 obj 显式设置成 null 才是有意义的。
1、同一个方法中：这个条件是最容易理解的，如果大对象定义在其他方法中，那么是不需要设置成Null的。
public static void main(String[] args){
foo();
System.gc();
}
public static void foo(){
byte[] placeholder = new byte[64*1024*1024];
}
其实很好理解：placeholder是foo方法的局部变量，在main方法中调用的时候，其实foo方法对应的栈帧已经结束。那么placeholder指向的大对象自然被gc的时候回收了。
2、定义了一个大对象：这句话的意思也很好理解，只有定义的是大的对象，我们才需要关心他尽快被回收。如果你只是定义了一个 String str = "abc"; 后续手动设置成null让gc回收是没有任何意义的。
3、后面跟着一个非常耗时的操作：这里理解是后面的这个耗时的可能超过了一个GC的周期。
public static void main(String[] args) throws Exception{
byte[] placeholder = new byte[64*1024*1024];
Thread.sleep(3000l);
// dosomething
}
在线程sleep的三秒内，可能jvm已经进行了好几次gc，但是由于placeholder一直持有这个大对象，所以造成这个64M的大对象一直无法被回收，甚至有可能造成了满足进入old 区的条件。这个时候在sleep之前显式得把placeholder设置成Null是有意义的。但是如果没有这个耗时的操作，main方法可以非常快速的执行结束，方法返回，同时也会销毁对应的栈帧。那么就是回到第一个条件，方法已经执行结束，在下一次gc的时候，自然就会把对应的"垃圾"给回收掉。
具体分析见这篇文章：https://blog.csdn.net/qq_42945742/article/details/84107531
二、问题背景
我们来看一段非常简单的代码：
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的问题，为什么 placeHolder 不赋值为null，GC 就“发现不了” placeHolder 该回收呢？这才是问题的关键所在。
三、运行时栈
1、典型的运行时栈
如果你了解过编译原理，或者程序执行的底层机制，你会知道方法在执行的时候，方法里的变量（局部变量）都是分配在栈上的；当然，对于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 |
容易理解吧？其实仔细想想上面这个例子的运行时栈是有优化空间的。
2、Java的栈优化
上面的例子，main()方法运行时占用了4个栈索引空间，但实际上不需要占用这么多。当if执行完后，变量a、b和c都不可能再访问到了，所以它们占用的1～3的栈索引是可以“回收”掉的，比如像这样：
| 索引 | 变量 |
|---|---|
| 1 | a |
| 2 | b |
| 3 | c |
| 1 | d |
变量d重用了变量a的栈索引，这样就节约了内存空间。
上面的“运行时栈”和“索引”是为方便引入而故意发明的词，实际上在JVM中，它们的名字分别叫做“局部变量表”和“Slot”。而且局部变量表在编译时即已确定，不需要等到“运行时”。
局部变量表用于存放方法中的局部变量和方法参数，局部变量表用 Slot 为单位。jvm在实现的时候为了节省栈帧空间，做了一个简单的优化，就是slot的复用。如果当前字节码的PC计数器已经超出某些变量的作用域，那么这些变量的 slot 就可以给其他的复用。方法的局部变量表大小在javac的时候就已经确定了。
3、如何确定对象可以被 GC 回收
这里来简单讲讲主流GC里非常简单的一小块，另一种表达是，如何确定对象是存活的。仔细想想，Java的世界中，对象与对象之间是存在关联的，我们可以从一个对象访问到另一个对象。如图所示。
再仔细想想，这些对象与对象之间构成的引用关系，就像是一张大大的图；更清楚一点，是众多的树。
如果我们找到了所有的树根，那么从树根走下去就能找到所有存活的对象，那么那些没有找到的对象，就是已经死亡的了！这样GC就可以把那些对象回收掉了。
现在的问题是，怎么找到树根呢？JVM早有规定，其中一个就是：栈中引用的对象。也就是说，只要堆中的这个对象，在栈中还存在引用，就会被认定是存活的。
这就是：确定对象可以被回收的算法，其名字是“可达性分析算法”。
基础知识：
1、sun jdk的内存垃圾判定是基于根搜索算法的。也就是说在GC root为根，能被搜索到的，就认为是存活对象，搜索不到的，则认为是"垃圾"。
2、啥是 gc root。
Local variable. For example, input parameters or locally created objects of methods that are still in the stack of a thread.
这句话直接翻译就是说是"本地变量,例如方法的参数或者方法中创建的局部变量"，如果换一种说法是：Java 方法栈（Java Method Stack）的局部变量表（Local Variable Table）中引用的对象。
在局部变量表的 slot 持有的某个对象，他是无法被垃圾回收的，因为局部变量表本来就是GC Root之一。
四、JVM的“bug”
我们再来回头看看最开始没有设置为 null 的例子，看看其运行时栈：
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 被成功回收了！我们的推断也被验证了。
再从运行时栈来看，加上 nt replacer = 1; 和将 placeHolder 赋值为 null 起到了同样的作用：断开堆中 placeHolder 和栈的联系，让GC判断placeHolder已经死亡。
现在算是理清了“不使用的对象应手动赋值为null“的原理了，一切根源都是来自于JVM的一个“bug”：代码离开变量作用域时，并不会自动切断其与堆的联系。
需要对局部变量表的重写才会重用 slot，这样才会端开 栈 中的引用与 堆 的联系。为什么这个“bug”一直存在？你不觉得出现这种情况的概率太小了么？算是一个tradeoff（权衡）了。
看到这里你已经明白了“不使用的对象应手动赋值为null“这句话背后的奥义，正如《深入理解Java虚拟机》作者的观点：在需要“不使用的对象应手动赋值为null”的时大胆去用，但不应当对其有过多依赖，更不能当作是一个普遍规则来推广。