1. JVM体系结构
图1 JVM体系结构
方法区：存放JVM加载的类型信息。包括: 类型基本信息，常量池，字段信息，方法信息，类变量，指向ClassLoader的引用，Class类的引用，方法表等。
（对应JVM内存配置中的-PermSize等）
java堆：程序中创建的类的实例和数组，包括class对象和exception对象，存放在堆里面。堆中除了存储对象的实例数据外，还要存储该对象指向方法区中类型信息的指针。
（JVM中所有的线程共享堆空间，对应JVM内存配置中的-Xms和-Xmx等）
java栈：当JVM创建一个新线程时，都会产生线程计数器（PC Register）和栈。每一次方法调用都会产生栈帧，栈帧中包含局部变量区和操作数栈。
（JVM中栈被线程独享，对应JVM内存配置中的-Xss）
线程计数器：每个线程拥有自己的程序计数器，它指向下一条指令。当线程调用本地方法的时候， 它为undefined。
本地方法栈：当JVM线程调用了本地方法， 则会跳入本地方法栈。本地方法返回后可能再次跳回java方法栈。
（JVM支持本地方法调用，故JVM占用的OS内存可能会超出JVM堆内存大小设置，甚至会产生本地内存泄漏）
2. Java代码编译加载机制
Java源代码编译机制
分析和输入到符号表：对java文件的字符串进行解析，生成语法树及符号表。
注解处理：根据注解生成代码，并再进行词法和语法分析。
语义分析和生成class文件：检查变量使用前是否申明，异常是否捕获，类型检查等语义信息。生成的class文件不止包括可执行的字节码，还包括class文件版本号、类的超类和实现的接口、类的属性、常量、元数据以及异常处理器列表等信息。
以上三个步骤是一个由“词法分析 -> 语法分析 ->语义分析”的顺序编译过程。
JVM类加载机制
装载：将class文件（二进制字节码）加载到JVM中。
链接：校验class文件的格式，加载类关联的接口及类，对属性、方法及方法的访问权限进行验证等。
初始化：执行静态初始化代码、构造函数、静态属性初始化等，初始化不是类加载完后的一个必须执行过程，但最迟必须在首次主要使用对象前执行。初始化的触发条件，包括：1）调用了new；2）反射中调用了类的方法；3）子类调用了初始化；4）JVM启动的过程中指定的初始化类。
Sun JDK Class Loader继承关系
如上图所示，JVM类加载器采用的是树形结构，除Bootstrap类加载器外，其余类加载器在加载某个类之前，都会去其Parent加载器处看是否已加载，一直往上到根处。目的是避免从类加载器根到叶子的路径上一个类被不同的类加载器重复加载多次。用户自定义类加载器，需要继承ClassLoader抽象类。
（具体讲解参见：http://www.ibm.com/developerworks/cn/java/j-lo-classloader/index.html）
3. Java类执行机制
字节码解释执行
定义：在源码编译阶段将源码编译为JVM字节码（一种中间代码的形式），由JVM在运行时对其解释并执行，这种方式被成为字节码解释执行方式。
过程： 字节码的指令是一种所有JVM均能识别的通用格式，格式类似汇编语言格式，如astore、aload、pop、return等数的保存、数的读取、出栈、函数返回等指令。JVM会解释这些指令，并且执行它们，执行过程中JVM会对其线程堆栈和程序计数器等进行管理。
拓展学习点：栈顶缓存、部分栈帧共享
编译执行
目的：为了提升代码执行性能（解释执行效率较低），Sun JDK提供将字节码编译为机器码的支持。编译在运行时进行，通常被成为JIT编译器。
Hotspot VM：Sun JDK 在执行过程中对执行频率高的代码进行编译，对执行不频繁的代码则继续采用解释的方式，因此Sun JDK又被成为Hotspot VM。
编译模式：-client 和 –server。默认情况下，JVM会根据机器的配置默认启用某种模式，但也可以通过给JVM传递参数的方式指定其JIT模式。默认情况下有两个以上物理处理器以及2G以上物理内存的机器会启用server模式，否则启用client模式。
性能测试环境：依据应用服务器配置，JBoss会默认设置成-server模式。
JDK Tools：不同模式下，JDK Tools的功能点可能有所不同，Server模式下更多。
编译执行性能优化
Client模式：也称C1模式，在编译成本地代码时主要进行方法内联、去虚拟化和冗余削除优化。
Server模式：也称C2模式，在C1优化的基础上，还会进行标量替换（将需要引用的point.x变量用局部变量x的形式代码以减少对引用的访问时间）、栈上分配（当对象在方法体外未被引用时，可直接在栈上分配，方法执行完成后自动回收该对象）和同步削除（同步方式编写但实际并未同步访问时去除同步）三种形式的优化。
在JVM进行优化后，如果编译的机器码不再符合优化的条件，则会回到解释方式执行。如：原来未同步访问的代码后来有同步访问了；原来只有一个实现类的接口现在用到多个实现类了等。
扩展学习点：OSR（On Stack Replace）编译机制，JDK 7多层编译机制。
字节码解释执行 vs. 编译执行
解释执行比编译执行更节省内存，启动时解释执行的启动速度更快
编译执行的性能更高
解释执行or编译执行计数器：-CompileThreshold（方法被调用次数），-OnStackReplacePercentage（是否触发OSR编译的阀值）
4. 反射执行
反射过程
动态加载事先并不知道类型的类，并执行某指定的方法，Java主要通过Class类和java.lang.reflect包共同对反射的概念进行支持。
反射机制使得框架代码可以很灵活的实现对象的调用
性能关注点
反射的实现提升了代码的灵活性，但其整个过程比直接编译成字节码的调用复杂的多，因此性能比直接执行慢一些。
Sun JDK中反射执行的性能随着JDK版本升级也在提升，JDK 6后的表现与直接执行差距不大。
getMethod相对消耗性能，而method.invoke的性能更好（仅比直接调用低一点）
性能测试思考
反射动态生成的类对象，其在JVM运行时加载会使得Perm区内存使用率上升。
Dead Class Object会在JVM GC回收时被正常回收掉，具体触发机制是怎样的？
