Java虚拟机类加载机制是把Class类文件加载到内存，并对Class文件中的数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型的过程。
7.1概述
与那些在编译时需要进行链接工作的语言不同，在Java语言里面，类型的加载和链接过程都是在程序运行期间完成的（其实C++也是分为静态链接库和动态链接库的），这样会在类加载时稍微增加一些性能开销，但是却能为Java应用程序提供高度的灵活性，Java中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。
7.2类加载的时机
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中验证、准备和解析三个部分统称为连接，它们开始的顺序如下图所示：
其中类加载的过程中加载、验证、准备、初始化、卸载五个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
这里简要说明下Java中的绑定：绑定指的是把一个方法的调用与方法所在的类(方法主体)关联起来，对java来说，绑定分为静态绑定和动态绑定：
- 静态绑定：即前期绑定。在程序执行前方法已经被绑定，此时由编译器或其它连接程序实现。针对java，简单的可以理解为程序编译期的绑定。java当中的方法只有final，static，private和构造方法是前期绑定的。
- 动态绑定：即晚期绑定，也叫运行时绑定。在运行时根据具体对象的类型进行绑定。在java中，几乎所有的方法都是后期绑定的。
虚拟机规范严格规定了有且只有5种情况必须立即对类进行初始化：（称为对类的主动引用）
(1)遇到new、getstatic、putstatic和invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发器初始化。
生成这四条指令最常见的 Java 代码场景是：
使用 new 关键字实例化对象时、读取或设置一个类的静态字段（static）时（被 static 修饰又被 final 修饰的，已在编译期把结果放入常量池的静态字段除外）、以及调用一个类的静态方法时。
(2)使用java.lang.reflect包的方法对类进行反射调用的时候。
(3)当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
(4)当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
(5)当使用jdk1.7的动态语言进行支持的时候，如果一个java.lang.invoke.methodHandle实例最后的解析结果ref_getstatic等的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先触发其初始化。
除此之外，所有引用类的方式都不会触发初始化，称为被动引用：
（1）通过子类引用父类的静态字段，不会导致子类初始化，对于静态字段，只有直接定义这个字段的类才会被初始化。
（2）通过数组定义来引用类，不会触发此类的初始化。
（3）常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。
接口的加载和类的加载稍有一些不同，但是接口也有初始化的过程，这一点与类是一致的，编译器会为接口生成“()”类构造器，用于初始化接口中定义的成员变量，真正的区别是类在初始化的过程中要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都进行了初始化，只有在真正使用到了父接口的时候才会初始化。
7.3类加载的过程
加载时类加载过程的第一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取其定义的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在Java堆中生成一个代表这个类的java.lang.Class对象，作为对方法区中这些数据的访问入口。
注意，这里第1条中的二进制字节流并不只是单纯地从Class文件中获取，比如它还可以从Jar包中获取、从网络中获取（最典型的应用便是Applet）、由其他文件生成（JSP应用）等。
相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。
加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在Java堆中也创建一个java.lang.Class类的对象，这样便可以通过该对象访问方法区中的这些数据。
7.4类加载器
7.4.1类与类加载器
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类的加载阶段。对于任意一个类，都需要由它的类加载器和这个类本身一同确定其在就Java虚拟机中的唯一性，也就是说，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。
这里的“相等”包括了代表类的Class对象的equals()、isAssignableFrom()、isInstance()等方法的返回结果，也包括了使用instanceof关键字对对象所属关系的判定结果。
7.4.2双亲委派模型
站在Java虚拟机的角度来讲，只存在两种不同的类加载器：
- 启动类加载器：它使用C++实现（这里仅限于Hotspot，也就是JDK1.5之后默认的虚拟机，有很多其他的虚拟机是用Java语言实现的），是虚拟机自身的一部分。
- 所有其他的类加载器：这些类加载器都由Java语言实现，独立于虚拟机之外，并且全部继承自抽象类java.lang.ClassLoader，这些类加载器需要由启动类加载器加载到内存中之后才能去加载其他的类。
站在Java开发人员的角度来看，类加载器可以大致划分为以下三类：
- 启动类加载器：Bootstrap ClassLoader，跟上面相同。它负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
- 扩展类加载器：Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库（如javax.*开头的类），开发者可以直接使用扩展类加载器。
- 应用程序类加载器：Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。
这种层次关系称为类加载器的双亲委派模型。
双亲委派模型要求除了启动类加载器之外，其余的类加载器都应当有自己的父类加载器，这种父子关系一般用组合实现：一个类加载器收到类加载请求时，首先委托给父类去加载，父类又递归地委托给自己的父类去加载，只有在父类无法加载时才自己尝试去加载。
类加载器双亲委派模型是从JDK1.2以后引入的，并且只是一种推荐的模型，不是强制要求的。
适当地不遵守双亲委派模型可以实现一些特殊的类加载需求，比如热部署。
双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。
相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话。如果用户编写了一个称为“java.lang.Object”的类，并存放在程序的ClassPath中，那系统中将会出现多个不同的Object类，java类型体系中最基础的行为也就无法保证。应用程序也将会一片混乱。
深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)PDF版下载：
http://download.csdn.net/detail/xunzaosiyecao/9648998
作者：jiankunking 出处：http://blog.csdn.net/jiankunking