JVM系列——详细说明类加载器与双亲委派机制

Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（Class Loader）。

类加载 器最初是为了满足Java Applet的需求而设计出来的，在今天用在浏览器上的Java Applet技术基本上已经被淘汰。
目前类加载器在类层次划分、OSGi、程序热部署、代码加密等领域大放异彩，成为Java 技术体系中一块重要的基石。

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远超类加载阶段

类的唯一性判断：
对于任意一个类，都必须由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

比较两个类是否“相 等”，只有在这两个类是由同一个类加载器加载的前提下才有意义。
否则，即使这两个类来源于同一个 Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

如何定义相等：
这里所指的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance() 方法的返回结果，也包括了使用instanceof关键字做对象所属关系判定等各种情况。

类加载器

站在Java虚拟机的角度来看，只存在两种不同的类加载器：启动类加载器（Bootstrap ClassLoader）和 其他所有的类加载器。

• 启动类加载器（Bootstrap ClassLoader），这个类加载器（HotSpot是）使用C++语言实现，是虚拟机的一部分
• 其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader.

本节内容将针对JDK 8及之前版本的Java。
下面介绍三个系统提供的类加载器：

启动类加载器（Bootstrap Class Loader）

这个类加载器负责加载存放在 \lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的类库加载到虚拟机的内存中。

其中，虚拟机能够识别的是指：按照文件名识别，如rt.jar、tools.jar，如果名字不符合的类库即使放在lib目录中也不会被加载。

启动类加载器无法被Java程序直接引用
用户在编写自定义类加载器时， 如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可。
下面的代码展示的就是 java.lang.ClassLoader.getClassLoader()方法的代码片段，其中的注释和代码实现都明确地说明了以null值 来代表引导类加载器的约定规则。

/** 
返回类的类加载器. 
一些实现会使用null代表启动类加载器. 
This method will return null in such implementations if this class was loaded by the bootstrap class loader. 
*/
public ClassLoader getClassLoader() { 
	ClassLoader cl = getClassLoader0(); 
	if (cl == null) 
		return null; 
	SecurityManager sm = System.getSecurityManager(); 
    if (sm != null) { 
    	ClassLoader ccl = ClassLoader.getCallerClassLoader(); 
        if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) { 
            sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION); 
        } 
    }
    return cl; 
}

扩展类加载器（Extension Class Loader）

这个类加载器是在类sun.misc.Launcher$ExtClassLoader 中以Java代码的形式实现的。它负责加载\lib\ext目录中，或者被java.ext.dirs系统变量所 指定的路径中所有的类库。

根据“扩展类加载器”这个名称，就可以推断出这是一种Java系统类库的扩展机制。
允许用户将具有通用性的类库放置在ext目录里以扩展Java SE的功能
在JDK 9之后，这种扩展机制被模块化带来的天然的扩展能力所取代。
由于扩展类加载器是由Java代码实现的，开发者可以直接在程序中使用扩展类加载器来加载Class文件。

应用程序类加载器（Application Class Loader）

这个类加载器由 sun.misc.Launcher$AppClassLoader来实现

由于应用程序类加载器是ClassLoader类中的****stemClassLoader()**方法的返回值，所以有些场合中也称它为“系统类加载器”。

它负责加载用户类路径 （ClassPath）上所有的类库
开发者同样可以直接在代码中使用这个类加载器。
如果应用程序中没有 自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

JDK 9之前的Java应用都是由这三种类加载器互相配合来完成加载的。
如果有必要，用户还可以加入自定义的类加载器来进行拓展，典型的如增加除了磁盘位置之外的Class文件来源，或者通过类加载器实现类的隔离、重载等功能。

双亲委派模型

各种类加载器之间的层次关系被称为类加载器的“双亲委派模型（Parents Delegation Model）”

如下图所示：

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。
不过这里类加载器之间的父子关系一般**不是以继承（Inheritance）**的关系来实现的，而是通常使用 组合（Composition）关系来复用父加载器的代码。

工作过程

双亲委派模型的工作过程如下：

1. 如果一个类加载器收到了类加载的请求，它不会先自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。（因此所有的 加载请求最终都应该传送到最顶层的启动类加载器中）
2. 当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去完成加载。

举个例子：
假设我们有一个类 Demo.class。需要请求将此类文件加载到 Application ClassLoader。

1. 它委托给它的父扩展类加载器。此外，它委托给 Bootstrap ClassLoader。
2. Bootstrap 在 rt.jar 中搜索该类。
3. 由于该类不存在，现在请求由 Extension ClassLoader处理，它搜索目录 jre/lib/ext 并尝试在其中找到此类。
4. 如果在此处找到该类，Extension ClassLoader 将加载该类。 Application ClassLoader 则不加载该类。
5. 若Extension ClassLoader 找不到该类，则Application ClaasLoader 从 Java 中的 CLASSPATH 加载它。

好处：
使用双亲委派模型来组织类加载器之间的关系，明显的好处是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

例如类java.lang.Object，它存放在rt.jar之中，无论哪个类加载器要加载它，最终都是委派给最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。
反之，如果没有使用双亲委派模型，都由各个类加载器自行去加载的话，如果用户自己也编写了一个名为java.lang.Object的类，并放在程序的 ClassPath中，那系统中就会出现多个不同的Object类，Java类型体系中最基础的行为也就无从保证，应用程序将会变得一片混乱。

可见性原则

可见性原则是说子ClassLoader可以看到父ClassLoader加载的类，反之则不然。
这意味着如果 Application ClassLoader 加载了 Demo.class，在这种情况下，尝试使用 Extension ClassLoader 显式加载 Demo.class 会抛出 java.lang.ClassNotFoundException（因为父加载器看不到子加载器加载的类）。

唯一性原则

根据唯一性原则，一个被父类加载的类不应该被子类加载器再次加载。
因此，可以编写违反双亲委派机制和唯一性原则的类加载器，自己加载类。

实现

双亲委派模型对于保证Java程序的稳定运作极为重要，但它的实现却异常简单。
用以实现双亲委 派的代码只有短短十余行，全部集中在java.lang.ClassLoader的loadClass()方法之中。
如下所示：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { 
    // 首先，检查请求的类是否已经被加载过了 
    Class c = findLoadedClass(name); 
    if (c == null) { 
        try { 
            if (parent != null) { 
            	c = parent.loadClass(name, false); 
            } else { 
            	c = findBootstrapClassOrNull(name); 
            }
        } catch (ClassNotFoundException e) { 
            // 如果父类加载器抛出ClassNotFoundException 
            // 说明父类加载器无法完成加载请求 
        }
        if (c == null) { 
            // 在父类加载器无法加载时 
            // 再调用本身的findClass方法来进行类加载 
            c = findClass(name); 
        } 
    }
    if (resolve) { 
    	resolveClass(c); 
    }
    return c; 
} 

该段代码比较简单明了：

1. 先检查请求加载的类型是否已经被加载过，若没有则调用父加载器的 loadClass()方法，
2. 若父加载器为空则默认使用启动类加载器作为父加载器。
3. 假如父类加载器加载失败， 或抛出ClassNotFoundException异常的话，才调用自己的findClass()方法尝试进行加载。

破坏双亲委派模型

破坏双亲委派

参考