内存管理
【虚拟机栈】
一： java栈在java虚拟机结构中的位置
java虚拟机体系结构中包括：类装载子系统、运行时数据区、执行引擎。
其中类装载子系统负责查找并装载class文件。
执行引擎处于JVM的核心位置，运行Java的每一个线程都是一个独立的虚拟机执行引擎的实例，从线程生命周期的开始到结束，他要么在执行字节码，要么在执行本地方法。
运行时数据区包括方法区、java堆、java栈、程序计数器和本地方法区。
二： java栈的组成
栈的基本单位是帧（或栈帧）： 每当一个java线程运行的时候， java虚拟机会为该线程分配一个java栈。
该线程在执行某个java方法的时候， 向java栈压入一个帧， 这个帧用于存储参数、局部变量、操作数、中间运算结果等。当这个方法执行完的时候， 帧会从栈中弹出。
Java栈上的所有数据是私有的，其他线程都不能该线程的栈数据。
栈帧由局部变量区、操作数栈和帧数据区三个部分组成。
（1） 局 部变量区：局部变量区大小按字长计算，局部变量区的大小在编译的时候可以预知： 局部变量区被组织成一个以字长为单位的数组，每个局部变量的空间是32位 的，基本类型byte、char、short、boolean、int、float及对象引用等占一个局部变量空间， long、double占两个局部变量空间。在访问long和double类型的局部变量时，只需要取第一个变量空间的索引即可。
（2） 操作数栈： 操作数栈和局部变量区一样，也被组织成一个以字长为单位的数组。但和前者不同的是，它不是通过索引来访问的，而是通过入栈和出栈来访问的。操作数栈是临时数据的存储区域。
view plaincopy to clipboardprint?·········10········20········30········40········50········60········70········80········90········100·······110·······120·······130·······140·······150float subTotal = 100; float tax = 5; float total = subTotal + tax;
在操作数栈的运行过程：1. 将100压入操作数栈 2. 将5压入操作数栈 3. 将100和5从栈中弹出，执行add指令，将结果105压入操作数栈 4.从栈中弹出结果105返回。
（3）帧数据区： 帧数据区存放了指向常量池的指针地址，当某些指令需要获得常量池的数据时，通过帧数据区中的指针地址来访问常量池的数据。此外，帧数据区还存放方法正常返回和异常终止需要的一些数据。
三： 栈内存的优点和缺点
java虚拟机中变量存储相关的内存分为栈内存和堆内存。在方法中定义的一些基本类型的变量和对象的引用变量都在栈内存中分配，对象实例和数组在堆内存分配。
栈的优点：
1. 存取速度比堆要快，仅次于直接位于CPU中的寄存器；
2. 栈数据可以共享。
view plaincopy to clipboardprint?int first = 100; int second = 100;
编译器先处理int first = 100；首先它会在栈中创建一个变量为a的引用，然后查找有没有字面值为100的地址，没找到，就开辟一个存放100这个字面值的地址，然后将first指向100的地址。接着处理int second = 100；在创建完second的引用变量后，由于在栈中已经有100这个字面值，便将second直接指向100的地址。这样，就出现了first与second同时均指向100的情况, 起到数据共享的作用。
栈的缺点： 栈中的数据大小与生存期必须是确定的，缺乏灵活性， 相反，堆内存中的数据在运行期动态分配，比较灵活。但是堆内存的数据需要jvm的垃圾回收机制来回收不再使用的对象。
在java虚拟机规范里，JVM被分为7个内存区域。
——虚拟器规范中的7个内存区域分别是三个线程私有的和四个线程共享的内存区,线程私有的内存区域与线程具有相同的生命周期，它们分别是： 指令计数器、 线程栈和本地线程栈
——四个共享区是所有线程共享的，在JVM启动时就会分配,分别是：方法区、 常量池、直接内存区和堆。
——指令计数器。我们都知道java的多线程是通过JVM切换时间片运行的，因此每个线程在某个时刻可能在运行也可能被挂起，那么当线程挂起之后，JVM再次调度它时怎么知道该线程要运行那条字节码指令呢？这就需要一个与该线程相关的内存区域记录该线程下一条指令，而指令计数器就是实现这种功能的内存区域。有多少线程在编译时是不确定的，因此该区域也没有办法在编译时分配，只能在创建线程时分配，所以说该区域是线程私有的，该区域只是指令的计数，占用的空间非常少，所以虚拟机规范中没有为该区域规定OutofMemoryError。
——线程栈。
class Test{
public static void main(String[] args) {
Thread th = new Thread();
th.start();
}
}
在运行以上代码时，JVM将分配一块栈空间给线程th，用于保存方法内的局部变量，方法的入口和出口等，这些【局部变量】包括基本类型和对象引用类型，这里可能有人会问，java的对象引用不是分配在堆上吗？有这样疑惑的人，可能是没有理解java中引用和对象之间的区别，当我们写出以下代码时:
public Object test() 【方法的栈帧】
{
Object obj = new Object();
return obj;
}
其中的Object obj就是我们所说的引用类型，这样的声明本身是要占用4个字节，而这4个字节在这里就是在栈空间里分配的，准确的说是在线程栈中为test方法分配的栈帧中分配的，当方法退出时，将会随栈帧的弹出而自动销毁，而new Object()则是在堆中分配的，由GC在适当的时间收回其占用的空间。每个栈空间的默认大小为0.5M，在1.7里调整为1M，每调用一次方法就会压入一个栈帧，如果压入的栈帧深度过大，即方法调用层次过深,就会抛出StackOverFlow,，SOF最常见的场景就是递归中，当递归没办法退出时，就会抛此异常，Hotspot提供了参数设置改区域的大小，使用-Xss：xxK，就可以修改默认大小。
3 本地线程栈.顾名思义，该区域主要是给调用本地方法的线程分配的，该区域和线程栈的最大区别就是，在该线程的申请的内存不受GC管理，需要调用者自己管理，JDK中的Math类的大部分方法都是本地方法，一个值得注意的问题是,在执行本地方法时，并不是运行字节码，所以之前所说的指令计数器是没法记录下一条字节码指令的，当执行本地方法时，指令计数器置为undefined。
接下来是四个线程共享区。
1 方法区。这块区域是用来存放JVM装载的class的类信息，包括：类的方法、静态变量、类型信息(接口/父类)，我们使用反射技术时，所需的信息就是从这里获取的。
2 常量池。当我们编写如下的代码时：
class Test1{
private final int size=50;
}
这个程序中size因为用final修饰，不能再修改它的值，所以就成为常量，而这常量将会存放在常量区，这些常量在编译时就知道占用空间的大小，但并不是说明该区域编译就固定了，运行期也可以修改常量池的大小，典型的场景是在使用String时，你可以调用String的 intern()，JVM会判断当前所创建的String对象是否在常量池中，若有，则从常量区取，否则把该字符放入常量池并返回,这时就会修改常量池的大小，比如JDK中java.io.ObjectStreamField的一段代码:
String的 intern()方法返回一个字符串对象的内部化引用。众所周知：String类维护一个初始为空的字符串的对象池，当intern方法被调用时，如果对象池中已经包含这一个相等的字符串对象则返回对象池中的实例，否则添加字符串到对象池并返回该字符串的引用。
....
ObjectStreamField(Field field, boolean unshared, boolean showType) {
this.field = field;
this.unshared = unshared;
name = field.getName();
Class ftype = field.getType();
type = (showType || ftype.isPrimitive()) ? ftype : Object.class;
signature = ObjectStreamClass.getClassSignature(ftype).intern();
}
这段代码将获取的类的签名放入常量池。HotSpot中并没有单独为该区域分配，而是合并到方法区中。
3 直接内存区。直接内存区并不是JVM可管理的内存区。在JDK1.4中提供的NIO中，实现了高效的R/W操作，这种高效的R/W操作就是通过管道机制实现的，而管道机制实际上使用了本地内存，这样就避免了从本地源文件复制JVM内存，再从JVM复制到目标文件的过程，直接从源文件复制到目标文件，JVM通过DirectByteBuffer操作直接内存。
4 堆。主角总是最后出场，堆绝对是JVM中的一等公民，绝对的主角，我们通常所说的GC主要就是在这块区域中进行的，所有的java对象都在这里分配，这也是JVM中最大的内存区域，被所有线程共享，成千上万的对象在这里创建，也在这里被销毁。
java内存分配到这就算是一个完结了，接下来我们将讨论java内存的回收机制
第一，局部变量占用内存的回收，所谓局部变量，就是指在方法内创建的变量，其中变量又分为基本类型和引用类型。如下代码:
...
public void test()
{
int x=1;
char y='a';
long z=10L;
}
变量x y z即为局部变量，占用的空间将在test()所在的线程栈中分配，test()执行完了后会自动从栈中弹出，释放其占用的内存，再来看一段代码：
....
public void test2()
{
Date d = new Date();
System.out.println("Now is "+d);
}
我们都知道上述代码会创建两个对象，一个是Date d另一个是new Date。Date d叫做声明了一个date类型的引用，引用就是一种类型，和int x一样，它表明了这种类型要占用多少空间，在java中引用类型和int类型一样占用4字节的空间，如果只声明引用而不赋值，这4个字节将指向JVM中地址为0的空间，表示未初始化，对它的任何操作都会引发空指针异常。
如果进行赋值如d = new Date()那么这个d就保存了new Date（）这个对象的地址，通过之前的内存分配策略，我知道new Date（）是在jvm的heap中分配的，其占用的空间的回收我们将在后面着重分析，这里我们要知道的是这个Date d所占用的空间是在test2()所在的线程栈分配的，方法执行完后同样会被弹出栈，释放其占用的空间。
第二.非局部变量的内存回收,在上面的代码中new Date()就和C++里的new创建的对象一样，是在heap中分配，其占用的空间不会随着方法的结束而自动释放需要一定的机制去删除，在C++中必须由程序员在适当时候delete掉，在java中这部分内存是由GC自动回收的，但是要进行内存回收必须解决两问题：那些对象需要回收、怎么回收。
判定那些对象需要回收，我们熟知的有以下方法：
一，引用计数法，这应是绝大数的的java 程序员听说的方法了，也是很多书上甚至很多老师讲的方法，该方法是这样描述的，为每个对象维护一个引用计数器，当有引用时就加1，引用解除时就减1，那些长时间引用为0的对象就判定为回收对象，理论上这样的判定是最准确的，判定的效率也高，但是却有一个致命的缺陷，请看以下代码：
package com.mail.czp;
import java.util.ArrayList;
import java.util.List;
public class Test {
private byte[] buffer;
private List ls;
public Test() {
this.buffer = new byte[4*1024*1024];
this.ls = new ArrayList();
}
private List getList() {
return ls;
}
public static void main(String[] args) {
Test t1 = new Test();
Test t2 = new Test();
t1.getList().add(t2);
t2.getList().add(t1);
t1 = t2 = null;
Test t3 = new Test();
System.out.println(t3);
}
}
我们用以下参数运行：-Xmx10M -Xms10M M 将jvm的大小设置为10M，不允许扩展，按引用计数法，t1和t2相互引用，他们的引用计数都不可能为0，那么他们将永远不会回收，在我们的环境中JVM共10M，t1 t2占用8m，那么剩下的2M，是不足以创建t3的，理论上应该抛出OOM。但是，程序正常运行了，这说明JVM应该是回收了t1和t2的我们加上-XX:+PrintGCDetails运行，将打印GC的回收日记:
[GC [DefNew: 252K->64K(960K), 0.0030166 secs][Tenured: 8265K->137K(9216K), 0.0109869 secs] 8444K->137K(10176K), [Perm : 2051K->2051K(12288K)], 0.0140892 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]
com.mail.czp.Test@2ce908
Heap
def new generation total 960K, used 27K [0x029e0000, 0x02ae0000, 0x02ae0000)
eden space 896K, 3% used [0x029e0000, 0x029e6c40, 0x02ac0000)
from space 64K, 0% used [0x02ad0000, 0x02ad0000, 0x02ae0000)
to space 64K, 0% used [0x02ac0000, 0x02ac0000, 0x02ad0000)
tenured generation total 9216K, used 4233K [0x02ae0000, 0x033e0000, 0x033e0000)
the space 9216K, 45% used [0x02ae0000, 0x02f02500, 0x02f02600, 0x033e0000)
compacting perm gen total 12288K, used 2077K [0x033e0000, 0x03fe0000, 0x073e0000)
the space 12288K, 16% used [0x033e0000, 0x035e74d8, 0x035e7600, 0x03fe0000)
No shared spaces configured.
从打印的日志我们可以看出，GC照常回收了t1 t2,这就从侧面证明jvm不是采用这种策略判定对象是否可以回收的。
二，根搜索算法，这是当前的大部分虚拟机采用的判定策略，GC线程运行时，它会以一些特定的引用作为起点称为GCRoot，从这些起点开始搜索，把所用与这些起点相关联的对象标记，形成几条链路，扫描完时，那些没有与任何链路想连接的对象就会判定为可回收对象。具体那些引用作为起点呢，一种是类级别的引用：静态变量引用、常量引用，另一种是方法内的引用，如之前的test()方法中的Date d对new Date()的引用，在我们的测试代码中，在创建t3时，jvm发现当前的空间不足以创建对象，会出发一次GC，虽然t1和t2相互引用，但是执行t1=t2=null后，他们不和上面的3个根引用中的任何一个相连接，所以GC会判定他们是可回收对象，并在随后将其回收，从而为t3的创建创造空间，当进行回收后发现空间还是不够时，就会抛出OOM。
接下来我们就该讨论GC 是怎么回收的了，目前版本的Hotspot虚拟机采用分代回收算法，它把heap分为新生代和老年代两块区域,如下图:
默认的配置中老年代占90% 新生代占10%，其中新生代又被分为一个eden区和两个survivor区，每次使用eden和其中的一个survivor区，一般对象都在eden和其中的一个survivor区分配，但是那些占用空间较大的对象，就会直接在老年代分配，比如我们在进行文件操作时设置的缓冲区，如byte[] buffer = new byte[1024*1024],这样的对象如果在新生代分配将会导致新生代的内存不足而频繁的gc，GC运行时首先会进行会在新生代进行，会把那些标记还在引用的对象复制到另一块survivor空间中，然后把整个eden区和另一个survivor区里所有的对象进行清除，但也并不是立即清除，如果这些对象重写了finalize方法，那么GC会把这些对象先复制到一个队列里，以一个低级别的线程去触发finalize方法，然后回收该对象，而那些没有覆写finalize方法的对象，将会直接被回收。在复制存活对象到另一个survivor空间的过程中可能会出现空间不足的情况，在这种情况下GC回直接把这些存活对象复制到老年代中，如果老年代的空间也不够时，将会触发一次Full GC,Full gc会回收老年代中那些没有和任何GC Root相连的对象，如果Full GC后发现内存还是不足，将会出现OutofMemoryError。
Hotspot虚拟机下java对象内存的分配和回收就算完结了，后续我们将讨论java代码的重构。
