《深入理解Java虚拟机》一书中将类的加载过程放到了类加载器前面一节，但在这里我想先讲“类加载器”。在上一篇类加载时机中我们用大量篇幅来讲解了类加载过程中的5个步骤的最后一步——初始化。在这一节中，我们实际是在讲解类加载过程5个步骤的第一步——加载。
我们再次回顾类加载过程的5个步骤：
类加载过程的“加载”步骤是通过类加载器（ClassLoader）来实现的。那么加载阶段做什么工作呢？“通过一个类的全限定名来获取描述此类的二进制字节流。”首先我们需要了解来自同一个Class文件的两个类是否一定是“相等”的，这个相等几乎涵盖能代表“相等”的方法，equals()、isAssignableFrom()、isInstance()，也包括instanceof关键字判断对象所属关系。这是因为，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立在Java虚拟机的唯一性，每一个类加载器，都拥有一个独的类名称空间。这句话意思就是说，比较两个类是否相等不能光看他们本身来自同一个类，同时也要看加载它们的类加载器是否相同。
1 package day_14_classloader; 2 3 import java.io.IOException; 4 import java.io.InputStream; 5 6 /** 7 * @author turbo 8 * 9 * 2016年9月19日 10 */ 11 public class ClassLoaderTest { 12 13 /** 14 * @param args 15 */ 16 public static void main(String[] args) throws Exception{ 17 ClassLoader myLoader = new ClassLoader() { 18 19 @Override 20 public Class<?> loadClass(String name) 21 throws ClassNotFoundException { 22 try { 23 String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class"; 24 InputStream is = getClass().getResourceAsStream(fileName); 25 if (is == null){ 26 return super.loadClass(name); 27 } 28 byte[] b = new byte[is.available()]; 29 is.read(b); 30 return defineClass(name, b, 0, b.length); 31 } catch (IOException e) { 32 throw new ClassNotFoundException(); 33 } 34 } 35 }; 36 37 Object obj = myLoader.loadClass("day_14_classloader.ClassLoaderTest").newInstance(); 38 System.out.println(obj.getClass()); 39 System.out.println(obj instanceof day_14_classloader.ClassLoaderTest); 40 } 41 42 }
上面我们了一个类加载器直接重写了loadClass方法，其实如果真要自定义一个类加载器，Java是不提倡程序员直接覆盖loadClass方法的，这会牵扯出一个破坏“双亲委派模型”的问题（除非你就是打算破坏这个模型，比如上例），而是建议程序员重写findClass方法来实现自定义类加载逻辑。下面我们先介绍类加载器的种类，接着引出类加载器的一个重要概念“双亲委派模型”。
从程序员角度来看，绝大部分Java程序会使用到以下3种系统提供的类加载器。
- 启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++实现，是虚拟机自身的一部分。负责加载<JAVA_HOME>lib中（或者-Xbootclasspath参数所指定路径），且是虚拟机识别的类库加载到虚拟机内存中。不可直接被Java程序引用。
- 扩展类加载器（Extension ClassLoader），这个类加载器由Java实现，独立于虚拟机外部，继承至java.lang.ClassLoader抽象类。负责加载<JAVA_HOME>libext中（或者被java.ext.dirs系统变量所指定）的所有类库。开发者可直接使用扩展类加载器。
- 应用程序加载类（Application ClassLoader），也称之为系统类加载器，同样也由Java实现，独立于虚拟机外部，继承至java.lang.ClassLoader抽象类。负责加载用户类路径（ClassPath）上所指定的类库。开发者可直接使用这个类加载器。
以上3种类加载器（当然也可以自定义类加载器）它们是如何相互配合进行加载的呢？这就要回到我们要讲的“双亲委派模型”。
我们可以看到3种类加载器加上自定义类加载器属于一种层次关系。但这种层次父子关系，通常不会以继承来实现，而是使用组合关系来复用父加载器的代码。
那它们的工作过程是怎样的呢？从传统固定思维来看，应该是处在最低层的自定义类加载器进行加载，当发现不能加载时将请求传递加载传递给上一层类加载器——应用程序类加载器，以此类推，直到到达最顶层的启动类的类加载器。但事实恰好相反：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
这种模型有一个好处Java类随着它的加载器一起具备了一种带有优先级的层次关系。试想，如果不是双亲委托模型，如果不是从顶层启动类加载器开始加载，而是从自定义类加载器开始加载，那么我们在加载Object的时候，不同的类加载器就会出现不是同一个Object，Java类型体系中最基础的行为也就无法保证，这不符合我们的预期，这也正是我们在开头所提到的两个类是否相等需要由加载它的类加载器和这个类本身一同确立。
那么这个双亲委派模型是怎么实现的呢？我们来看看jdk1.7源码。
1 /** 2 * 3 * 此方法和书中的方法略有不同，书中方法为protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException 4 * 估计是版本的原因，未考证。 5 */ 6 protected Class<?> loadClass(String name, boolean resolve) 7 throws ClassNotFoundException 8 { 9 synchronized (getClassLoadingLock(name)) { 10 // 首先, 调用findLoadedClass方法检查请求的类是否已经被加载过了 11 Class c = findLoadedClass(name); 12 if (c == null) { 13 long t0 = System.nanoTime(); 14 try { 15 if (parent != null) { 16 c = parent.loadClass(name, false); //有父类加载器，则调用父类加载器 17 } else { 18 c = findBootstrapClassOrNull(name); //没有父类加载器，即调用启动类加载器 19 } 20 } catch (ClassNotFoundException e) { 21 //如果父类抛出ClassNotFoundException异常，说明父类加载器无法完成加载请求 22 } 23 24 if (c == null) { 25 //如果父类加载器无法加载器的时候调用本身的findClass方法来进行加载 26 long t1 = System.nanoTime(); 27 c = findClass(name); 28 29 // this is the defining class loader; record the stats 30 sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0); 31 sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); 32 sun.misc.PerfCounter.getFindClasses().increment(); 33 } 34 } 35 if (resolve) { 36 resolveClass(c); 37 } 38 return c; 39 } 40 }
我们可以看到其实双亲委托模式的实现方式非常简单。在本文开始举例instanceof，如果重写findClass方法，那么最后还是会由启动类加载器来加载。但我们直接重写了loadClass方法，所以我们破坏掉了双亲委托模式，也就出现了上述结果。
关于类加载器还有一个上下文加载器（Thread Context ClassLoader）值得探究。这个我们单独在下一篇文章中来讲。