一、类加载器
　　类加载器（ClassLoader），顾名思义，即加载类的东西。在我们使用一个类之前，JVM需要先将该类的字节码文件（.class文件）从磁盘、网络或其他来源加载到内存中，并对字节码进行解析生成对应的Class对象，这是类加载器的功能。我们可以利用类加载器，实现类的动态加载。
　　二、类的加载机制
　　在Java中，采用双亲委派机制来实现类的加载。那什么是双亲委派机制？在Java Doc中有这样一段描述：
　　The ClassLoader class uses a delegation model to search for classes and resources. Each instance of ClassLoader has an associated parent class loader. When requested to find a class or resource， a ClassLoader instance will delegate the search for the class or resource to its parent class loader before attempting to find the class or resource itself. The virtual machine's built-in class loader， called the "bootstrap class loader"， does not itself have a parent but may serve as the parent of a ClassLoader instance.
　　从以上描述中，我们可以总结出如下四点：
　　1、类的加载过程采用委托模式实现
　　2、每个 ClassLoader 都有一个父加载器。
　　3、类加载器在加载类之前会先递归的去尝试使用父加载器加载。
　　4、虚拟机有一个内建的启动类加载器（Bootstrap ClassLoader），该加载器没有父加载器，但是可以作为其他加载器的父加载器。
　　Java 提供三种类型的系统类加载器。第一种是启动类加载器，由C++语言实现，属于JVM的一部分，其作用是加载 <Java_Runtime_Home>/lib 目录中的文件，并且该类加载器只加载特定名称的文件（如 rt.jar），而不是该目录下所有的文件。另外两种是 Java 语言自身实现的类加载器，包括扩展类加载器（ExtClassLoader）和应用类加载器（AppClassLoader），扩展类加载器负责加载<Java_Runtime_Home>libext目录中或系统变量 java.ext.dirs 所指定的目录中的文件。应用程序类加载器负责加载用户类路径中的文件。用户可以直接使用扩展类加载器或系统类加载器来加载自己的类，但是用户无法直接使用启动类加载器，除了这两种类加载器以外，用户也可以自定义类加载器，加载流程如下图所示：

　　注意：这里父类加载器并不是通过继承关系来实现的，而是采用组合实现的。
　　我们可以通过一段程序来验证这个过程：
　　public class Test {
　　}
　　public class TestMain {
　　public static void main(String[] args) {
　　ClassLoader loader = Test.class.getClassLoader();
　　while (loader!=null){
　　System.out.println(loader);
　　loader = loader.getParent();
　　}
　　}
　　}
　　上面程序的运行结果如下所示:

　　从结果我们可以看出，默认情况下，用户自定义的类使用 AppClassLoader 加载，AppClassLoader 的父加载器为 ExtClassLoader，但是 ExtClassLoader 的父加载器却显示为空，这是什么原因呢？究其缘由，启动类加载器属于 JVM 的一部分，它不是由 Java 语言实现的，在 Java 中无法直接引用，所以才返回空。但如果是这样，该怎么实现 ExtClassLoader 与 启动类加载器之间双亲委派机制？我们可以参考一下源码：
　　protected Class<?> loadClass(String name， boolean resolve)
　　throws ClassNotFoundException
　　{
　　synchronized (getClassLoadingLock(name)) {
　　// First， check if the class has already been loaded
　　Class<?> c = findLoadedClass(name);
　　if (c == null) {
　　long t0 = System.nanoTime();
　　try {
　　if (parent != null) {
　　c = parent.loadClass(name， false);
　　} else {
　　c = findBootstrapClassOrNull(name);
　　}
　　} catch (ClassNotFoundException e) {
　　// ClassNotFoundException thrown if class not found
　　// from the non-null parent class loader
　　}
　　if (c == null) {
　　// If still not found， then invoke findClass in order
　　// to find the class.
　　long t1 = System.nanoTime();
　　c = findClass(name);
　　// this is the defining class loader; record the stats
　　sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
　　sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
　　sun.misc.PerfCounter.getFindClasses().increment();
　　}
　　}
　　if (resolve) {
　　resolveClass(c);
　　}
　　return c;
　　}
　　}
　　从源码可以看出，ExtClassLoader 和 AppClassLoader都继承自 ClassLoader 类，ClassLoader 类中通过 loadClass 方法来实现双亲委派机制。整个类的加载过程可分为如下三步：
　　1、查找对应的类是否已经加载。
　　2、若未加载，则判断当前类加载器的父加载器是否为空，不为空则委托给父类去加载，否则调用启动类加载器加载（findBootstrapClassOrNull 再往下会调用一个 native 方法）。
　　3、若第二步加载失败，则调用当前类加载器加载。
　　通过上面这段程序，可以很清楚的看出扩展类加载器与启动类加载器之间是如何实现委托模式的。
　　现在，我们再验证另一个问题。我们将刚才的Test类打成jar包，将其放置在 <Java_Runtime_Home>libext 目录下，然后再次运行上面的代码，结果如下：