点击上方“java大数据修炼之道”，选择“设为星标”
优质文章, 第一时间送达
==================
作者 ：zhantong
前言
许多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 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“时大胆去用，但不应当对其有过多依赖，更不能当作是一个普遍规则来推广。
1 有热门推荐👇 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 灵魂拷问：你写的SQL一般有几个join ？ 33 34 35 36 37 38 39 40 41 42 43 44 30 分钟学会如何使用 Shiro 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 JVM 史上最最最完整深入解析 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 5分钟 教大家搭建免费个人博客 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 太火了，这些牛逼的Java代码技巧，肯定能让你目瞪口呆！ 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 300 行代码带你秒懂 Java 多线程！ 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 非常有意思的SQL优化经历:从30248.271s到0.001s 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 绝对干货: 在Java项目中打印错误日志的正确姿势，排查问题更方便，非常实用！ 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 干货分享：扫码关注下面的公众号后台回复“资源”领取1T编程资源，里面包含各种学习资料。帮助大家更快的学习编程与进阶+资料想充电就关注Java大数据修炼之道 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 - end - 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 关注Java大数据修炼之道每天学习Java技术，你想学的Java知识这里都有！ 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297
文章有帮助的话，在看
，转发吧。
谢谢支持哟 (*^__^*)
本文分享自微信公众号 - java大数据修炼之道（Java_Bigdata_Study）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。