在《JVM 之1、 运行时数据区》提到，虚拟机栈是 描述Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧（Stack Frame）用于存储局部变量表、操作数栈、动态链接、方法出口等信息。本篇主要分析局部变量表的原理结构。
局部变量表是一组变量值存储空间，用于存放方法参数和方法内部定义的局部变量。在Java程序被编译为Class文件时，就在方法的Code属性的max_locals数据项中确定了方法所需要分配的最大局部变量表的容量。
局部变量表的容量以变量槽（Variable Slot）为最小单位，虚拟机规范中并没有明确指明一个Slot暂用的内存空间大小，只是很有“导向性”地说明每个Slot都应该能存放一个boolean,byte,char,short,int,float,refrence,returnAddress类型的数据，这种描述明确指出 “每个Slot占用32位长度的内存空间” 有一些差别，它允许Slot的长度随着处理器，操作系统或虚拟机的不同而发生变化。不过无论如何，即使在64位虚拟机中使用64位长度的内存空间来实现Slot,虚拟机仍要使用对齐和补白的手段让Slot在外观上看起来和32位虚拟机中得一致。
既然前面提到了数据类型，在此顺便说一下，一个Slot可以存放一个32位以内的数据类型，Java中用32位以内的数据类型有:boolean,byte,char,short,int,float,reference,returnAddress八种类型。reference是对象的引用。虚拟机规范即没有说明它的长度，也没有明确指出这个引用应由怎样的结构，一般来说，虚拟机实现至少都应当能从此引用中直接或间接的查找到对象在Java堆中得起始地址索引和方法区中得对象类型数据。而returnAddress是为字节码指令jsr,jsr_w 和 ret服务的。它指向了一条字节码指令的地址。
对于64位的数据类型，虚拟机会以高位在前的方式为其分配两个连续的Slot空间。Java语言中明确规定的64位的数据类型只有long和double数据类型分割存储的做法与"long和double的非原子性协定" 中把一次long 和double 数据类型读写分割为两次32位读写的做法类似，在阅读JAVA内存模型时对比下。不过，由于局部变量表建在线程的堆栈上，是线程私有的数据，无论读写两个连续的Slot是否是原子操作，都不会引起数据安全问题。
虚拟机通过索引定位的方式使用局部变量表，索引值的范围是从0开始到局部变量表最大的Slot数量。如果32位数据类型的变量，索引N就代表了使用第N个Slot，如果是64位数据类型的变量，则说明要使用第N个和N+1两个Slot。
在方法执行时，虚拟机是使用局部变量表完成参数值到参数变量列表的传递过程。如果是实例方法（非static的方法），那么局部变量表中第0位索引的Slot默认是用于传递方法所属对象实例的引用，在方法中可以通过关键字this来访问这个隐含的参数，其余参数则按照参数表的顺序来排列，暂用从1开始的局部变量Slot，参数表分配完毕后，在根据方法体内部定义的变量顺序和作用域分配其余的Slot。
局部变量表中得slot是可重用的，方法体定义的变量，其作用域并不一定会覆盖整个方法体，如果当前字节码PC计数器的值已经超过了某个变量的作用域，那么这个变量对应的Slot就可以交给其他变量使用。这样的设计不仅仅是为了节省栈空间，在某些情况下Slot的复用会直接影响到系统的垃圾收集行为。例如如下代码：
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 byte[]_64M=new****byte[1024*1024*64];；
8、 System.gc();；
9、 }；
10、 }；
运行结果：
[GC 66558K->65952K(129024K), 0.0015650 secs]
[Full GC 65952K->65853K(129024K), 0.0122710 secs]
从运行结果分析，发现System.gc()运行后并没有回收掉这64M的内存。
没有回收掉"_64M"的内存能说的过去，因为在执行System.gc()时，变量_64M还处于作用域之内，虚拟机自然不敢回收掉该内存。我们把代码位如下：
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 {；
8、 byte[]_64M=new****byte[1024*1024*64];；
9、 }；
10、 System.gc();；
11、 }；
12、 }；
从代码逻辑上将，在执行System.gc()的时候，变量“_64M”已经不可能在被访问了，但执行以下这段程序，会发现运行结果如下：
[GC 66558K->65968K(129024K), 0.0014760 secs]
[Full GC 65968K->65853K(129024K), 0.0127180 secs]
这是为什么呢？
在解释为什么之前，我们先对代码进行第二次修改。在调用 System.gc()之前加入代码int x=0, 这个修改看起来莫名其妙，但运行以下程序，却方法这次内存针对被正确回收了。
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 {；
8、 byte[]_64M=new****byte[1024*1024*64];；
9、 }；
10、 intx=0;；
11、 System.gc();；
12、 }；
13、 }；
[GC 66558K->65936K(129024K), 0.0027120 secs]
[Full GC 65936K->317K(129024K), 0.0129600 secs]
局部变量"_64M"能否被回收的根本原因就是：局部变量表中得Slot是否还存有关于_64M数组对象的引用。第一次修改，代码虽然离开了_64的作用域，但在此之后，没有任何对局部变量表的读写操作，_64M 原本所占用的Slot还没有被其他变量所复用，所以作为GC Roots 一部分的局部变量表让然保持对它的关联。这种关联没有被及时打断，在绝大部分情况下都很轻微。但如果遇到一个方法，其后面的代码有一些耗时很长的操作，而前面又占用了大量的内存，实际上已经不会在被使用的变量，手工将其设置为NULL值(用来代替int x=0)把变量对应的局部变量表Slot情况，就不是一个毫无意义的操作，这种操作可以作为 一种在及特殊情形（对象暂用内存大，此方法的栈帧长时间不能被回收，方法调用次数达不到JIT编译条件）下得“奇技” 来使用。但不应当对赋null值操作有过多的依赖，也没有必要把它当做一个普遍的编码方法来推广，以恰当的变量作用域来控制变量回收时间才是最优雅的解决方法。
另外，赋null值的操作在经过虚拟机JIT编译器优化之后会被消除掉，这时候将变量设置为null实际上是没有意义的。字节码被编译为bending代码后，对GC Roots的枚举也与解释执行时期有所差别，在经过JIT编译后，System.gc()执行时就可以正确的回收掉内存。
打印GC详细日志还可以加上参数：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 byte[]_64M=new****byte[1024*1024*64];；
8、 System.gc();；
9、 }；
10、 }；
运行结果：
[GC 66558K->65952K(129024K), 0.0015650 secs]
[Full GC 65952K->65853K(129024K), 0.0122710 secs]
从运行结果分析，发现System.gc()运行后并没有回收掉这64M的内存。
没有回收掉"_64M"的内存能说的过去，因为在执行System.gc()时，变量_64M还处于作用域之内，虚拟机自然不敢回收掉该内存。我们把代码位如下：
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 {；
8、 byte[]_64M=new****byte[1024*1024*64];；
9、 }；
10、 System.gc();；
11、 }；
12、 }；
从代码逻辑上将，在执行System.gc()的时候，变量“_64M”已经不可能在被访问了，但执行以下这段程序，会发现运行结果如下：
[GC 66558K->65968K(129024K), 0.0014760 secs]
[Full GC 65968K->65853K(129024K), 0.0127180 secs]
这是为什么呢？
在解释为什么之前，我们先对代码进行第二次修改。在调用 System.gc()之前加入代码int x=0, 这个修改看起来莫名其妙，但运行以下程序，却方法这次内存针对被正确回收了。
[java] view plain copy
1、 /**；
2、 *VMargs:-verbose:gc；
3、 *；
4、 */；
5、 public****classGCTest{；
6、 publicstaticvoidmain(String[]args){；
7、 {；
8、 byte[]_64M=new****byte[1024*1024*64];；
9、 }；
10、 intx=0;；
11、 System.gc();；
12、 }；
13、 }；
[GC 66558K->65936K(129024K), 0.0027120 secs]
[Full GC 65936K->317K(129024K), 0.0129600 secs]
局部变量"_64M"能否被回收的根本原因就是：局部变量表中得Slot是否还存有关于_64M数组对象的引用。第一次修改，代码虽然离开了_64的作用域，但在此之后，没有任何对局部变量表的读写操作，_64M 原本所占用的Slot还没有被其他变量所复用，所以作为GC Roots 一部分的局部变量表让然保持对它的关联。这种关联没有被及时打断，在绝大部分情况下都很轻微。但如果遇到一个方法，其后面的代码有一些耗时很长的操作，而前面又占用了大量的内存，实际上已经不会在被使用的变量，手工将其设置为NULL值(用来代替int x=0)把变量对应的局部变量表Slot情况，就不是一个毫无意义的操作，这种操作可以作为 一种在及特殊情形（对象暂用内存大，此方法的栈帧长时间不能被回收，方法调用次数达不到JIT编译条件）下得“奇技” 来使用。但不应当对赋null值操作有过多的依赖，也没有必要把它当做一个普遍的编码方法来推广，以恰当的变量作用域来控制变量回收时间才是最优雅的解决方法。
另外，赋null值的操作在经过虚拟机JIT编译器优化之后会被消除掉，这时候将变量设置为null实际上是没有意义的。字节码被编译为bending代码后，对GC Roots的枚举也与解释执行时期有所差别，在经过JIT编译后，System.gc()执行时就可以正确的回收掉内存。
打印GC详细日志还可以加上参数：
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps