Java虚拟机结构分析
本文主要介绍了JVM(Java Virtual Machine)的组成部分以及它们内部的工作机制和原理。需要注意的是，虽然平时我们用的大多是Sun（现已被Oracle收购）JDK提供的JVM，但是JVM本身是一个规范，所以可以有多种实现，除了Hotspot外，还有诸如Oracle的JRockit、IBM的J9也都是非常有名的JVM。
1. 结构
下图展示了JVM的主要结构：
可以看出，JVM主要由类加载器子系统、运行时数据区（内存空间）、执行引擎以及与本地方法接口等组成。其中运行时数据区又由方法区、堆、Java栈、PC寄存器、本地方法栈组成。
从上图中还可以看出，在内存空间中方法区和堆是所有Java线程共享的，而Java栈、本地方法栈、PC寄存器则由每个线程私有，这会引出一些问题，后文会进行具体讨论。
众所周知，Java语言具有跨平台的特性，这也是由JVM来实现的。更准确地说，是Sun利用JVM在不同平台上的实现帮我们把平台相关性的问题给解决了，这就好比是HTML语言可以在不同厂商的浏览器上呈现元素（虽然某些浏览器在对W3C标准的支持上还有一些问题）。同时，Java语言支持通过JNI（Java Native Interface）来实现本地方法的调用，但是需要注意到，如果你在Java程序用调用了本地方法，那么你的程序就很可能不再具有跨平台性，即本地方法会破坏平台无关性。
2. 类加载器子系统（Class Loader）
类加载器子系统负责加载编译好的.class字节码文件，并装入内存，使JVM可以实例化或以其它方式使用加载后的类。JVM的类加载子系统支持在运行时的动态加载，动态加载的优点有很多，例如可以节省内存空间、灵活地从网络上加载类，动态加载的另一好处是可以通过命名空间的分隔来实现类的隔离，增强了整个系统的安全性。
2.1 ClassLoader的分类
- 启动类加载器（BootStrap Class Loader）：负责加载rt.jar文件中所有的Java类，即Java的核心类都是由该ClassLoader加载。在Sun JDK中，这个类加载器是由C++实现的，并且在Java语言中无法获得它的引用。
- 扩展类加载器（Extension Class Loader）：负责加载一些扩展功能的jar包。
- 系统类加载器（System Class Loader）：负责加载启动参数中指定的Classpath中的jar包及目录，通常我们自己写的Java类也是由该ClassLoader加载。在Sun JDK中，系统类加载器的名字叫AppClassLoader。
- 用户自定义类加载器（User Defined Class Loader）：由用户自定义类的加载规则，可以手动控制加载过程中的步骤。
2.2 ClassLoader的工作原理
类加载分为装载、链接、初始化三步。
2.2.1 装载
通过类的全限定名和ClassLoader加载类，主要是将指定的.class文件加载至JVM。当类被加载以后，在JVM内部就以“类的全限定名+ClassLoader实例ID”来标明类。
在内存中，ClassLoader实例和类的实例都位于堆中，它们的类信息都位于方法区。
装载过程采用了一种被称为“双亲委派模型（Parent Delegation Model）”的方式，当一个ClassLoader要加载类时，它会先请求它的双亲ClassLoader（其实这里只有两个ClassLoader，所以称为父ClassLoader可能更容易理解）加载类，而它的双亲ClassLoader会继续把加载请求提交再上一级的ClassLoader，直到启动类加载器。只有其双亲ClassLoader无法加载指定的类时，它才会自己加载类。
双亲委派模型是JVM的第一道安全防线，它保证了类的安全加载，这里同时依赖了类加载器隔离的原理：不同类加载器加载的类之间是无法直接交互的，即使是同一个类，被不同的ClassLoader加载，它们也无法感知到彼此的存在。这样即使有恶意的类冒充自己在核心包（例如java.lang）下，由于它无法被启动类加载器加载，也造成不了危害。
由此也可见，如果用户自定义了类加载器，那就必须自己保障类加载过程中的安全。
2.2.2 链接
链接的任务是把二进制的类型信息合并到JVM运行时状态中去。
链接分为以下三步：
- 验证：校验.class文件的正确性，确保该文件是符合规范定义的，并且适合当前JVM使用。
- 准备：为类分配内存，同时初始化类中的静态变量赋值为默认值。
- 解析（可选）：主要是把类的常量池中的符号引用解析为直接引用，这一步可以在用到相应的引用时再解析。
2.2.3 初始化
初始化类中的静态变量，并执行类中的static代码、构造函数。
JVM规范严格定义了何时需要对类进行初始化：
1. 通过new关键字、反射、clone、反序列化机制实例化对象时。
2. 调用类的静态方法时。
3. 使用类的静态字段或对其赋值时。
4. 通过反射调用类的方法时。
5. 初始化该类的子类时（初始化子类前其父类必须已经被初始化）。
6. JVM启动时被标记为启动类的类（简单理解为具有main方法的类）。
更详细的虚拟机加载机制可以参考《Java虚拟机类加载机制》。
3. 运行时数据区
运行时数据区由方法区、堆、Java栈、PC寄存器、本地方法栈组成。
3.1 Java栈（Java Stack）
Java栈的主要任务是存储方法参数、局部变量、中间运算结果，并且提供部分其它模块工作需要的数据。
Java栈总是与线程关联在一起的，每当创建一个线程，JVM就会为该线程创建对应的Java栈，在这个Java栈中又会包含多个栈帧(Stack Frame)，这些栈帧是与每个方法关联起来的，每运行一个方法就创建一个栈帧，每个栈帧会含有一些局部变量、操作栈和方法返回值等信息。每当一个方法执行完成时，该栈帧就会弹出栈帧的元素作为这个方法的返回值，并且清除这个栈帧，Java栈的栈顶的栈帧就是当前正在执行的活动栈，也就是当前正在执行的方法，PC寄存器也会指向该地址。只有这个活动的栈帧的本地变量可以被操作栈使用，当在这个栈帧中调用另外一个方法时，与之对应的一个新的栈帧被创建，这个新创建的栈帧被放到Java栈的栈顶，变为当前的活动栈。同样现在只有这个栈的本地变量才能被使用，当这个栈帧中所有指令都完成时，这个栈帧被移除Java栈，刚才的那个栈帧变为活动栈帧，前面栈帧的返回值变为这个栈帧的操作栈的一个操作数。
由于Java栈是与线程对应起来的，Java栈数据不是线程共有的，所以不需要关心其数据一致性，也不会存在同步锁的问题。
它分为三部分：局部变量区、操作数栈、帧数据区。
3.1.1 局部变量区
局部变量区是以字长为单位的数组，在这里，byte、short、char类型会被转换成int类型存储，除了long和double类型占两个字长以外，其余类型都只占用一个字长。特别地，boolean类型在编译时会被转换成int或byte类型，boolean数组会被当做byte类型数组来处理。局部变量区也会包含对象的引用，包括类引用、接口引用以及数组引用。
局部变量区包含了方法参数和局部变量，此外，实例方法隐含第一个局部变量this，它指向调用该方法的对象引用。对于对象，局部变量区中永远只有指向堆的引用。
3.1.2 操作数栈
操作数栈也是以字长为单位的数组，但是正如其名，它只能进行入栈出栈的基本操作。在进行计算时，操作数被弹出栈，计算完毕后再入栈。
3.1.3 帧数据区
帧数据区的任务主要有：
记录指向类的常量池的指针，以便于解析。
帮助方法的正常返回，包括恢复调用该方法的栈帧，设置PC寄存器指向调用方法对应的下一条指令，把返回值压入调用栈帧的操作数栈中。
记录异常表，发生异常时将控制权交由对应异常的catch子句，如果没有找到对应的catch子句，会恢复调用方法的栈帧并重新抛出异常。
局部变量区和操作数栈的大小依照具体方法在编译时就已经确定。调用方法时会从方法区中找到对应类的类型信息，从中得到具体方法的局部变量区和操作数栈的大小，依此分配栈帧内存，压入Java栈。
在Java虚拟机规范中，对这个区域规定了两种异常状况：如果线程请求的栈深度大于虚拟机所允许的深度，将抛出StackOverflowError异常；如果虚拟机可以动态扩展，如果扩展时无法申请到足够的内存，就会抛出OutOfMemoryError异常。
3.2 本地方法栈（Native Method Stack）
本地方法栈类似于Java栈，主要存储了本地方法调用的状态。区别不过是Java栈为JVM执行Java方法服务，而本地方法栈为JVM执行Native方法服务。本地方法栈也会抛出StackOverflowError和OutOfMemoryError异常。在Sun JDK中，本地方法栈和Java栈是同一个。
3.3 PC寄存器/程序计数器（Program Count Register）
严格来说是一个数据结构，用于保存当前正在执行的程序的内存地址，由于Java是支持多线程执行的，所以程序执行的轨迹不可能一直都是线性执行。当有多个线程交叉执行时，被中断的线程的程序当前执行到哪条内存地址必然要保存下来，以便用于被中断的线程恢复执行时再按照被中断时的指令地址继续执行下去。为了线程切换后能恢复到正确的执行位置，每个线程都需要有一个独立的程序计数器，各个线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存,这在某种程度上有点类似于“ThreadLocal”，是线程安全的。
3.4 方法区（Method Area）
类型信息和类的静态变量都存储在方法区中。方法区中对于每个类存储了以下数据：
- 类及其父类的全限定名（java.lang.Object没有父类）
- 类的类型（Class or Interface）
- 访问修饰符（public, abstract, final）
- 实现的接口的全限定名的列表
- 常量池
- 字段信息
- 方法信息
- 静态变量
- ClassLoader引用
- Class引用
可见类的所有信息都存储在方法区中。由于方法区是所有线程共享的，所以必须保证线程安全，举例来说，如果两个类同时要加载一个尚未被加载的类，那么一个类会请求它的ClassLoader去加载需要的类，另一个类只能等待而不会重复加载。
常量池本身是方法区中的一个数据结构。常量池中存储了如字符串、final变量值、类名和方法名常量。常量池在编译期间就被确定，并保存在已编译的.class文件中。一般分为两类：字面量和应用量。字面量就是字符串、final变量等。类名和方法名属于引用量。引用量最常见的是在调用方法的时候，根据方法名找到方法的引用，并以此定为到函数体进行函数代码的执行。引用量包含：类和接口的权限定名、字段的名称和描述符，方法的名称和描述符。
此外为了加快调用方法的速度，通常还会为每个非抽象类创建私有的方法表，方法表是一个数组，存放了实例可能被调用的实例方法的直接引用。
在Sun JDK中，方法区对应了持久代（Permanent Generation），默认最小值为16MB，最大值为64MB。大小可以通过参数来设置,可以通过-XX:PermSize指定初始值，-XX:MaxPermSize指定最大值。
3.5 堆（Heap）
堆是JVM所管理的内存中最大的一块，是被所有Java线程锁共享的，不是线程安全的，在JVM启动时创建。
堆用于存储对象实例以及数组值。堆是存储Java对象的地方，这一点Java虚拟机规范中描述是：所有的对象实例以及数组都要在堆上分配。堆中有指向类数据的指针，该指针指向了方法区中对应的类型信息。堆中还可能存放了指向方法表的指针。堆是所有线程共享的，所以在进行实例化对象等操作时，需要解决同步问题。此外，堆中的实例数据中还包含了对象锁，并且针对不同的垃圾收集策略，可能存放了引用计数或清扫标记等数据。
在堆的管理上，Sun JDK从1.2版本开始引入了分代管理的方式。主要分为新生代、旧生代。分代方式大大改善了垃圾收集的效率。
1、新生代（New Generation）
大多数情况下新对象都被分配在新生代中，新生代由Eden Space和两块相同大小的Survivor Space组成，后两者主要用于Minor GC时的对象复制（Minor GC的过程在此不详细讨论）。
JVM在Eden Space中会开辟一小块独立的TLAB（Thread Local Allocation Buffer）区域用于更高效的内存分配，我们知道在堆上分配内存需要锁定整个堆，而在TLAB上则不需要，JVM在分配对象时会尽量在TLAB上分配，以提高效率。
2、老年代（Old Generation/Tenuring Generation）
在新生代中存活时间较久的对象将会被转入老年代，老年代进行垃圾收集的频率没有新生代高。
4. 执行引擎
执行引擎是JVM执行Java字节码的核心，执行方式主要分为解释执行、编译执行、自适应优化执行、硬件芯片执行方式。
JVM的指令集是基于栈而非寄存器的，这样做的好处在于可以使指令尽可能紧凑，便于快速地在网络上传输（别忘了Java最初就是为网络设计的），同时也很容易适应通用寄存器较少的平台，并且有利于代码优化，由于Java栈和PC寄存器是线程私有的，线程之间无法互相干涉彼此的栈。每个线程拥有独立的JVM执行引擎实例。
JVM指令由单字节操作码和若干操作数组成。对于需要操作数的指令，通常是先把操作数压入操作数栈，即使是对局部变量赋值，也会先入栈再赋值。注意这里是“通常”情况，之后会讲到由于优化导致的例外。
4.1 解释执行
和一些动态语言类似，JVM可以解释执行字节码。Sun JDK采用了token-threading的方式，感兴趣的同学可以深入了解一下。解释执行中有几种优化方式：
- 栈顶缓存：将位于操作数栈顶的值直接缓存在寄存器上，对于大部分只需要一个操作数的指令而言，就无需再入栈，可以直接在寄存器上进行计算，结果压入操作数站。这样便减少了寄存器和内存的交换开销。
- 部分栈帧共享：被调用方法可将调用方法栈帧中的操作数栈作为自己的局部变量区，这样在获取方法参数时减少了复制参数的开销。
- 执行机器指令：在一些特殊情况下，JVM会执行机器指令以提高速度。
4.2 编译执行
为了提升执行速度，Sun JDK提供了将字节码编译为机器指令的支持，主要利用了JIT（Just-In-Time）编译器在运行时进行编译，它会在第一次执行时编译字节码为机器码并缓存，之后就可以重复利用。Oracle JRockit采用的是完全的编译执行。
4.3 自适应优化执行
自适应优化执行的思想是程序中10%~20%的代码占据了80%~90%的执行时间，所以通过将那少部分代码编译为优化过的机器码就可以大大提升执行效率。自适应优化的典型代表是Sun的Hotspot VM，正如其名，JVM会监测代码的执行情况，当判断特定方法是瓶颈或热点时，将会启动一个后台线程，把该方法的字节码编译为极度优化的、静态链接的C++代码。当方法不再是热区时，则会取消编译过的代码，重新进行解释执行。
自适应优化不仅通过利用小部分的编译时间获得大部分的效率提升，而且由于在执行过程中时刻监测，对内联代码等优化也起到了很大的作用。由于面向对象的多态性，一个方法可能对应了很多种不同实现，自适应优化就可以通过监测只内联那些用到的代码，大大减少了内联函数的大小。
Sun JDK在编译上采用了两种模式：Client和Server模式。前者较为轻量级，占用内存较少。后者的优化程序更高，占用内存更多。
在Server模式中会进行对象的逃逸分析，即方法中的对象是否会在方法外使用，如果被其它方法使用了，则该对象是逃逸的。对于非逃逸对象，JVM会在栈上直接分配对象（所以对象不一定是在堆上分配的），线程获取对象会更加快速，同时当方法返回时，由于栈帧被抛弃，也有利于对象的垃圾收集。Server模式还会通过分析去除一些不必要的同步，感兴趣的同学可以研究一下Sun JDK 6引入的Biased Locking机制。
此外，执行引擎也必须保证线程安全性，因而JMM（Java Memory Model）也是由执行引擎确保的。
