前言
在JVM中，类加载的过程分为加载、链接（验证、准备、解析）、初始化5个阶段。而加载阶段需要完成的重要事项之一，就是通过一个类的全限定名来获取定义此类的二进制字节码流（在HotSpot中，最常见的方法就是从class文件读取），并构造出类的定义。
HotSpot并没有在内部直接做这件事，而是在外部提供了类加载器ClassLoader，让应用程序自己来决定如何获取和加载需要的类，这就使得Java类加载拥有了很强的灵活性，成为动态代理、OSGi、热部署等技术的基础。
下面先来看ClassLoader类的部分源码，以了解它是如何加载一个类的。
ClassLoader类
java.lang.ClassLoader是一个抽象类，其JavaDoc的开头一段话如下。
/**
* A class loader is an object that is responsible for loading classes. The
* class <tt>ClassLoader</tt> is an abstract class. Given the <a
* href="#name">binary name</a> of a class, a class loader should attempt to
* locate or generate data that constitutes a definition for the class. A
* typical strategy is to transform the name into a file name and then read a
* "class file" of that name from a file system.
这段话所阐述的ClassLoader的作用与前言中给出的描述基本相同。然后我们来阅读其核心方法loadClass()的具体实现，该方法用于根据类的全限定名来加载类，并返回其对应的Class对象实例。
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;
}
}
loadClass()方法的详细执行流程如下。
- 调用getClassLoadingLock()方法获得类名对应的加载锁，并上锁，保证整个loadClass()方法执行的过程都是线程安全的。getClassLoadingLock()的源码如下所示，注意如果当前ClassLoader可以并行加载，就需要借助parallelLockMap（ConcurrentHashMap类型）来保存类名与锁的映射。
protected Object getClassLoadingLock(String className) {
Object lock = this;
if (parallelLockMap != null) {
Object newLock = new Object();
lock = parallelLockMap.putIfAbsent(className, newLock);
if (lock == null) {
lock = newLock;
}
}
return lock;
}
- 调用findLoadedClass()方法检查这个类是否已经加载过，若没有加载过，再继续往下执行。该方法最终调用的是native方法findLoadedClass0()，代码略。
- 如果存在父加载器，就调用父加载器的loadClass()方法试图加载该类，若加载不到就直接抛出ClassNotFoundException。反之，调用自身的findBootstrapClassOrNull()方法试图获取Bootstrap类加载器加载的该类。
- 如果通过前面的操作仍然无果，就调用自身的findClass()方法查找并获取该类。自定义ClassLoader都必须要覆写该方法，以规定获取类的逻辑（比如找到其对应的class文件并读取之）。其默认实现则是直接抛异常。
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}
- 最后，若resolve参数为true，就调用resolveClass()方法链接该类，最后返回对应的Class对象。注意，ClassLoader和Class对象都位于JVM堆中，而类及其字段、方法的相关信息（包含常量池）则位于方法区中。
类加载器层次
先来复习一下JVM加载一个类的时机：
- 使用new关键字创建类的实例，对应new指令；
- 访问或设置类的静态成员（final修饰的除外），对应getstatic/putstatic指令；
- 调用类的静态方法，对应invokestatic指令；
- 使用反射，即Class.forName("className")；
- JVM启动时会加载启动类，即包含有main()方法的那个类；
- 当子类被加载时，其父类也会同时被加载。
在上一节第3步，提到了Bootstrap类加载器。JVM的类加载器层次实际上由4层组成，如下图所示。
- Bootstrap（启动）类加载器：它负责加载最基础的$JAVA_HOME/jre/lib/rt.jar中的所有类，以及-Xbootclasspath参数中指定路径的类。它比较特殊，是由C++实现的，不是ClassLoader的子类，而是JVM自身的一部分。
- Extension（扩展）类加载器：它负责加载Java中的一些扩展功能，包括$JAVA_HOME/jre/lib/ext/*.jar中的所有类，以及-Djava.ext.dirs参数中指定路径的类。
- Application（应用）类加载器：它负责加载当前应用程序classpath中的类。
- Custom（自定义）类加载器：用户自己通过继承ClassLoader类并覆写findClass()方法来加载用户指定的类。
我们可以通过ClassLoader.getSystemClassLoader()与getParent()方法获取当前系统的类加载器及其父加载器。
ClassLoader cl = ClassLoader.getSystemClassLoader();
System.out.println(cl);
System.out.println(cl.getParent());
System.out.println(cl.getParent().getParent());
上述代码的输出如下。
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@5caf905d
null
可见，应用类加载器的实现是sun.misc.Launcher$AppClassLoader类，扩展类加载器是实现是sun.misc.Launcher$ExtClassLoader类。启动类加载器是native的，因此在HotSpot中返回null。
双亲委派模型
所谓双亲委派模型（Parents Delegation Model/PDM），就是上一节图中的类加载器层次关系与ClassLoader.loadClass()方法思想的具体体现。也就是说：如果一个类加载器要加载一个类，它首先不会自己尝试加载这个类，而是把加载的请求委托给父加载器完成，所有的类加载请求最终都应该传递给最顶层的启动类加载器。只有当父加载器无法加载到这个类时，子加载器才会尝试自己加载。
双亲委派模型的好处就是随着类加载器的层次关系保证了被加载类的层次关系，保证了Java运行环境的安全性。例如，在classpath中有一个用户自定义的类java.lang.Object，其中包含了恶意代码。如果没有双亲委派模型，系统中就出现了两个Object类，一旦使用包含恶意代码的那个Object类，系统就会处于危险之中。而在双亲委派模型下，可以保证Object类肯定是rt.jar中的那一个，恶意代码永远不会被执行。
由于双亲委派模型是靠loadClass()方法实现的，因此为了不破坏它，自定义类加载器必须覆写findClass()方法，而不能覆写loadClass()方法。在特殊的情况下，基础类必须回调用户代码（如JDBC、Tomcat），就必须破坏双亲委派模型，JDK提供了线程上下文类加载器（Thread Context ClassLoader）来实现这种需求，本文不细讲。
实现自定义ClassLoader
最后我们来自己实现一个最简单的ClassLoader。
public class CustomClassLoaderExample {
public static void main(String[] args) throws Exception {
ClassLoader myClassLoader = new ClassLoader() {
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream inputStream = getClass().getResourceAsStream(fileName);
if (inputStream == null) {
return super.findClass(name);
}
byte[] bytes = new byte[inputStream.available()];
inputStream.read(bytes);
return defineClass(name, bytes, 0, bytes.length);
} catch (IOException ex) {
throw new ClassNotFoundException(name, ex);
}
}
};
Object cl = myClassLoader.loadClass("me.lmagics.cl.CustomClassLoaderExample");
System.out.println(cl instanceof CustomClassLoaderExample);
}
}
顺便，程序最后的输出是false。这是因为在JVM中，不同类加载器加载的类会位于不同的命名空间。只有类加载器和类的全限定名都相同时，才真正算是同一个类。
