文章标题

通过虚拟机要了解的问题
1、基本的内存模型
2、各种内存溢出的原因
3、垃圾回收模型及各种垃圾回收器原理
4、class文件结构
5、类加载机制
6、虚拟机从编译到运行整个生命周期
7、了解java继承、多态的底层机制
8、了解泛型的底层实现机制
9、了解内部类的底层实现机制
10、了解对象的从实例化开始到释放内存的整个生命周期
11、了解反射的底层实现机制
12、线程机制（暂缓吧）

一、内存模型

1. 程序计数器
   记录线程中正在执行的指令，确定下一步要执行的是哪条指令。多线程时，当线程数超过CPU数量或CPU内核数量，线程之间就要根据时间片轮询抢夺CPU时间资源。因此每个线程有要有一个独立的程序计数器，记录下一条要运行的指令。如果执行的是JAVA方法，计数器记录正在执行的java字节码地址，如果执行的是native方法，则计数器为空。

2. 虚拟机栈
   每个方法执行时都会创建一个桢栈来存储方法的私有变量、操作数栈、动态链接方法、返回值、返回地址等信息。每个方法的调用直至完成，就代表一个桢栈在虚拟机栈中入栈、出栈的过程。
   如果栈的深度是固定的，请求的栈深度大于最大可用深度，则抛出stackOverflowError；如果栈是可动态扩展的，但没有内存空间支持扩展，则抛出OutofMemoryError。

3. 本地方法区
   同虚拟机栈类似，不同的是本地方法去中执行的是native方法。
   同虚拟机栈一样，本地方法区也会抛出stackOverflowError和OutofMemoryError

4. 堆
   存放对象实例和数组。分为新生代和老年代和老年代，新生代又可分为Eden,From Survivor,To Survivor(他们各自所占的比例和作用后面讨论)。
   堆中没有足够空间存放实例时，抛出OutofMemoryError

5. 方法区
   存放虚拟机加载的类信息、常量、静态变量等编译器编译后的代码。
   方法区无法满足内存分配时，抛出OutofMemoryError

6. 运行时常量池
   是方法区的一部分，存放各种字面量和符号引用（专指字符串？）。Java语言并不要求常量一定只有编译期预置入Class的常量表的内容才能进入方法区常量池，运行期间也可将新内容放入常量池（最典型的String.intern()方法）。
   常量池无法申请到内存时，抛出OutofMemoryError

7. 直接内存
   直接内存并不是虚拟机运行时数据区的一部分，它根本就是本机内存而不是VM直接管理的区域。
   各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），而导致动态扩展时出现OutOfMemoryError异常。

二、 GC回收机制

程序计数器、虚拟机栈、本地方法栈线程私有，生命周期同线程的一样。GC主要涉及堆和方法区。方法区执行GC的效率较低，虚拟机规范也没有对方法区的回收做强制规定，但最好还好对，
方法区进行GC回收，防止方法区内存溢出。
对象四种引用级别：
1. 强引用
2. 软引用
3. 弱引用
4. 虚引用
参考http://itlab.idcquan.com/Java/oop/716371_2.html

常用垃圾回收算法：
1.标记-整理
将需要回收的对象，先标记后清除。标记和清除的效率都很低，垃圾回收后会产生内存碎片。
2. 复制
将内存分为两块，一块拿来使用，内存不足时，将存活的对象复制到另一块上面，然后将已使用过的内存清除。不会产生内存碎片，但是需要额外的内存空间。
3. 标记-清理
先标记，后整理。整理时将存活的对象向一端移动，从而不会产生内存碎片。
4. 分代整理
将内存空间分为几个模块，模块之间采用不同的垃圾收集方式。

当前主流的虚拟机都将内存分为新生代和老年代，新生代存放存活率较低的对象，老年代存放存活率较高的对象。所以通常新生代采用复制算法，老年代采用标记-清理或标记-整理。研究表明新生代中的对象98%是朝生夕死的，所以x新生代并不需要按照1:1来划分内存，而是按照8:1:1,划分为eden、survivor from、survivor to 三块。同一时刻新生代中，eden和一块survivor用来存放内存，另一块survivor留作回收时备用。
参考：http://www.iteye.com/topic/894148

垃圾收集器

1. Serial
单线程收集器，采用复制算法，“stop the world”时间过长，没有线程交互的开销，可以获得最高的单线程垃圾收集效率，因此Serial垃圾收集器依然是java虚拟机运行在Client模式下默认的新生代垃圾收集器。
2. ParNew
Serial的多线程版本。ParNew收集器是许多运行在server模式下的虚拟机的收集器（一个愿意是除了Serial外，只有它能与CMS收集器配合使用）
3. Parallel Scavenge
多线程收集器，它的特点在于可以手动控制一次垃圾收集中”stop the world”时间和吞吐量（吞吐量=运行用户代码时间/（运行用户代码时间+垃圾回收时间））
4. Serial Old
Serial 的老年代版本，采用标记-整理算法
5. Parallel Old
Parallel Scavenge的老年代版本，采用标记-整理算法。在着重需要控制吞吐量时，可以将Parallel Old收集器和Parallel Scavenge收集器配合使用。
6. CMS
Concurrent Mark Sweep,标记-清除算法以获取最短停顿时间为目标的收集器。”stop the world”时间短，符合目前的互联网B/S架构。
CMS收集分为四个阶段：
初始标记：标记GC Roots能直接关联到对象，需要”stop the world”,但速度很快
并发标记：标记阶段
重新标记：修正并发标记阶段时用户继续运行产生的标记改变，需要”stop the world”，
并发清： 清除阶段
CMS收集过程中，耗时较长的并发标记阶段并发清除阶段，都可以和用户操作同步进行，所有停顿时间短。
缺点三点：并发阶段，会占用一定的线程，导致吞吐量降低；无法处理浮动垃圾，可能出现”concurrent mode failure”,出现”concurrent mode failure”后，虚拟机将启用备用方案Serial Old处理器来重新进行收集；产生内存碎片。
7. G1收集器
G1于CMS相比的两个优点：采用标记-整理算法，不会产生内存碎片；可以精确的控制停顿时间。
G1收集器可以实现在不牺牲吞吐量的情况下实现低停顿。这是因为它极力避免了全区域的垃圾收集，而是将堆划分为多个大小固定的区域，每次根据优先情况，值清理其中的部分区域。

三、Java Class类文件结构

(1)magic 魔数 确定文件类型
(2)minor_version 次版本号 major_version 主版本号
(3)constane_pool_count constane_pool 常量池
常量池中主要包括两大类常量：
字面量，文本字符串、被声明为final的常量值等。
符号引用，类和接口的全定限名、字段的名称和描述符、方法名称和描述符
总共21种常量类型（jdk1.7），下面列出了部分常量类型的结构

(4)access_flags 访问标志，识别是类还是接口，识别修饰符public final abstract等
(5)this_class super_class interfaces_count interfaces
(6)fields_count fields 字段表
字段表不会列出从超类或父接口中继承的字段，但可能列出原本java代码中不存在的字段，如内部类中会列出外部类的字段。另外，在Java中是不支持重载的，两个字段的数据类型、数据类型不管是否相同，都必须使用不同的名称。但对字节码来说，如果两个字段的描述符不一致，那字段重名就是合法的。

(7)medthods_count medthods 方法表
方法表不会列出从父类继承的方法，但可能出现编译器自动添加的方法，如实例构造器”init”和类构造器”clinit”.
在字节码文件中，如果两个方法名称和特征签名相同，但返回值不同，那么也是可以合法存在与同一文件中的。
方法表结构与字段表类似
(8)attribute_info_count attribute_info 属性表
目前的属性表有21个种类（jdk1.7）,下面只简要概述其中一部分。
Code,描述方法体的具体操作

max_stact代表操作数栈的最大深度；max_locals代表局部变量所需的存储空间，并不是方法中用到了多少局部变量，就把这些局部变量所占的空间作为max_locals的值，因为局部变量表中的空间可以重用;exception_info被称作显示异常表（编译器会为方法内的同步块自动添加异常表，从而在同步块中的异常无法处理时，释放管程（Monitor））
ConstantValue 作用是通知虚拟机自动为静态变量赋值。目前Sun Javac编译器对类变量的初始化有两种方式：final修饰的类变量，且这个变量的类型是基本类型或String的话，就生成ConstantValue在准备阶段进行初始化，否则在初始化阶段的clinit方法中进行初始化（这样做的原因是？）
InnerClasses、EncloseingMedthod 用于记录内部类与宿主类之间的关联。
StackMapTable
BootstapMedthods

(9)constant_medthodhandle_info, constant_medthodtype_info constant_invokedynamic_info

四、虚拟机加载机制

加载、验证、准备、初始化和卸载这5个阶段的顺序是一定的，解析阶段则不一定，按规定应该在初始化之前，但有时会在之后，这样是为了支持Java的运行时绑定(及多态)。什么时候进行初始化呢，java虚拟机规范严格规定了有且只有5种情况必须对类进行初始化

• 遇到new（实例化对象）、getstatic（读取类静态字段）、putstatic（设置类静态字段）、invokestatic（调用类静态方法）这4条字节码指令
• . 使用Java.lang.reflect包对类进行反射调用
• 当初始化一个类时，如果父类没有初始化，则对父类初始化
• 虚拟机启动时，指定执行的追（包含main方法的那个类），需要进行初 始化
• 使用jdk1.7的动态语言支持，MethodHandle解析结果是REF_getStatic、REF_putStatic、REF_invokeStatic,且没有初始化时，需要先对其进行初始化

加载
在加载阶段，虚拟机需要完成以下3件事情
- 通过类的全限定名获取定义此类的二进制字节流；
- 将字节流代表的静态存储结构转化为方法区的运行时数据结构；
- 在Java内存中生成Java.lang.Class对象，作为方法区这些数据的访问入口

参考http://blog.csdn.net/a19881029/article/details/17247165
加载阶段是类加载过程中，开发人员可控性最强的阶段，开发人员可定义自己的加载器。Java中的类加载器主要有2类，一类是系统提供的，另一类是由Java应用开发人员编写的
系统提供的类加载器主要有下面3个：
- 启动（Bootstrap）类加载器：是用本地代码实现的类装入器，它负责将 /lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
- 标准扩展（Extension）类加载器：是由 Sun的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将/lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。 - 系统（System）类加载器：是由 Sun 的AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器

类加载器涉及的双亲委派模式：当一个类收到类加载请求时，它首先不会自己去加载这个类，而是把这个类交给父加载器去完成，父加载器反馈无法完成加载时，它才会对这个类进行加载。具体可以查看java.lang.ClassLoad中的代码

protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException
    {
        synchronized (getClassLoadingLock(name)) {
            // First, check if the class has already been loaded
            Class c = findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime();
                try {
                    if (parent != null) {
                        c = parent.loadClass(name, false);
                    } else {
                        c = findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // ClassNotFoundException thrown if class not found
                    // from the non-null parent class loader
                }

                if (c == null) {
                    // If still not found, then invoke findClass in order
                    // to find the class.
                    long t1 = System.nanoTime();
                    c = findClass(name);

                    // this is the defining class loader; record the stats
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

双亲委派模式的好处是使类加载器具有优先级的层次关系，保证了对象类在程序的各种加载器环境下都是同一个类。有时候也需要破坏双亲委派模式，如典型的JNDI服务。

验证
确保Class文件的字节流中包含的信息符合当前虚拟机的要求

准备
准备阶段是为类变量分配内存并设置初始值的阶段，但ConstantValue属性的类变量在准备阶段就会直接赋值。

解析
解析阶段是虚拟机将常量池内的符号引用转为直接引用的过程；解析发生的时间：在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevitual、multianewarray、new、putfield、putstatic这13用于操作符号引用的字节码指令之前；解析过程主要有如下7种：
1）类或接口的解析：
假设当前代码所处的类为D，D的常量池中有一个从未解析过得符号引用N，将N解析为一个类或接口C的直接引用，过程如下
- 如果C不是数组类型：将N的全限定名传递给D的类加载器去加载C。如果加载过程出现异常，则解析失败
- 如果C是数组类型，且数组类型的元素类型为对象，即N的描述符是“[Ljava.lang.Integer”的形式：按照第1点加载Integer，接着由虚拟机生成一个代表此数组维度和元素的数组对象
- 进行访问权限验证
2)字段解析
- 对字段表内class_index项索引的CONSTANT_Class_info符号引用进行解析，获得所属类或接口的直接引用
- 在获取的直接引用中，查找简单名称和简单描述符匹配的字段
- 如果在获取的直接引用中没有找到，按照继承关系，由下向上递归查找简单名称和简单描述符匹配的字段 找到匹配的字段后，进行访问权限验证
3)类方法解析
类似字段解析，类方法解析的所属类引用不可以是接口
3)接口方法解析
类似字段解析，类方法解析的所属接口引用不可以是类

初始化
- 该阶段才真正开始执行类中定义的Java代码（字节码），执行类构造器clinit。类构造器clinit的生成有一下规则：
- clinit是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，编译顺序由语句在java文件中的顺序决定。静态语句块只能访问到定义在静态语句块之前的变量，但可以给定义之前的变量赋值
- clinit方法与实例构造器不同，不需要显示的调用父类构造器，虚拟机会保证在子类的clinit执行前，父类的clinit已经执行
- 接口中不需要先执行父接口的clinit，只有当父接口中定义的变量被使用时，父接口才被初始化。另外，接口的实现类在初始化时也一样不会执行接口的clinit
- 虚拟机会保证一个类的clinit在多线程环境中被正确的加锁和同步

。