类加载器最初是为了Java Applet的需求而开发,虽然目前applet基本没人用了,但是类加载器却在类层次划分、OSGi、热部署、代码加密等领域大放异彩,成为java领域中一块重要的基石。
每个java程序都至少拥有三个类加载器:
- 引导类加载器(Bootstrap Classloader)
- 扩展类加载器(Extension Classloader)
- 应用程序类加载器(Application ClassLoader)
引导类加载器负责加载系统类,通常从rt.jar中进行加载,它是虚拟机中不可分割的一部分,而且一般都是用C语言来实现的。
扩展类加载器用于从jre/lib/ext目录加载“标准的扩展”。可以将jar文件放到该目录,这样即使没有任何类路径,扩展类加载器也可以找到其中的各个类。
应用程序类加载器用于加载应用类,它在用CLASSPATH环境变量或者-classpath命令行选项设置类路径中的目录或者是jar文件里找到这些类。
双亲委派模型示意图
上图的类加载器之间的层次关系,称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器外,其余的类加载器都应当有自己的父类加载器。这里的类加载器之间的父子关系一般不会以继承的关系来实现,而是都使用组合关系来复用父类加载器的代码。
双亲委派模型的工作过程是:如果一个类加载器收到类加载的请求,它首先不会自己去尝试加载这个类,而是把这个请求委派给父类加载器去完成,每一个层次的类加载器都是如此,因此所有的加载请求最终都应该传送到顶层的启动类加载器中,只有当父类加载器反馈自己无法完成这个加载请求时,子加载器才会尝试自己去加载。
双亲委派模型实现
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
//首先,检查请求的类是否已经被加载过了
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
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载的时候
// 再调用本身的findclass方法进行类加载
long t1 = System.nanoTime();
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
使用双亲委派模型来组织类加载器之间的关系,有一个显而易见的好处就是java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如java.lang.Object,它存放在rt.jar中,无论哪一个类加载器要加载这个类,最终都会委派给处于模型最顶端的启动类加载器进行加载,因此Object类在程序的各种类加载器环境中都是同一个类。假如没有使用双亲委派模型的话,由各个类加载器自行去加载的话,如果用户自己编写一个java.lang.Object的类,并放在程序的classpath中的话,系统中就会出现不同的Object类,java类型体系中的最基础的行为也就无法保证,应用程序也将变得一片混乱。