什么是JVM虚拟机？
一 JVM体系结构概述
负责加载class文件,class在文件开头有特定的文件标识,并且ClassLoader只负责class文件的加载,至于它是否可以运行,则有Execution Engine决定.
1.2 三种类加载器
启动类加载器(Bootstrap)
(C++语言,Object类 负责加载%JAVA_HOME%\bin目录下的所有jar包，或者是-Xbootclasspath参数指定的路径)拓展类加载器(Extension)
(java语言,负责加载%JAVA_HOME%\bin\ext目录下的所有jar包，或者是java.ext.dirs参数指定的路径)应用程序类加载器(App)
(Java,系统类加载器,加载当前应用的classpath的所有类(存放 main函数的类))
启动类加载器(Bootstrap)的子类是拓展类加载器(Extension)
拓展类加载器(Extension) 的子类是应用程序类加载器(App)
1.3双亲委派机制
双亲委派机制得工作过程：
1-类加载器收到类加载的请求；
2-把这个请求委托给父加载器去完成，一直向上委托，直到启动类加载器；
3-启动器加载器检查能不能加载（使用findClass()方法），能就加载（结束）；否则，抛出异常，通知子加载器进行加载。
4-重复步骤三
1.4双亲委派机制说明
接下来举个例子：
大家所熟知的Object类，直接告诉大家，Object默认情况下是启动类加载器进行加载的。假设我也自定义一个Object，并且制定加载器为自定义加载器。现在你会发现自定义的Object可以正常编译，但是永远无法被加载运行。
这是因为申请自定义Object加载时，总是启动类加载器，而不是自定义加载器，也不会是其他的加载器。
人和事物都有缺陷，双亲委派机制也不例外，三次得到破坏：
1-jdk1.2之间，用户直接去调用loadClass()方法；不能保证双亲委派机制的基本规则。后改成findClass()方法。
2-双亲委派机制的自我缺陷，使用了线程上下文类加载器。这种行为打破了双亲委派机制模型的层次关系来逆向使用类加载器，实际上违背了双亲委派机制的一般性原则。
3-用户对程序动态性的追求而导致的。例如鼠标，键盘灯热部署。
1.5沙箱安全机制
组成沙箱的基本组件：
字节码校验器（bytecode verifier）：确保Java类文件遵循Java语言规范。这样可以帮助Java程序实现内存保护。但并不是所有的类文件都会经过字节码校验，比如核心类。
类装载器（class loader）：其中类装载器在3个方面对Java沙箱起作用 它防止恶意代码去干涉善意的代码； 它守护了被信任的类库边界； 它将代码归入保护域，确定了代码可以进行哪些操作。
1.6 本地方法栈
Java语言本身不能对操作系统底层进行访问和操作，但是可以通过JNI接口调用其他语言来实现对底层的访问。
1.7PC寄存器
每个线程都有一个程序计数器，是线程私有的,就是一个指针，指向方法区中的方法字节码（
用来存储指向下一条指令的地址,也即将要执行的指令代码），由执行引擎读取下一条指令，是一个非常小的内存空间，几乎可以忽略不记。
记录着方法之间的调用关系
1.8Heap堆
一个JVM实例只存在一个堆内存，堆内存的大小是可以调节的。类加载器读取了类文件后，需要把类、方法、常变量放到堆内存中，保存所有引用类型的真实信息，以方便执行器执行。
新生区
新生区是类的诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。新生区又分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存0区.若幸存0区也满了，再对该区进行垃圾回收，然后移动到1区。那如果1区也满了呢？再移动到养老区。若养老区也满了，那么这个时候将产生MajorGC（FullGC），进行养老区的内存清理。若养老区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”。
如果出现java.lang.OutOfMemoryError: Java heap space异常，说明Java虚拟机的堆内存不够。原因有二：
（1）Java虚拟机的堆内存设置不够，可以通过参数-Xms、-Xmx来调整。
（2）代码中创建了大量大对象，并且长时间不能被垃圾收集器收集（存在被引用）。
如有错误，请指正！！！
