参考：http://www.importnew.com/6581.html
Java 编译器会为虚拟机转换源指令。虚拟机代码存储在以 .class 为扩展名的类文件中，每个类文件都包含某个类或者接口的定义和代码实现。这些类文件必须由一个程序进行解释，该程序能够将虚拟机的指令集翻译成目标机器的机器语言。
虚拟机值加载程序执行时所需要的类文件。
类加载机制并非只使用单个的类加载器。每个 Java 程序至少拥有三个类加载器：
引导类加载器
扩展类加载器
系统类加载器（有时也称为应用类加载器）
引导类加载器负责加载系统类（通常从 JAR 文件 rt.jar 中进行加载）。它是虚拟机不可分割的一部分，而且通常是用 C 语言来实现的。引导类加载器没有对应的 ClassLoader 对象。
扩展类加载器用于从 jre/lib/ext 目录加载 “标准的扩展”。可以将 JAR 文件放入该目录，这样即使没有任何类路径，扩展类加载器也可以找到其中的各个类。
系统类加载器用于加载应用类。它在由 CLASSPATH 环境变量或者 -classpath 命令行选项设置的类路径中的目录里或者是 JAR/ZIP 文件里查找这些类。
在 Oracle 的 Java 语言实现中，扩展类加载器和系统类加载器都是用 Java 来实现的。它们都是 URLClassLoader 类的实例。
警告：如果将 JAR 文件放入 jre/lib/ext 目录中，并且在它的类中有一个类需要调用系统类或者扩展类，那么就会遇到麻烦。扩展类加载器并不使用类路径。
除了所有已经提到的位置，还可以从 jre/lib/endorsed 目录中加载类。这种机制只能用于将某个标准的 Java 类库替换为更新的版本（例如那些支持 XML 和 CORBA 的类）。
类加载器有一种父/子关系。除了引导类加载器外，每个类加载器都有一个父类加载器。根据规定，类加载器会为它的父类加载器提供一个机会，以便加载任何给定的类，并且只有在其父类加载器加载失败时，它才会加载该给定类。
某些程序具有插件架构，其中代码的某些部分是作为可选的插件打包的。如果插件被打包为 JAR 文件，那就可以直接用 URLClassLoader 类的实例去加载这些类。
1 package classloader; 2 3 import java.net.MalformedURLException; 4 import java.net.URL; 5 import java.net.URLClassLoader; 6 7 public class URLDemo { 8 9 public static void main(String[] args) throws MalformedURLException, ClassNotFoundException, InstantiationException, IllegalAccessException { 10 URL url= new URL("file:\\E:\\project_neon1\\Demo2\\commons-codec-1.9.jar"); 11 URLClassLoader pluginLoader = new URLClassLoader(new URL[] {url}); 12 Class<?> c1 = pluginLoader.loadClass("org.apache.commons.codec.binary.Base64"); 13 } 14 15 }
因为在 URLClassLoader 构造器中没有指定父类加载器，因此 pluginLoader 的父亲就是系统类加载器。
大多数时候，你不必操心类加载的层次结构。通常，类是由于其他的类需要它而被加载的，而这个过程对你是透明的。
偶尔，你也会需要干涉和指定类加载器。
考虑下面的例子：
你的应用的代码包含一个助手方法，它要调用 Class.forName(classNameString)。
这个方法是从一个插件类中被调用的。
而 classNameString 指定的正是一个包含在这个插件的 JAR 中类。
插件的作者很合理地期望这个类应该被加载。但是，助手方法的类是由系统类加载器加载的，这正式 Class.forName 所使用的类加载器。而对于它来说，在插件 JAR 中的类是不可视的，这种现象被称为类加载器倒置。
要解决这个问题，助手方法需要使用恰当的类加载器，它可以要求类加载器作为其一个参数传递给他。或者，它可以要求将恰当的类加载器设置成为当前线程的上下文类加载器。
每个线程都有一个对类加载器的引用，称为上下文类加载器。主线程的上下文类加载器是系统类加载器。当新线程创建时，它的上下文类加载器会被设置成为创建该线程的上下文类加载器。因此，如果你不做任何特殊的操作，那么所有线程就都将它们的上下文类加载器设置为系统类加载器。
可以通过下面的调用将上下文类加载器设置成为任何类加载器。
1 Thread t = Thread.currentThread(); 2 t.setContextClassLoader(loader);
然后助手方法可以获取这个上下文类加载器：
1 Thread t = Thread.currentThread(); 2 ClassLoader loader = t.getContextClassLoader(); 3 Class cl = loaser.loadClass(className);
当上下文类加载器设置为插件类加载器时，问题依旧存在。应用设计者必须作出决策：通常，当调用由不同的类加载器加载的插件类的方法时，进行上下文类加载器的设置是一种好的思路；或者，让助手方法的调用者设置上下文类加载器。
如果你编写了一个按名字来加载类的方法，那么让调用者在传递显示的类加载器和使用上下文类加载器之间进行选择就是一种好的做法。不要直接使用该方法所属的类的类加载器。
在同一个虚拟机中，可以有两个类，它们的类名和包名都是相同的。类是由它的全名和类的加载器来确定的。这项技术在加载来自多处的代码时很有用。例如 servlets 和 EJB 的 “热部署”。
我们可以编写自己的用于特殊目的的类加载器，这使得我们可以在向虚拟机传递字节码之前执行定制的检查。
如果要编写自己的类加载器，只需要继承 ClassLoader 类，然后覆盖下面这个方法
findClass(String className)
ClassLoader 超类的 loadClass 方法用于将类的加载操作委托给其父类加载器去进行，只有当该类尚未加载并且父类加载器也无法加载该类时，才调用 findClass 方法。
如果要实现该方法，必须做到以下几点：
1) 为来自本地文件系统或者其他来源的类加载其字节码
2) 调用 ClassLoader 超类的 defineClass 方法，向虚拟机提供字节码
