JAVA 虚拟机深入研究(二)——JVM虚拟机发展以及一些Java的新东西
Java与C++之间有一堵由内存动态分配和垃圾收集技术所围成的围城，城外的人想进去，城里的人想出来。
Java运行的时候会把内存分为若干个，他们各有各的用途，每块区域的创建和销毁都是相对独立的，有的跟虚拟机一起混，有的则抱着用户的大腿同生共死。
按照第七版的《Java虚拟机规范》规定，JVM所管理的内存包括以下几个区域。
1.1 程序计数器（Program Counter Register）
这块内存区比较小，按照概念模型（各种虚拟机可能不按照概念模型，而采用自己的更高效的方式来搞定），字节码解释器就通过这个计数器来寻去下一个字节码指令，分支，循环，跳转，异常处理，线程回复等都需要这个东西来完成。
Java虚拟机多线程采用时间片轮转的方式，所以同一时刻，一个内核只能执行一个线程中的指令。因此，为了当获取到时间片之后线程可以正常恢复执行，每个线程都需要有自己的线程计数器，这种内存称为“线程私有”的内存。
如果线程执行的是Java方法，这个计数器就存储正在执行的字节码指令地址，如果线程执行的是Native方法，那么这个计数器就是空的（undefined）。
这个内存区域是唯一一个在Java虚拟机规范中没有规定任何OOM（OutOfMemoryError）情况的区域。
1.2 Java虚拟机栈（Java Virtual Machine Stacks）
跟计数器一样，这个区域也是线程私有的，跟线程同生共死。这个区域描述了Java方法执行的内存模型：没个方法执行的时候创建一个栈帧（回头再讲），存储局部变量表，操作数栈，动态链接，方法出口等信息。一个方法开始执行，栈帧就会在虚拟机栈中入栈，方法执行完成后出栈。Java虚拟机规范中规定，如果线程请求的栈深大鱼虚拟机允许的深度，就跑出StackOverFlowError，如果虚拟机栈允许动态扩展（多数都能，也可以固定），那就扩展，如果扩展的时候发现内存不足，跑出OutOfMemoryError。
有的人会把Java的内存草草的分为两部分，一部分叫堆，另一部分叫栈，这个分法太粗糙，实际上要复杂很多，不过其中的栈指的就是这个虚拟机栈里面所说的局部变量表。
局部变量表存储了基本数据类型（八种），returnAddress类型（指向一个字节码指令地址）和引用类型，引用类型包含两种种，第一可能是指向对象起始位置的引用指针，第二可能是指向一个代表对象句柄或者其他与这个对象相关的位置。
除了两个64位的数据类型（long，double）占用两个局部变量空间（Slot），其余的都只占用一个。局部变量表的内存空间在编译器就已经分配完成了，运行时不会改变局部变量表的大小。
1.3 本地方法栈（Native Method Stack）
跟虚拟机栈功能类似，区别在于这个栈服务于Native方法，而虚拟机栈服务于Java方法（字节码）。规范中没有对这个区域的实现做出明确的要求，所以相应的这个区域的实现就显得比较自由，像HotSpot就很干脆的直接和虚拟机栈合二为一。
1.4 Java堆（Java Heap）
多数的应用中堆都是虚拟机中最大的一块内存，按照虚拟机规范要求，所有的对象实例以及数组都要在堆上分配，随着JIT编译器的发展以及逃逸分析技术的成熟，栈上分配、标量替换优化技术就会带来一些新的变化，所有的对象都分配在对上就不是那么绝对了。
Java的堆是垃圾回收的大头，因此有时候会称为GC堆。由于现在多数GC都采用的是分代垃圾回收算法，所以对堆还可以细分，比如新生代，老年代。要是再详细一点，就有Eden空间，From Survivor，To Survivor等（前面提到过）。
规范中并没有要求堆在内存上的物理连续性，只要保证逻辑连续即可，设计实现的时候可以固定大小，也可以扩展，现在主流的都可以扩展（利用-Xmx和-Xms控制），如果碰到扩展时内存不够的情况，就会抛出OutOfMemoryError。
1.5 方法区（Method Area）
这个区域也是线程共享的区域，用于存储已经被虚拟机加载的类信息，常量，静态变量，即时编译器编译后的代码等数据。规范中对这个区域的描述是，方法区是堆的一部分，但是它有个名字叫做非堆（Non-Heap），目的是用于区分堆。
有些在HotSpot上搞事情的人喜欢吧方法区和永久代（Permanent Generation）画等号，但是从本质上说这两个不是一回事，只不过HopSpot虚拟机的团队选择用永久代来实现方法区而已，省掉了为方法区单独编写内存回收代码的工作。
原则上，方法区的实现不受规范约束，但是从设计角度说，这个设计并不是好设计，由于方法区占用了永久代，导致永久代更容易出现内存溢出问题(永久代有最大内存先知 -XX：MaxPermSize),有一些方法，比如String.intern()，会因为这个原因而导致不同的虚拟机出现不一样的表现，目前JDK1.7中字符串常量池已经从永久代移出了。
方法区无法满足内存分配需求时，将会抛出OutOfMemoryError。
1.6 运行时常量池（Runtime Constant Pool）
这个部分是方法区的一部分。Class文件里除了有版本，字段，方法，接口等描述信息之外，还有一个是常量池（Constant Pool Table），用于存放在编译期生成的各种字面量和符号引用，并在类加载后进入方法区的常量池。
Java虚拟机规范对于Class的格式有严格要求，唯独对这个运行时常量池没有细节要求，不同的提供商可以按照自己的需要来实现这块区域。
这个运行时常量池具备动态性，Java并没要求常量只能在编译期产生，运行时也可以进入常量池，典型应用就是String.intern（).
由于常量池就在方法区内部，因此也受到内存的限制，一旦申请不到内存就OutOfMemoryError。
1.7 直接内存（Direct Memory）
Java虚拟机规范中并没有对这个部分作出规范。
JDK 1.4中新加入了NIO，利用它可以使用Native函数库直接分配内存，然后通过一个存在Java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这样，在一些场景中可以显著地提高性能，可以避免在Java堆中和Native堆中来回复制数据。