首先我想从宏观上介绍一下Java虚拟机的工作原理。从最初的我们编写的Java源文件（.java文件）是如何一步步执行的，如下图所示，首先Java源文件经过前端编译器（javac或ECJ）将.java文件编译为Java字节码文件，然后JRE加载Java字节码文件，载入系统分配给JVM的内存区，然后执行引擎解释或编译类文件，再由即时编译器将字节码转化为机器码。主要介绍下图中的类加载器和运行时数据区两个部分。
类加载
类加载指将类的字节码文件（.class）中的二进制数据读入内存，将其放在运行时数据区的方法区内，然后在堆上创建java.lang.Class对象，封装类在方法区内的数据结构。类加载的最终产品是位于堆中的类对象，类对象封装了类在方法区内的数据结构，并且向JAVA程序提供了访问方法区内数据结构的接口。如下是类加载器的层次关系图。
启动类加载器（BootstrapClassLoader）：在JVM运行时被创建，负责加载存放在JDK安装目录下的jre\lib的类文件，或者被-Xbootclasspath参数指定的路径中，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类无法被JAVA程序直接引用。
扩展类加载器（Extension ClassLoader）：该类加载器负责加载JDK安装目录下的\jre\lib\ext的类，或者由java.ext.dirs系统变量指定路径中的所有类库，开发者也可以直接使用扩展类加载器。
应用程序类加载器（AppClassLoader）：负责加载用户类路径（Classpath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有定义过自己的类加载器，该类加载器为默认的类加载器。
用户自定义类加载器（User ClassLoader）：JVM自带的类加载器是从本地文件系统加载标准的java class文件，而自定义的类加载器可以做到在执行非置信代码之前，自动验证数字签名，动态地创建符合用户特定需要的定制化构建类，从特定的场所（数据库、网络中）取得java class。
注意如上的类加载器并不是通过继承的方式实现的，而是通过组合的方式实现的。而JAVA虚拟机的加载模式是一种委派模式，如上图中的1-7步所示。下层的加载器能够看到上层加载器中的类，反之则不行。类加载器可以加载类但是不能卸载类。说了一大堆，还是感觉需要拿点代码说事。
首先我们先定义自己的类加载器MyClassLoader，继承自ClassLoader，并覆盖了父类的findClass(String name)方法
我们如何利用我们定义的类加载器加载指定的字节码文件（.class）呢？如通过MyClassLoader加载C:\\Users\\Administrator\\下的Test.class字节码文件，代码如下所示：
public class Client {
public static void main(String[] args) {
// TODO Auto-generated method stub
//MyClassLoader的父类加载器为系统默认的加载器AppClassLoader
MyClassLoader myCLoader = new MyClassLoader("MyClassLoader");
//指定MyClassLoader的父类加载器为ExtClassLoader
//MyClassLoader myCLoader = new MyClassLoader(ClassLoader.getSystemClassLoader().getParent(),"MyClassLoader");
myCLoader.setPath("C:\\Users\\Administrator\\");
Class<?> clazz;
try {
clazz = myCLoader.loadClass("Test");
Field[] filed = clazz.getFields(); //获取加载类的属性字段
Method[] methods = clazz.getMethods(); //获取加载类的方法字段
System.out.println("该类的类加载器为：" + clazz.getClassLoader());
System.out.println("该类的类加载器的父类为:" + clazz.getClassLoader().getParent());
System.out.println("该类的名称为：" + clazz.getName());
} catch (ClassNotFoundException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
运行时数据区
字节码的加载第一步，其后分别是认证、准备、解析、初始化，那么这些步骤又具体做了哪些工作，以及他们会对运行时数据区缠身什么影响呢？如下图所示：
如下我们将介绍运行时数据区，主要分为方法区、Java堆、虚拟机栈、本地方法栈、程序计数器。其中方法区和Java堆一样，是各个线程共享的内存区域，而虚拟机栈、本地方法栈、程序计数器是线程私有的内存区。
常量池：这个名词可能大家也经常见，它是方法区的一部分。Class文件除了有类的版本、字段、方法、接口等描述信息外，还有一项信息就是常量池，用于存放编译期生成的各种字面量和符号引用。Java虚拟机运行期间，也可能将新的常量放入常量池（如String类的intern()方法）。
Java堆：Java堆是Java虚拟机所管理的内存中最大的一块，被进程的所有线程共享，在虚拟机启动时被创建。该区域的唯一目的就是存放对象实例，几乎所有的对象实例都在这里分配内存，随着JIT编译器的发展与逃逸分支技术逐渐成熟，栈上分配、标量替换等优化技术使得对象在堆上的分配内存变得不是那么“绝对”。Java堆是垃圾收集器管理的主要区域。由于现在的收集器基本都采用分代收集算法，所以Java堆中还可以分为老年代和新生代(Eden、From Survivor、To Survivor)。根据Java虚拟机规范，Java堆可以处于物理上不连续的内存空间，只要逻辑上连续即可。该区域的大小可以通过-Xmx和-Xms参数来扩展，如果堆中没有内存完成实例分配，并且堆也无法扩展，将会抛出OutOfMemoryError异常。
方法区：用于存储被Java虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据。不同于Java堆的是，Java虚拟机规范对方法区的限制非常宽松，可以选择不实现垃圾收集。但并非数据进入了方法区就“永久”存在了，这区域内存回收目标主要是针对常量池的回收和对类型的卸载。如果该区域内存不足也会抛出OutOfMemoryError异常。
虚拟机栈：线程私有，生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。如果请求的站深度大于虚拟机所允许的深度，将抛出StackOverflowError异常，虚拟机栈在动态扩展时如果无法申请到足够的内存，就会抛出OutOfMemoryError异常。
本地方法栈：与虚拟机栈类似，不过虚拟机栈是为虚拟机执行Java方法（字节码）服务，而本地方法栈则是为虚拟机使用到的Native方法服务。该区域同样会报StackOverflowError和OutOfMemoryError异常。
程序计数器：一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器完成。如果线程正在执行一个Java方法，计数器记录的是正在执行的虚拟机字节码指令的地址，如果正在执行的是Native方法，这个计数器值为空。此内存区域是唯一一个在Java虚拟机规范中没有规定任何OutOfMemoryError情况的区域。
写了这么多，感觉还是少一个例子。通过最简单的一段代码解释一下，程序在运行时数据区个部分的变化情况。
public class Test{
public static void main(String[] args){
String name = "best.lei";
sayHello(name);
}
public static void sayHello(String name){
System.out.println("Hello " + name);
}
}
通过编译器将Test.java文件编译为Test.class，利用javap -verbose Test.class对编译后的字节码进行分析，如下图所示：
我们在看看运行时数据区的变化：
一、类加载器
首先来看一下Java程序的执行过程。
从这个框图很容易大体上了解java程序工作原理。首先，你写好java代码，保存到硬盘当中。然后你在命令行中输入
javac YourClassName.java
此时，你的java代码就被编译成字节码（.class).如果你是在Eclipse IDE或者其他开发工具中，你保存代码的时候，开发工具已经帮你完成了上述的编译工作，因此你可以在对应的目录下看到class文件。此时的class文件依然是保存在硬盘中，因此，当你在命令行中运行
java YourClassName
就完成了上面红色方框中的工作。JRE的来加载器从硬盘中读取class文件，载入到系统分配给JVM的内存区域--运行数据区（Runtime Data Areas). 然后执行引擎解释或者编译类文件，转化成特定CPU的机器码，CPU执行机器码，至此完成整个过程。
接下来就重点研究一下类加载器究竟为何物？又是如何工作的？
首先看一下来加载器的一些特点，有点抽象，不过总有帮助的。
》》层级结构
类加载器被组织成一种层级结构关系，也就是父子关系。其中，Bootstrap是所有类加载器的父亲。如下图所示：
--Bootstrap class loader：
当运行java虚拟机时，这个类加载器被创建，它加载一些基本的Java API，包括Object这个类。需要注意的是，这个类加载器不是用java语言写的，而是用C/C++写的。
--Extension class loader:
这个加载器加载出了基本API之外的一些拓展类，包括一些与安全性能相关的类。（目前了解得不是很深，只能笼统说，待日后再详细说明）
--System Class Loader:
它加载应用程序中的类，也就是在你的classpath中配置的类。
--User-Defined Class Loader:
这是开发人员通过拓展ClassLoader类定义的自定义加载器，加载程序员定义的一些类。
》》委派模式（Delegation Mode）
仔细看上面的层次结构，当JVM加载一个类的时候，下层的加载器会将将任务委托给上一层类加载器，上一层加载检查它的命名空间中是否已经加载这个类，如果已经加载，直接使用这个类。如果没有加载，继续往上委托直到顶部。检查完了之后，按照相反的顺序进行加载，如果Bootstrap加载器找不到这个类，则往下委托，直到找到类文件。对于某个特定的类加载器来说，一个Java类只能被载入一次，也就是说在Java虚拟机中，类的完整标识是（classLoader，package，className）。一个雷可以被不同的类加载器加载。
举个具体的例子来说明，现在加入我有一个自己定义的类MyClass需要加载，如果不指定的话，一般交App（System）加载。接到任务后，System检查自己的库里是否已经有这个类，发现没有之后委托给Extension，Extension进行同样的检查，发现还是没有继续往上委托，最顶层的Boots发现自己库里也没有，于是根据它的路径（Java 核心类库，如java.lang）尝试去加载，没找到这个MaClass类，于是只好（人家看好你，交给你完成，你无能为力，只好交给别人啦）往下委托给Extension，Extension到自己的路径（JAVA_HOME/jre/lib/ext)是找，还是没找到，继续往下，此时System加载器到classpath路径寻找，找到了，于是加载到Java虚拟机。
现在假设我们将这个类放到JAVA_HOME/jre/lib/ext这个路径中去（相当于交给Extension加载器加载），按照同样的规则，最后由Extension加载器加载MyClass类，看到了吧，统一各类被两次加载到JVM，但是每次都是由不同的ClassLoader完成。
》》可见性限制
下层的加载器能够看到上层加载器中的类，反之则不行，也就是是说委托只能从下到上。
》》不允许卸载类
类加载器可以加载一个类，但是它不能卸载一个类。但是类加载器可以被删除或者被创建。
当类加载完毕之后，JVM继续按照下图完成其他工作：
框图中各个步骤简单介绍如下：
Loading：文章前面介绍的类加载，将文件系统中的Class文件载入到JVM内存（运行数据区域）
Verifying：检查载入的类文件是否符合Java规范和虚拟机规范。
Preparing：为这个类分配所需要的内存，确定这个类的属性、方法等所需的数据结构。（Prepare a data structure that assigns the memory required by classes and indicates the fields, methods, and interfaces defined in the class.）
Resolving：将该类常量池中的符号引用都改变为直接引用。（不是很理解）
Initialing：初始化类的局部变量，为静态域赋值，同时执行静态初始化块。
那么，Class Loader在加载类的时候，究竟做了些什么工作呢？
要了解这其中的细节，必须得先详细介绍一下运行数据区域。
二、运行数据区域
Runtime Data Areas：当运行一个JVM示例时，系统将分配给它一块内存区域（这块内存区域的大小可以设置的），这一内存区域由JVM自己来管理。从这一块内存中分出一块用来存储一些运行数据，例如创建的对象，传递给方法的参数，局部变量，返回值等等。分出来的这一块就称为运行数据区域。运行数据区域可以划分为6大块：Java栈、程序计数寄存器（PC寄存器）、本地方法栈（Native Method Stack）、Java堆、方法区域、运行常量池（Runtime Constant Pool）。运行常量池本应该属于方法区，但是由于其重要性，JVM规范将其独立出来说明。其中，前面3各区域（PC寄存器、Java栈、本地方法栈）是每个线程独自拥有的，后三者则是整个JVM实例中的所有线程共有的。这六大块如下图所示：
》PC计数器：
每一个线程都拥有一个PC计数器，当线程启动（start）时，PC计数器被创建，这个计数器存放当前正在被执行的字节码指令（JVM指令）的地址。
》Java栈：
同样的，Java栈也是每个线程单独拥有，线程启动时创建。这个栈中存放着一系列的栈帧（Stack Frame），JVM只能进行压入（Push）和弹出（Pop）栈帧这两种操作。每当调用一个方法时，JVM就往栈里压入一个栈帧，方法结束返回时弹出栈帧。如果方法执行时出现异常，可以调用printStackTrace等方法来查看栈的情况。栈的示意图如下：
OK。现在我们再来详细看看每一个栈帧中都放着什么东西。从示意图很容易看出，每个栈帧包含三个部分：本地变量数组，操作数栈，方法所属类的常量池引用。
》局部（本地）变量数组：
局部（本地）变量数组中，从0开始按顺序存放方法所属对象的引用、传递给方法的参数、局部变量。举个例子：
public void doSomething(int a, double b, Object o) {
...
}
这个方法的栈帧中的局部变量存储的内容分别是：
0: this
1: a
2,3:b
4:0
看仔细了，其中double类型的b需要两个连续的索引。取值的时候，取出的是2这个索引中的值。如果是静态方法，则数组第0个不存放this引用，而是直接存储传递的参数。
》操作数栈：
操作数栈中存放方法执行时的一些中间变量，JVM在执行方法时压入或者弹出这些变量。其实，操作数栈是方法真正工作的地方，执行方法时，局部变量数组与操作数栈根据方法定义进行数据交换。例如，执行以下代码时，操作数栈的情况如下：
int a = 90;
int b = 10;
int c = a + b;
注意在这个图中，操作数栈的地步是在上边，所以先压入的100位于上方。可以看出，操作数栈其实是一个数据临时存储区，存放一些中间变量，方法结束了，操作数栈也就没有啦。
》栈帧中数据引用：
除了局部变量数组和操作数栈之外，栈帧还需要一个常量池的引用。当JVM执行到需要常量池的数据时，就是通过这个引用来访问常量池的。栈帧中的数据还要负责处理方法的返回和异常。如果通过return返回，则将该方法的栈帧从Java栈中弹出。如果方法有返回值，则将返回值压入到调用该方法的方法的操作数栈中。另外，数据区中还保存中该方法可能的异常表的引用。下面的例子用来说明：
class Example3C{
public static void addAndPrint(){
double result = addTwoTypes(1,88.88);
System.out.println(result);
}
public static double addTwoTypes(int i, double d){
return i+d;
}
}
执行上述代码时，Java栈如下图所示：
花些时间好好研究上图。一样需要注意的是，栈的底部在上方，先押人员addAndPrint方法的栈帧，再压入addTwoTypes方法的栈帧。上图最右边的文字说明有错误，应该是addTwoTypes的执行结果存放在addAndPrint的操作数栈中。
》》本地方法栈
当程序通过JNI（Java Native Interface）调用本地方法（如C或者C++代码）时，就根据本地方法的语言类型建立相应的栈。
》》方法区域
方法区域是一个JVM实例中的所有线程共享的，当启动一个JVM实例时，方法区域被创建。它用于存运行放常量池、有关域和方法的信息、静态变量、类和方法的字节码。不同的JVM实现方式在实现方法区域的时候会有所区别。Oracle的HotSpot称之为永久区域（Permanent Area）或者永久代（Permanent Generation）。
》》运行常量池
这个区域存放类和接口的常量，除此之外，它还存放方法和域的所有引用。当一个方法或者域被引用的时候，JVM就通过运行常量池中的这些引用来查找方法和域在内存中的的实际地址。
》》堆（Heap）
堆中存放的是程序创建的对象或者实例。这个区域对JVM的性能影响很大。垃圾回收机制处理的正是这一块内存区域。
所以，类加载器加载其实就是根据编译后的Class文件，将java字节码载入JVM内存，并完成对运行数据处于的初始化工作，供执行引擎执行。
三、 执行引擎（Execution Engine）
类加载器将字节码载入内存之后，执行引擎以Java 字节码指令为但愿，读取Java字节码。问题是，现在的java字节码机器是读不懂的，因此还必须想办法将字节码转化成平台相关的机器码。这个过程可以由解释器来执行，也可以有即时编译器（JIT Compiler）来完成。
