Java虚拟机类加载机制是把Class类文件加载到内存，并对Class文件中的数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的java类型的过程。

    java可动态扩展的语言特性就是依赖运行期动态加载和动态链接这个特点实现的。

    类从被加载到虚拟机内存中开始，到卸载出内存为止，整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载七个阶段，其中验证、准备、解析3个部分统称为连接，加载、验证、准备、初始化、卸载这5个阶段的顺序是一定的，类的加载过程必须按照这种顺序按部就班的开始，但是并不一定按部就班的执行，因为这些阶段通常都是互相交叉的混合式进行的，通常会在一个阶段执行的过程中调用、激活另外一个阶段，而且解析阶段在某些情况下可以在初始化阶段之后进行，这是为了支持java语言的动态绑定。

虚拟机规范严格规定了有且只有5种情况必须立即对类进行初始化：（称为对类的主动引用）

(1)遇到new、getstatic、putstatic和invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发器初始化，

(2)使用java.lang.reflect包的方法对类进行反射调用的时候，

(3)当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化，

(4)当虚拟机启动时，用户需要指定一个要执行的主类，虚拟机会先初始化这个主类，

(5)当使用jdk1.7的动态语言进行支持的时候，如果一个java.lang.invoke.methodHandle实例最后的解析结果ref_getstatic等的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先触发其初始化。

除此之外，所有引用类的方式都不会触发初始化，称为被动引用：

（1）通过子类引用父类的静态字段，不会导致子类初始化，对于静态字段，只有直接定义这个字段的类才会被初始化，

（2）通过数组定义来引用类，不会触发此类的初始化

（3）常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化，

接口的加载和类的加载稍有一些不同，但是接口也有初始化的过程，这一点与类是一致的，上面的代码都是用静态语句块“static{}”来输出初始化信息，而接口不能使用“static{}”语句块，但编译器仍然会为接口生成“<clinit>()”类构造器，用于初始化接口中定义的成员变量，真正的区别是类在初始化的过程中要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其父接口全部都进行了初始化，只有在真正使用到了父接口的时候才会初始化，

类加载的过程：

在加载阶段，java虚拟机需要完成以下3件事：

a.通过一个类的全限定名来获取定义此类的二进制字节流。

b.将定义类的二进制字节流所代表的静态存储结构转换为方法区的运行时数据结构。

c.在java堆中生成一个代表该类的java.lang.Class对象，作为方法区数据的访问入口。

一个非数组类的加载阶段（即加载阶段中获取类的二进制字节流的动作）是开发人员可以控制的，但是对于数组类，情况有所不同，数组类本身不通过类加载器创建，他是由java虚拟机直接进行创建的，但是数组类的元素类型最终是要靠类加载器去创建，一个数组类的创建过程遵循的规则参考p215页

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中，方法区的数据存储格式由虚拟机自行定义，

验证阶段：

验证是连接阶段的第一步，目的是为了确保class文件的字节流中包含的心细符合当前虚拟机的要求，并且不会危害虚拟机自身的安全，java语言本身是相对安全的语言，使用纯粹的java代码无法做到诸如访问数组边界以外的数据，如果这样做了，编译器将拒绝编译，但是class文件并不一定要求用java源码编译而来，可以使用任何途径产生，所以虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。

验证的4个阶段：

1.文件格式验证：

    验证是否以魔数0xcafebabe开头，主、次版本号是否在当前虚拟机处理范围之内，常量池的常量是否有不被支持的敞亮类型等，主要目的是保证输入的字节流能正确的解析并存储于方法区之内，

2.元数据验证：

     对字节码描述的信息进行语义分析，保证信息符合java语言规范要求，主要包括的验证点为：这个类是否有父类，这个类的父类是否继承了不允许被继承的类，如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法等

3.字节码验证：

     主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，第二阶段对数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，如果一个类的方法体通过了字节码验证，也不能说明其一定是安全的，

由于数据流验证的高复杂性，避免消耗过多的时间，虚拟机在方法体的code属性的属性表增加了一项名为“stackmaptable”的属性，描述了方法体中所有的基本块开始时本地变量表和操作栈应有的状态，就不用根据程序推导这些状态的合法性 p218

4.符号引用验证：

       目的是确保解析动作能正常执行，发生在虚拟机将符号引用转换为直接引用的时候，

准备阶段：

     准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，首先这里的类变量不包括实例变量，实例变量将会在对象实例化的时候随着对象一起分配在java堆中，初始值一般是数据类型的零值，但是如果类字段的字段属性表中存在constantvalue（不变）属性,那么就会在准备阶段初始化为属性所指定的值，

解析阶段：

     解析是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用与虚拟机实现的内存布局无关，对同一个符号引用进行多次解析是很常见的事情，除invokedynamic外，虚拟机可以对第一次解析的结果进行缓存，从而避免解析动作重复进行，但是对于invokedynamic指令，因为其目的是用于动态语言支持，

四种引用的解析过程：

1.类或接口的解析：

2.字段解析：

3.类方法解析：

4.接口方法解析

  初始化阶段：

      类初始化阶段是类加载的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码，在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，是执行类构造器<clinit>()方法的过程，

首先看一下<clinit>()方法执行过程中的一些可能影响程序运行行为的特点和细节：

（1）<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在他之后的变量，在前面的静态语句块可以赋值，但是不能访问，

（2）<clinit>()方法与类的构造函数不同，他不需要显式的调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行以前，父类的方法已经执行完毕，

（3）由于父类的<clinit>（）方法先执行，则父类的静态语句块要优先于子类的变量赋值操作，

(4)<clinit>()方法对于类或接口来说不是必须的，如果一个类中没有定义静态语句块，没有对变量进行赋值操作，则编译器不会为这个类产生这个方法，

（5）执行接口中的<clinit>（）方法不需要先执行父接口的<clinit>()方法

  Java虚拟机的类加载是通过类加载器实现的，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，也就是说比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，

(1).BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA_HOME%\lib目录中的，或者通被-Xbootclasspath参数所指定的路径中的，并且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即使放在指定路径中也不会被加载)类库到虚拟机的内存中，启动类加载器无法被java程序直接引用。

(2).Extension ClassLoader：扩展类加载器，由sun.misc.Launcher$ExtClassLoader实现，负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

(3).Application ClassLoader：应用程序类加载器，由sun.misc.Launcher$AppClassLoader实现，负责加载用户类路径classpath上所指定的类库，是类加载器ClassLoader中的getSystemClassLoader()方法的返回值，开发者可以直接使用应用程序类加载器，如果程序中没有自定义过类加载器，该加载器就是程序中默认的类加载器。

注意：上述三个JDK提供的类加载器虽然是父子类加载器关系，但是没有使用继承，而是使用了组合关系。

从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程如下：

(1).如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。

(2).每一层的类加载器都把类加载请求委派给父类加载器，直到所有的类加载请求都应该传递给顶层的启动类加载器。

(3).如果顶层的启动类加载器无法完成加载请求，子类加载器尝试去加载，如果连最初发起类加载请求的类加载器也无法完成加载请求时，将会抛出ClassNotFoundException，而不再调用其子类加载器去进行类加载。

双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。双亲委派模式的实现： 

[java]
view plain
copy

1. protected synchronized Class loadClass(String name, Boolean resolve) throws ClassNotFoundException{  
2. //首先检查请求的类是否已经被加载过
3.     Class c = findLoadedClass(name);  
4. if(c == null){  
5. try{  
6. if(parent != null){//委派父类加载器加载
7.     c = parent.loadClass(name, false);  
8. }  
9. else{//委派启动类加载器加载
10.     c = findBootstrapClassOrNull(name);   
11. }  
12. }catch(ClassNotFoundException e){  
13. //父类加载器无法完成类加载请求
14. }  
15. if(c == null){//本身类加载器进行类加载
16.     c = findClass(name);  
17. }  
18. }  
19. if(resolve){  
20.     resolveClass(c);  
21. }  
22. return c;  
23. }  

若要实现自定义类加载器，只需要继承java.lang.ClassLoader 类，并且重写其findClass()方法即可。java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等，ClassLoader 中与加载类相关的方法如下：

注意：在JDK1.2之前，类加载尚未引入双亲委派模式，因此实现自定义类加载器时常常重写loadClass方法，提供双亲委派逻辑，从JDK1.2之后，双亲委派模式已经被引入到类加载体系中，自定义类加载器时不需要在自己写双亲委派的逻辑，因此不鼓励重写loadClass方法，而推荐重写findClass方法。

在Java中，任意一个类都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性，即比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提之下才有意义，否则，即使这两个类来源于同一个Class类文件，只要加载它的类加载器不相同，那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。例子代码如下：

[java]
view plain
copy

1. package com.test;  
3. public class ClassLoaderTest {  
4. public static void main(String[] args)throws Exception{  
5. //匿名内部类实现自定义类加载器
6.     ClassLoader myClassLoader = new ClassLoader(){  
7. protected Class findClass(String name)throws ClassNotFoundException{  
8. //获取类文件名
9.     String filename = name.substring(name.lastIndexOf(“.”) + 1) + “.class”;  
10.     InputStream in = getClass().getResourceAsStream(filename);  
11. if(in == null){  
12. throw RuntimeException(“Could not found class file:” + filename);  
13. }  
14. byte[] b = newbyte[in.available()];  
15. return defineClass(name, b, 0, b.length);  
16. }catch(IOException e){  
17. thrownew ClassNotFoundException(name);  
18. }  
19. };  
20. Object obj = myClassLoader.loadClass(“com.test.ClassLoaderTest”).newInstance();  
21. System.out.println(obj.getClass());  
22. System.out.println(obj instanceof com.test. ClassLoaderTest);  
23. }  
24. }  

输出结果如下：

com.test.ClassLoaderTest

false

之所以instanceof会返回false，是因为com.test.ClassLoaderTest类默认使用Application ClassLoader加载，而obj是通过自定义类加载器加载的，类加载不相同，因此不相等。

类加载器双亲委派模型是从JDK1.2以后引入的，并且只是一种推荐的模型，不是强制要求的，因此有一些没有遵循双亲委派模型的特例：

(1).在JDK1.2之前，自定义类加载器都要覆盖loadClass方法去实现加载类的功能，JDK1.2引入双亲委派模型之后，loadClass方法用于委派父类加载器进行类加载，只有父类加载器无法完成类加载请求时才调用自己的findClass方法进行类加载，因此在JDK1.2之前的类加载的loadClass方法没有遵循双亲委派模型，因此在JDK1.2之后，自定义类加载器不推荐覆盖loadClass方法，而只需要覆盖findClass方法即可。

(2).双亲委派模式很好地解决了各个类加载器的基础类统一问题，越基础的类由越上层的类加载器进行加载，但是这个基础类统一有一个不足，当基础类想要调用回下层的用户代码时无法委派子类加载器进行类加载。为了解决这个问题JDK引入了ThreadContext线程上下文，通过线程上下文的setContextClassLoader方法可以设置线程上下文类加载器。

JavaEE只是一个规范，sun公司只给出了接口规范，具体的实现由各个厂商进行实现，因此JNDI，JDBC,JAXB等这些第三方的实现库就可以被JDK的类库所调用。线程上下文类加载器也没有遵循双亲委派模型。

(3).近年来的热码替换，模块热部署等应用要求不用重启java虚拟机就可以实现代码模块的即插即用，催生了OSGi技术，在OSGi中类加载器体系被发展为网状结构。OSGi也没有完全遵循双亲委派模型。