一， 虚拟机的类加载过程
类加载：虚拟机把描述类的数据从 .class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被直接使用的java类型，这就是虚拟机的类加载机制。
类的生命周期包括：
加载（Loading）、
验证（Verification）、准备（Preparation）、解析（Resolution）、
初始化（Initialization）、使用（Using）、卸载（Unloading）等七个阶段，
其中验证、准备和解析三个部分统称为链接（Linking）。而类的加载指的就是从 加载 到 初始化 这五个阶段。
这七个阶段的顺序除了解析阶段和使用阶段外，其它几个阶段的开始顺序是确定的，必须按这种顺序按部就班的开始，但不要求按这种顺序按部就班的完成，这些阶段通常是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用或激活另外一个阶段。解析阶段在某些情况下可以在初始化阶段之后再开始，以支持java的运行时绑定（RTTI），而使用阶段则是按类文件内容的定义的不同而在不同的阶段进行。
虚拟机规范对于何时进行加载这一阶段并没有强制约束，但对于初始化阶段，虚拟机规范是严格规定了有且只有四种情况必须立即对类进行初始化：
a、遇到new,getstatic,putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指定的场景是：使用new关键字实例化对象，读取或设置一个类的静态字段以及调用一个类的静态方法的时候。当然，被final修饰并在编译期就把结果放入常量池的静态字段不属于这些场景，这类静态字段的值在编译期时就会被编译器优化而直接放入常量池，其引用直接指向其在常量池的入口。
b、使用java.lang.reflect包的方法对类进行反射调用时，如果类没有进行过初始化，则需要先触发其初始化。
c、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
d、当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的类），虚拟机会先初始化这个主类。
以上四种场景中的行为称为对一个类进行主动引用，除此之外所有引用类的方式都不会触发初始化，称为被动引用。
接口的加载过程与类加载过程最主要的区别在于第三点，即当初始化一个接口时，并不需要先初始化其父接口，而是只有真正使用到父接口中的字段的时候才会初始化。
以下对类加载的各个阶段进行简单的说明。
加载阶段，虚拟机需要完成三件事：通过一个类的全限定名来获取定义此类的二进制字节流，将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构，在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
验证阶段，不同虚拟机会进行不同类验证的实现，但大致都会完成以下四个阶段的检验过程：文件格式验证（验证字节流是否符合Class文件格式的规范，并能被当前版本的虚拟机处理），元数据验证（对字节码描述信息进行语义分析，保证其描述信息符合java语言规范），字节码验证（对类方法体进行数据流和控制流分析，保证类的方法在运行时不会做出危害虚拟机的行为）和符号引用验证（发生在将符号引用转化为直接引用的时候，在解析阶段中发生）。
准备阶段，正式为类成员变量（注意，不是实例成员变量，实例变量会在对象实例化时随着对象一起分配在java堆上）分配内存并设置类变量初始值（通常情况下是数据类型的零值，不进行赋值操作）的阶段，这些内存都将在方法区中进行分配。
例：public static int value=123;则在准备阶段过后，value的初始值为0而不是123，赋值指令是在初始化阶段通过构造方法来执行的。
解析阶段，虚拟机将常量池内的符号引用替换为直接引用的过程。符号引用与内存布局无关，而直接引用的目标必定已经在内存中存在。解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行。
初始化阶段，真正开始执行类中定义的java程序代码（字节码），是执行类构造器<clinit>()方法的过程。
<clinit>()方法的一些特点：
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static｛｝）中的语句合并产生的，编译器收集顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量。
<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会在子类的<clinit>()方法执行之前完成父类<clinit>()方法的执行。
由于父类的<clinit>() 方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，则编译器可以不为这个类生成<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法，不同于类的地方是执行接口的<clinit>()方法时不坱要先执行父类的<clinit>()方法。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，则只有一个线程去执行这个类的<clinit>()方法，其它线程阻塞等待，直到活动线程执行<clinit>()方法完毕。
二，默认的类加载机制
类的加载是通过ClassLoader实现的， jvm提供了三种ClassLoader的实现， 分别是：
1，BootStrap ClassLoader：称为启动类加载器，它集成在jvm中，是Java类加载层次中最顶层的类加载器，负责加载JDK中的核心类库（JAVA_HOME/jre/lib下的jar 以及 lib/classes下的类或jar等），如：rt.jar、resources.jar、charsets.jar等，可以通过 系统属性 sun.boot.class.path 得到核心类库的全部类路径 : System.out.println(System.getProperty("sun.boot.class.path"));
另外，Bootstrap ClassLoader还负责构造Extension ClassLoader和App ClassLoader类加载器。
2，Extension ClassLoader：称为扩展类加载器，负责加载Java的扩展类库，默认加载JAVA_HOME/jre/lib/ext/目下的所有jar。
3，App ClassLoader：称为系统类加载器，负责加载应用程序classpath目录下的所有jar和class文件。
加载机制： 双亲委托模型（此处省略若干字..）, 注意，判断两个类是否相同，不单要看类名，还要看是否是由同一个类加载其加载的
三， 定制的ClassLoader
Java环境已经提供了三种默认的ClassLoader，但是它们只能加载指定目录下的jar和class，如果因为某些原因我们想把一些类动态资源根据需要来决策何时加载的话，我们就必须定制自己的类加载器，实现一些定制的加载策略。
定制一个ClassLoader需要两步：
1、继承java.lang.ClassLoader
2、重写父类的findClass方法
JDK已经在loadClass方法中帮我们实现了ClassLoader搜索类的算法，当在loadClass方法中搜索不到类时，loadClass方法就会调用findClass方法来搜索类，所以我们只需重写该方法即可。如没有特殊的要求，一般不建议重写loadClass搜索类的算法。从loadClass的实现可以看到双亲委托模型的过程，首先在已经加载的类中查找（查看是否已加载），若否则交给parent 进行加载，如果parent不能加载，才调用自己的findClass进行加载， 所以为了遵守双亲委托模型，定制的classloader只需要重写findClass 方法即可。 （android中的字节码是经过格式优化的，不需要链接）
ClassLoader.java:
/**
* Loads the class with the specified name, optionally linking it after
* loading. The following steps are performed:
* <ol>
* <li> Call {@link #findLoadedClass(String)} to determine if the requested
* class has already been loaded.</li>
* <li>If the class has not yet been loaded: Invoke this method on the
* parent class loader.</li>
* <li>If the class has still not been loaded: Call
* {@link #findClass(String)} to find the class.</li>
* </ol>
* <p>
* <strong>Note:</strong> In the Android reference implementation, the
* {@code resolve} parameter is ignored; classes are never linked.
* </p>
*
* @return the {@code Class} object.
* @param className
* the name of the class to look for.
* @param resolve
* Indicates if the class should be resolved after loading. This
* parameter is ignored on the Android reference implementation;
* classes are not resolved.
* @throws ClassNotFoundException
* if the class can not be found.
*/
protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {
Class<?> clazz = findLoadedClass(className);
if (clazz == null) {
try {
clazz = parent.loadClass(className, false);
} catch (ClassNotFoundException e) {
// Don't want to see this.
}
if (clazz == null) {
clazz = findClass(className);
}
}
return clazz;
}
参考：
http://my.oschina.net/u/1269532/blog/166888
http://blog.csdn.net/xyang81/article/details/7292380
转自：