最近大致的学习了一下jvm的相关技术，发现深入理解java虚拟机这本书很不错，所以想将这本书的内容的重难点在blog总结一下，一是为了巩固这些知识，二是为了把这些重点单独写出来，让初学者在学习的时候有一个大致的框架以至于学起来不至于那么迷茫
学习java虚拟机，有两个最重要的机制需要知道：
1. 自动内存管理机制
2. 虚拟机执行子系统
下面将首先介绍jvm的自动内存管理机制：
java和c++之间有一堵由内存动态分配和垃圾回收机制所围成的高墙。要了解具体是如何进行内存分配和回收之前需要了解jvm的运行时内存模型（数据区域），本文将详细的介绍jvm的内存模型。
java虚拟机在执行java程序的过程中会把它所管理的内存划分为若干个不同的数据区域。这些区域各有各自的用途，以及创建和销毁的时间。下图便是一个jvm运行时的内存模型 
下面分模块对这些区域做简要的介绍：
1. 程序计数器：它可以看作是当前线程所执行的字节码（字节码 ）的行号指示器，在虚拟的概念模型中 ，字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支，循环，跳转，异常处理，线程恢复等基础功能。为了在多线程中，线程切换后能恢复到正确的执行位置，每条线程需要有一个独立的程序计数器，即这个部分是线程私有的。
如果线程执行的是一个java方法，那么计数器记录的是虚拟机字节码指令的地址；如果执行的是Native方法，则该计数器值为空(Undefined)。此内存区域是唯一一个不会发生OutOfMemoryError的区域。
2. java虚拟机栈：与程序计数器一样，java虚拟机栈同样是线程私有的，它的生命周期和线程相同。虚拟机栈描述的是java方法执行的内存模型：每个方法在执行的同时会创建一个栈帧（Stack Frame）用于存储局部变量表，操作数栈，动态链接，方法出口等信息。每一个方法从调用到执行完成的过程，就对应着一个栈帧在虚拟机栈从入栈到出栈的过程。这部分内容比较重要，详情见jvm栈帧详解。局部变量表所需的内存空间在编译器件完成分配，在方法运行期间不会改变局部变量表的大小。
在jvm规范中，对这个区域指定了两种异常状况：1.如果线程请求的栈深度大于虚拟机所允许的深度（多为无限递归）：抛出*Error异常；如果虚拟机栈可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
虚拟机参数：HotSpot不区分本地方法栈和虚拟机栈，所以-Xoss参数无效，栈容量只由-Xss参数决定
3. 本地方法栈：和虚拟机栈差不多，区别在于虚拟机栈为虚拟机执行java方法（字节码）服务，而本地方法栈则为虚拟机使用到的Native方法服务，与虚拟机栈一样，本地方法栈也会抛出*Error异常或者OutOfMemoryError异常。
4. java堆：Java堆是jvm所管理内存中最大的一块。Java堆是被所有线程共享的一块区域。在虚拟机启动时创建。java堆是GC的主要区域。从内存回收的角度来看，由于现在收集器基本采用分代回收算法，所以java堆还可以细分为新生代和老年代；从内存分配的角度来看，线程共享的java堆可以划分出多个线程私有的分配缓冲区。但无论如何划分，都与存放内容无关，无论哪个区域，存储的依然是对象的实例。进一步划分只是为了更好的回收内存和更好的分配内存。
根据jvm规范的规定，java堆可以处于物理上不连续的内存空间中，只要逻辑上市连续的即可。如果堆中没有内存完成实力分配并且堆也无法再扩展时，将会抛出OutOfMemoryError异常。
虚拟机参数：-Xms：堆的最小值；-Xmx：堆的最大值；将这两个设为一样可以防止堆自动扩展。-XX:+HeapDumpOnOutOfMemoryError 可以让虚拟机在出现内存溢出异常时Dump出当前的内存堆转储快照以便分析，一般可以用内存映像分析工具（如：Eclipse Memory Analyzer）分析转储快照，重点是确认内存中的对象是否是有必要的，即内存泄漏还是内存溢出。如果是内存泄漏：分析到GC Roots引用链，准确定位泄漏代码的位置；如果是内存溢出：检查堆参数是否可根据物理内存在调大，是否有对象声明周期过长等问题。
5. 方法区：与java堆一样，是各个线程共享的内存区域，它用于存储已被虚拟机加载的类信息 ，常量，静态变量，即时编译器编译后的代码等数据。不同虚拟机在这里的实现不尽相同，这些区别可以在String.intern()方法看出来。这个区域很少进行垃圾回收，但并非”永久”，这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载，当方法区无法满足内存分配需求时，将抛出OutOfMemoryError异常。
虚拟机参数：在JDK 1.6 之前，可以通过-XX : PermSize和-XX : MaxPermSize限制方法区的大小从而限制常量池的容量
6. 运行时常量池：它其实是方法区的一部分，Class文件中除了有类的版本，字段，方法，接口等描述信息外，还有一项信息是常量池，用于存放编译器生成的各种字面量和符号引用，这部分内容 将在类加载后进入方法区的运行时常量池中存放。一般来说，除了保存Class文件中的符号引用外，还会把翻译出来的直接引用也存储到运行时常量池中。并且运行时常量池具备动态性，所以不仅有class文件中内容才能进入常量池中。运行时也可能将新的常量放入池中，比如String.intern()方法，jvm规范规定，当常量池无法再申请到内存时会抛出OutOfMemoryError异常。
7. 直接内存：直接内存并不是虚拟机运行时数据区的一部分，也不是java虚拟机规范中定义的内存区域。比如NIO中，引入了一种基于通道和缓冲区的IO方式，它可以使用Native函数直接分配堆外内存，然后通过一个存储在java堆中的DirectByteBuffer对象作为这块内存的引用进行操作。这部分内存的分配不会受到java堆内存的限制，但是会受到本机总内存和处理器寻址空间的限制，会导致OutOfMemoryError异常。
虚拟机参数：DirectMemory容量可以通过-XX : MaxDirectMemorySize指定，如果不指定，则和java堆最大值(-Xmx)一样
下面将以HotSpot虚拟机在Java堆中对象分配，布局和访问的全过程为例来讲解一下虚拟机的细节实现：
jvm对new的反应（对象的创建）：
1. 会去检查这个指令的参数是否能在常量池中定位到一个类的符号引用，并且检查这个符号引用代表的类是否被加载，解析和初始化过（虚拟机执行子系统）。如果没有，那必须先执行类加载过程
2. 在类加载检查通过后，接下来虚拟机将为新生对象分配内存。对象所需内存的大小在类加载完成后便可完全确定，为对象在堆中分配空间有两种方式：1. 指针碰撞（堆中内存规整），2. 空闲列表（堆中内存不规整）。选择哪种分配方式由java堆是否规整决定，而java堆是否规整由所采用的gc是否带有压缩整理的功能决定。内存分配在多线程时并不安全，要同步。
3. 接下来，虚拟机要对对象进行必要的设置，例如对象是哪个类的实例，如何找到类的元数据信息，对象的hashcode，对象的GC分代年龄等信息，这些信息存放在对象头中。
4. 现在，在jvm的角度，一个对象已经产生，但从java程序的角度，还需要调用构造函数，这样一个真正可用的对象才算完全产生出来。
到目前为止，对象已经被创建，那么对象在内存中的存储布局是什么样的呢？对象的内存布局主要分为3块区域：对象头，实例数据，对齐填充。下面分别介绍这三个部分。
1.对象头：HotSpot虚拟机的对象头包含两部分信息，第一部分用于存储对象自身的运行时数据，如hashcode，GC分代年龄，线程持有的锁等信息；另一部分就是类型指针，即对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，如果对象是一个java数组，那么对象头中应该还有一个记录数组长度的数据。因为jvm可以通过普通java对象的元数据信息来确定对象的大小，但是无法通过数组的元数据信息确定数组的大小。
2. 实例数据：是对象真正存储的有效信息，也是在程序代码中定义的各种类型的字段内容。无论是从父类继承还是子类定义，都需要记录。一般父类的信息会在子类之前
3. 对齐填充：仅仅是占位符的作用，因为对象的大小要是8字节的整数倍，不够的地方要填充。
知道了对象的内存布局，那如何对对象进行定位呢？ java程序是通过栈上的reference数据来操作堆上的具体对象。jvm规范并未定义reference这个也能用应该通过何种方式去定位堆中的对象。所以对象的访问方式取决于虚拟机的具体实现：
1. 句柄：java堆中会划分出一块内存作为句柄池，reference中存储的是对象的句柄地址，而句柄中包含了对象实例数据与类型数据各自的具体地址信息 
2. 直接指针：reference中直接存储对象的地址 
两种方式各有优劣：句柄的好处是对象移动（GC很多）时只会改变句柄中的实例数据指针，而reference本身不用修改；但是直接指针的访问速度更快，一次定位，句柄需要二次。HotSpot是采用直接指针的方式对对象定位的。