JVM学习笔记(八)类加载机制－类加载器

前言

  类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。两个类被同一虚拟机加载，即时这两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不想等。

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

注：isAssignableFrom 是用来判断一个类Class1和另一个类Class2是否相同或是另一个类的超类或接口。
例子：Class1.isAssignableFrom(Class2)

---

1、类加载器体系结构

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

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

  从java开发人员的角度来看，类加载器还可以划分得更细致一些，绝大部分java程序都会使用到以下3种系统的提供的类加载器，Java中的类加载器体系结构如下：

1）BootStrap ClassLoader：启动类加载器，负责加载存放在%JAVA_HOME%\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且被java虚拟机识别的(仅按照文件名识别，如rt.jar，名字不符合的类库，即使放在指定路径中也不会被加载)类库加载到虚拟机的内存中，启动类加载器无法被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）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

---

2、双亲委派模型

注意：上述三个JDK提供的类加载器虽然是父子类加载器关系，但是没有使用继承，而是使用了组合关系。

从JDK1.2开始，java虚拟机规范推荐开发者使用双亲委派模式(ParentsDelegation Model)进行类加载，其加载过程如下：

(1).如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器去完成。

(2).每一层的类加载器都把类加载请求委派给父类加载器，直到所有的类加载请求都应该传递给顶层的启动类加载器。

(3).如果顶层的启动类加载器无法完成加载请求，子类加载器尝试去加载，如果连最初发起类加载请求的类加载器也无法完成加载请求时，将会抛出ClassNotFoundException，而不再调用其子类加载器去进行类加载。
双亲委派 模式的类加载机制的优点是java类它的类加载器一起具备了一种带优先级的层次关系，越是基础的类，越是被上层的类加载器进行加载，保证了java程序的稳定运行。

双亲委派模式的实现：

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){      //父类加载器无法完成类加载请求  }  if(c == null){//本身类加载器进行类加载      c = findClass(name);  }  }  if(resolve){      resolveClass(c);  }  return c;  }  

  若要实现自定义类加载器，只需要继承java.lang.ClassLoader 类，并且重写其findClass()方法即可。java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即 java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等，ClassLoader 中与加载类相关的方法如下：

方法 说明 getParent() 返回该类加载器的父类加载器。 loadClass(String name) 加载名称为 二进制名称为name 的类，返回的结果是 java.lang.Class 类的实例。 findClass(String name) 查找名称为 name 的类，返回的结果是 java.lang.Class 类的实例。 findLoadedClass(String name) 查找名称为 name 的已经被加载过的类，返回的结果是 java.lang.Class 类的实例。 resolveClass(Class c) 链接指定的 Java 类。

---

注意：在JDK1.2之前，类加载尚未引入双亲委派模式，因此实现自定义类加载器时常常重写loadClass方法，提供双亲委派逻辑，从JDK1.2之后，双亲委派模式已经被引入到类加载体系中，自定义类加载器时不需要在自己写双亲委派的逻辑，因此不鼓励重写loadClass方法，而推荐重写findClass方法。

  在Java中，任意一个类都需要由加载它的类加载器和这个类本身一同确定其在java虚拟机中的唯一性，即比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提之下才有意义，否则，即使这两个类来源于同一个Class类文件，只要加载它的类加载器不相同，那么这两个类必定不相等(这里的相等包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法和instanceof关键字的结果)。

例子代码如下：

public class ClassLoaderTest {      public static void main(String[] args)throws Exception{          //匿名内部类实现自定义类加载器      ClassLoader myClassLoader = new ClassLoader(){      protected Class<?> findClass(String name)throws ClassNotFoundException{          //获取类文件名      String filename = name.substring(name.lastIndexOf(“.”) + 1) + “.class”;      InputStream in = getClass().getResourceAsStream(filename);      if(in == null){      throw RuntimeException(“Could not found class file:” + filename);  }  byte[] b = new byte[in.available()];  return defineClass(name, b, 0, b.length);  }catch(IOException e){      throw new ClassNotFoundException(name);  }  };  Object obj = myClassLoader.loadClass(“com.test.ClassLoaderTest”).newInstance();  System.out.println(obj.getClass());  System.out.println(obj instanceof com.test. ClassLoaderTest);  }  }  

输出结果如下：

com.test.ClassLoaderTestfalse

  之所以instanceof会返回false，是因为com.test.ClassLoaderTest类默认使用Application ClassLoader加载，而obj是通过自定义类加载器加载的，类加载不相同，因此不相等。
  类加载器双亲委派模型是从JDK1.2以后引入的，并且只是一种推荐的模型，不是强制要求的，因此有一些没有遵循双亲委派模型的特例：

(1).在JDK1.2之前，自定义类加载器都要覆盖loadClass方法去实现加载类的功能，JDK1.2引入双亲委派模型之后，loadClass方法用于委派父类加载器进行类加载，只有父类加载器无法完成类加载请求时才调用自己的findClass方法进行类加载，因此在JDK1.2之前的类加载的loadClass方法没有遵循双亲委派模型，因此在JDK1.2之后，自定义类加载器不推荐覆盖loadClass方法，而只需要覆盖findClass方法即可。

(2).双亲委派模式很好地解决了各个类加载器的基础类统一问题，越基础的类由越上层的类加载器进行加载，但是这个基础类统一有一个不足，当基础类想要调用回下层的用户代码时无法委派子类加载器进行类加载。为了解决这个问题JDK引入了ThreadContext线程上下文，通过线程上下文的setContextClassLoader方法可以设置线程上下文类加载器。
JavaEE只是一个规范，sun公司只给出了接口规范，具体的实现由各个厂商进行实现，因此JNDI，JDBC,JAXB等这些第三方的实现库就可以被JDK的类库所调用。线程上下文类加载器也没有遵循双亲委派模型。

(3).近年来的热码替换，模块热部署等应用要求不用重启java虚拟机就可以实现代码模块的即插即用，催生了OSGi技术，在OSGi中类加载器体系被发展为网状结构。OSGi也没有完全遵循双亲委派模型。

注：OSGI实现模块化热部署的关键则是它自定义的类加载器机制的实现。每一个程序模块（OSGI中称为Bundle）都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGI环境下，类加载器不再是双亲委派模型中的树状结构。OSGI中对类加载器的使用是很值得学习的，弄懂了OSGI的实现，就可以算是掌握了类加载器的精髓。

推荐书籍：《深入理解OSGI：Equinox原理、应用与最佳实践》