Java 类加载器解析及常见类加载问题

每个类加载器本身也是个对象——一个继承 java.lang.ClassLoader 的实例。每个类被其中一个实例加载。我们下面来看看 java.lang.ClassLoader 中的 API, 不太相关的部分已忽略。

package java.lang;

public abstract class ClassLoader {

public Class loadClass(String name);
protected Class defineClass(byte[] b);

public URL getResource(String name);
public Enumeration getResources(String name);

public ClassLoader getParent()
}

loadClass: 目前 java.lang.ClassLoader 中最重要的方法是 loadClass 方法，它获取要加载的类的全限定名返回 Class 对象。

defineClass: defineClass 方法用于具体化 JVM 的类。byte 数组参数是加载自磁盘或其他位置的类字节码。

getResource 和 getResources: 返回资源路径。loadClass 大致相当于 defineClass(getResource(name).getBytes())。

getParent: 返回父加载器。

Java 的懒惰特性影响了类加载器的工作方式——所有事情都应该在最后一刻完成。类只有在以某种方式被引用时才会被加载-通过调用构造函数、静态方法或字段。看个例子：

类 A 实例化类 B:

public class A {
public void doSomething() {
B b = new B();
b.doSomethingElse();
}
}

语句 B b = new B() 在语义上等同于 B b = A.class. getClassLoader().loadClass(“B”).newInstance() 。如我们所见，Java 中的每个对象都与其类 (A.class) 相关联，并且每个类都与用于加载类的类加载器 (A.class.getClassLoader()) 相关联。

当我们实例化类加载器时，我们可以将父类加载器指定为构造函数参数。如果未显式指定父类加载器，则会将虚拟机的系统类加载器指定为默认父类。

类加载器层次结构

每当启动新的 JVM 时，引导类加载器(bootstrap classloader)负责首先将关键 Java 类（来自 Java.lang 包）和其他运行时类加载到内存中。引导类加载器是所有其他类加载器的父类。因此，它是唯一没有父类的。

接下来是扩展类加载器(extension classloader)。引导类加载器(bootstrap classloader)作为父类，负责从 java.ext.dirs 路径中保存的所有 .jar 文件加载类。

从开发人员的角度来看，第三个也是最重要的类加载器是系统类路径类加载器(system classpath classloader)，它是扩展类加载器(extension classloader)的直接子类。它从由 CLASSPATH 环境变量 java.class.pat h系统属性或 -classpath 命令行选项指定的目录和 jar 文件加载类。

请注意，类加载器层次结构不是继承层次结构，而是委托层次结构。大多数类加载器在搜索自己的类路径之前将查找类和资源委托给其父类。如果父类加载器找不到类或资源，则类加载器只能尝试在本地找到它们。实际上，类加载器只负责加载父级不可用的类；层次结构中较高的类加载器加载的类不能引用层次结构中较低的可用类。类加载器委托行为的动机是避免多次加载同一个类。

在 Java EE 中，查找的顺序通常是相反的：类加载器可能在转到父类之前尝试在本地查找类。

Java EE 委托模型

下面是应用程序容器的类加载器层次结构的典型视图：容器本身有一个类加载器，每个 EAR 模块都有自己的类加载器，每个 WAR 都有自己的类加载器。Java Servlet 规范建议 web 模块的类加载器在委托给其父类之前先在本地类加载器中查找——父类加载器只要求提供模块中找不到的资源和类。