《深入理解Java虚拟机》笔记07之类加载器

7.4 类加载器

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

7.4.1 类与类加载器

对于任何一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。

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

package org.fenixsoft.classloading;

import java.io.IOException;
import java.io.InputStream;

public class ClassLoaderTest {

    public static void main(String[] args) throws Exception{

        ClassLoader myLoader = new ClassLoader() {
            @Override
            public Class<?> loadClass(String name) throws ClassNotFoundException {
                try{
                    String fileName = name.substring(name.lastIndexOf(".")+1)+".class";

                    InputStream is = getClass().getResourceAsStream(fileName);
                    if(is == null){
                        return super.loadClass(name);
                    }
                    byte[] b = new byte[is.available()];
                    is.read(b);
                    return defineClass(name,b,0,b.length);
                }catch (IOException e){
                    throw new ClassNotFoundException(name);
                }
            }
        };

        Object obj = myLoader.loadClass("org.fenixsoft.classloading.ClassLoaderTest").newInstance();

        System.out.println(obj.getClass());
        System.out.println(obj instanceof org.fenixsoft.classloading.ClassLoaderTest);

    }

}

运行结果：

class org.fenixsoft.classloading.ClassLoaderTest
false

程序中构造了一个简单的类加载器。可以看到类型检查的时候返回了false,这是因为虚拟机中存在了**两个ClassLoaderTest类**，一个是由系统应用程序类加载器加载的，另外一个是由我们自定义的类加载器加载的，虽然都是来自同一个Class文件，但依然是两个独立的类，做对象所需类型检查时结果自然为false。

7.4.2 双亲委派模型

**从Java虚拟机的角度来讲，**只存在两种不同的类加载器：

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

从Java开发人员的角度来看，绝大部分Java程序都会使用到以下3种系统提供的类加载器。

1.启动类加载器：

启动类加载器（Bootstrap ClassLoader）:这个类加载器负责将存放在<JAVA_HOME>\lib目录中的，

或者被-Xbootclasspath参数所指定的路径中的，

并且是虚拟机识别的（仅按照文件名识别，如rt.jar,名字不符合的类库即使放在lib目录也不会被加载）类库

加载到虚拟机内存中。

启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

2.扩展类加载器：

扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher&ExtClassLoader实现，

它负责加载<JAVA_HOME>\lib\ext目录中的

或者被java.ext.dirs系统变量所指定的路径中的所有类库

开发者可以直接使用扩展类加载器。

3.应用程序类加载器：

应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc.Launcher&App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称为**系统类加载器。**

它负责加载用户类路径（ClassPath）上所指定的类库

开发者可以直接使用这个类加载

如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

我们的应用程序都是由这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。

这些类加载器之间的关系一般如图7-2所示：

**如上图所示的类加载之间的这种层次关系，称为类加载器的双亲委派模型（Parents Delegation Model）。**JDK1.2期间被引入。

双清委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。

这里类加载之间的父子关系一般都不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

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

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

例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载环境中都是同一个类。

否则，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

双亲委派模型对于保证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{
				//如果没有加载父类的loadClass，，默认使用启动类加载器作为父加载器
				c = findBootstrapClassOrNull(name);
			}
		}catch(ClassNotFoundException e){
			//如果父类加载器抛出ClassNotFoundException
			//说明父类加载器无法完成加载请求
		}
		if(resolve){
			resolveClass(c);
		}
		return c;
	}
}

如上代码，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。

7.4.3 破坏双亲委派模型

上文提到过双清委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。

目前为止，双亲委派模型主要出现过3次较大规模的“被破坏”情况。

1.双亲委派模型的第一次“被破坏”：

发生在双亲委派模型出现之前-即JDK1.2发布之前。为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的protected方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的就是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个跟方法的唯一逻辑就是去调用自己的loadClass()。

上一节我们已经看过loadClass()方法的代码，双亲委派的具体逻辑就实现在这个方法之中，JDK1.2之后已不提倡用户再去覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派规则的。

2.双亲委派模型的第二次“被破坏”：

由这个模型自身的缺陷所导致的，双亲模型很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载）。

基础类之所以成为“基础”，是因为它们总是作为被用户代码调用的API，但世事往往没有绝对的完美，如果基础类又要调用回用户的代码，那该怎么办？

一个典型的例子便是JNDI服务。它的代码由启动类加载器去加载，但JNDI的目的就是对资源进行集中管理和查找，它需要由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI,Service Provider Interface）的代码，但启动类加载器不可能“认识”这些代码啊！那该怎么办？

**使用线程上下文类加载器（Thread Context ClassLoader）:**这个类加载器可以通过java.lang.Thread类的setContextClassLoaser()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上也就违背了双亲委派模型的一般性原则。

Java中所有涉及SPI的加载动作基本上都采用这种方式：JNDI、JDBC、JCE、JAXB、JBI等。

**3.双亲委派模型的第三次“被破坏”：**模块热部署

OSGi（JSR-291）去实现模块化热部署的关键则是它自定义的类加载器机制的实现。

每一个程序模块（OSGi中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连通类加载器一起换掉以实现代码的热替换。

在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构。