北京网站建设联系电话,长春市网络科技有限公司,网易企业邮箱登录v,专业北京seo公司在java方法中#xff0c;不使用的对象是否应该手动赋值为null#xff1f;我们先来通过一个示例看一下。
垃圾回收示例一
public class GuoGuoTest {public static void main(String[] args) {byte[] placeholder new byte[64 * 1024 * 1024];System.gc();}
}
上面代码向内…在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和n1个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如果程序员的代码没有显式给其赋值那么也没有关系类变量仍然有一个确定的系统初始值。但是局部变量则不同如果一个局部变量只声明没有初始化编译器是会报错的即使编译器不提示错误直接手动生成字节码字节码校验的时候也会被虚拟机发现而类加载失败。
