关于类加载器

写在前面

每个java开发人员对java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生，这背后就涉及到了java技术体系中的类加载。Java的类加载机制是java技术体系中比较核心的部分，虽然平时没又怎么接触，虽然和大部分开发人员直接打交道不多，但是对其背后的机理有一定理解有助于排查程序中出现的类加载失败等技术问题，对理解java虚拟机的连接模型和java语言的动态性都有很大帮助。

类加载器作用

Java虚拟机类加载器结构

1. Bootstrap ClassLoader/启动类加载器
   主要负责jdk_home/lib目录下的核心 api 或 -Xbootclasspath 选项指定的jar包装入工作。
2. Extension ClassLoader/扩展类加载器
   主要负责jdk_home/lib/ext目录下的jar包或 -Djava.ext.dirs 指定目录下的jar包装入工作。
3. System ClassLoader/系统类加载器
   主要负责java -classpath/-Djava.class.path所指的目录下的类与jar包装入工作。
4. User Custom ClassLoader/用户自定义类加载器(java.lang.ClassLoader的子类)
   在程序运行期间, 通过java.lang.ClassLoader的子类动态加载class文件, 体现java动态实时类装入特性。

类加载器的特性

1. 每个ClassLoader都维护了一份自己的名称空间， 同一个名称空间里不能出现两个同名的类。
2. 为了实现java安全沙箱模型顶层的类加载器安全机制, java默认采用了 " 双亲委派的加载链 " 结构。

• 关于类加载双亲委派机制

  如果一个类加载器收到了一个类加载请求，它首先不会自己去加载这个类，而是把这个请求委托给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成加载请求(它管理的范围之中没有这个类)时，子加载器才会尝试着自己去加载。

• 双亲委派机制的好处

1. 避免重复加载，当父亲已经加载了该类的时候，就没有必要子ClassLoader再加载一次。
2. Java类随着它的类加载器一起具备了一种带有优先级的层次关系，例如java.lang.Object存放在rt.jar之中，无论那个类加载器要加载这个类，最终都是委托给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类，相反，如果没有双亲委托模型，由各个类加载器去完成的话，如果用户自己写一个名为java.lang.Object的类，并放在classpath中，应用程序中可能会出现多个不同的Object类，java类型体系中最基本安全行为也就无法保证。

• 类加载器的几个重要方法

  类加载器均是继承自java.lang.ClassLoader抽象类。我们下面我们就看简要介绍一下java.lang.ClassLoader中几个最重要的方法:

  loadClass：此方法负责加载指定名字的类，首先会从已加载的类中去寻找，如果没有找到；从parent ClassLoader[ExtClassLoader]中加载；如果没有加载到，则从Bootstrap ClassLoader中尝试加载(findBootstrapClassOrNull方法), 如果还是加载失败，则抛出异常ClassNotFoundException, 在调用自己的findClass方法进行加载。如果要改变类的加载顺序可以覆盖此方法；如果加载顺序相同，则可以通过覆盖findClass方法来做特殊处理，例如：解密，固定路径寻找等。当通过整个寻找类的过程仍然未获取Class对象，则抛出ClassNotFoundException异常。

  如果类需要resolve，在调用resolveClass进行链接。

  protected synchronized Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) {  try {  if (parent != null) {   c = parent.loadClass(name, false);  } else {   c = findBootstrapClassOrNull(name);  }  } catch (ClassNotFoundException e) {    // ClassNotFoundException thrown if class not found    // from the non-null parent class loader   }   if (c == null) {   // If still not found, then invoke findClass in order   // to find the class.   c = findClass(name);  } } if (resolve) {  resolveClass(c); } return c; } 

  findLoadedClass：此方法负责从当前ClassLoader实例对象的缓存中寻找已加载的类，调用的为native方法。

  protected final Class<?> findLoadedClass(String name) { if (!checkName(name))     return null; return findLoadedClass0(name); }  private native final Class findLoadedClass0(String name);

  findClass：此方法直接抛出ClassNotFoundException异常，因此要通过覆盖loadClass或此方法来以自定义的方式加载相应的类。

      protected Class<?> findClass(String name) throws ClassNotFoundException {  throw new ClassNotFoundException(name);     }

  findSystemClass：此方法是从sun.misc.Launcher$AppClassLoader中寻找类，如果未找到，则继续从BootstrapClassLoader中寻找，如果仍然未找到，返回null

  protected final Class<?> findSystemClass(String name)throws ClassNotFoundException  {  ClassLoader system = getSystemClassLoader();  if (system == null) {   if (!checkName(name))   throw new ClassNotFoundException(name);    Class cls = findBootstrapClass(name);    if (cls == null) {     throw new ClassNotFoundException(name);    }    return cls;  }  return system.loadClass(name); } 

  defineClass：此方法负责将二进制字节流转换为Class对象，这个方法对于自定义类加载器而言非常重要。如果二进制的字节码的格式不符合jvm class文件格式规范，则抛出ClassFormatError异常；如果生成的类名和二进制字节码不同，则抛出NoClassDefFoundError；如果加载的class是受保护的、采用不同签名的，或者类名是以java.开头的，则抛出SecurityException异常。

  ```

  protected final Class<?> defineClass(String name, byte[] b, int off, int len,ProtectionDomain protectionDomain)throws ClassFormatError

  {

  return defineClassCond(name, b, off, len, protectionDomain, true);

  }

Class c = null;  String source = defineClassSourceLocation(protectionDomain); try {  c = defineClass1(name, b, off, len, protectionDomain, source,verify); } catch (ClassFormatError cfe) {  c = defineTransformedClass(name, b, off, len, protectionDomain, cfe,source, verify); } postDefineClass(c, protectionDomain); return c; 

}

**resolveClass：** 此方法负责完成Class对象的链接，如果链接过，则直接返回。  ###线程上下文加载器 Java 提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的 SPI 有 JDBC、JCE、JNDI、JAXP 和 JBI 等。这些 SPI 的接口由 Java 核心库来提供，如 JAXP 的 SPI 接口定义包含在 javax.xml.parsers包中。这些 SPI 的实现代码很可能是作为 Java 应用所依赖的 jar 包被包含进来，可以通过类路径（CLASSPATH）来找到，如实现了 JAXP SPI 的 Apache Xerces所包含的 jar 包。SPI 接口中的代码经常需要加载具体的实现类。如 JAXP 中的 javax.xml.parsers.DocumentBuilderFactory类中的 newInstance()方法用来生成一个新的 DocumentBuilderFactory的实例。这里的实例的真正的类是继承自 javax.xml.parsers.DocumentBuilderFactory，由 SPI 的实现所提供的。如在 Apache Xerces 中，实现的类是 org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI 的接口是 Java 核心库的一部分，是由引导类加载器来加载的；SPI 实现的 Java 类一般是由系统类加载器来加载的。引导类加载器是无法找到 SPI 的实现类的，因为它只加载 Java 的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。 线程上下文类加载器正好解决了这个问题。如果不做任何的设置，Java 应用的线程的上下文类加载器默认就是系统上下文类加载器。在 SPI 接口的代码中使用线程上下文类加载器，就可以成功的加载到 SPI 实现的类。线程上下文类加载器在很多 SPI 的实现中都会用到。 java默认的线程上下文类加载器是 系统类加载器(AppClassLoader)。

// Also set the context class loader for the primordial thread.Thread.currentThread().setContextClassLoader(loader);

以上代码摘自sun.misc.Launch的无参构造函数Launch()。 使用线程上下文类加载器, 可以在执行线程中, 抛弃双亲委派加载链模式, 使用线程上下文里的类加载器加载类. 典型的例子有, 通过线程上下文来加载第三方库jndi实现, 而不依赖于双亲委派. 大部分java app服务器(jboss, tomcat..)也是采用contextClassLoader来处理web服务。 还有一些采用 hotswap 特性的框架, 也使用了线程上下文类加载器, 比如 seasar (full stack framework in japenese). 线程上下文从根本解决了一般应用不能违背双亲委派模式的问题. 使java类加载体系显得更灵活. 随着多核时代的来临, 相信多线程开发将会越来越多地进入程序员的实际编码过程中. 因此, 在编写基础设施时， 通过使用线程上下文来加载类, 应该是一个很好的选择。 当然, 好东西都有利弊. 使用线程上下文加载类, 也要注意, 保证多根需要通信的线程间的类加载器应该是同一个, 防止因为不同的类加载器, 导致类型转换异常(ClassCastException)。 在黄勇的《架构探险》一书中开发类加载器的时候采用的也是线程上下文加载器。  ###java动态载入class的两种方式 1. implicit隐式,即利用实例化才载入的特性来动态载入class 2. explicit显式方式,又分两种方式:  * java.lang.Class的forName()方法  * java.lang.ClassLoader的loadClass()方法  * **用Class.forName加载类** Class.forName使用的是被调用者的类加载器来加载类的。 这种特性, 证明了java类加载器中的名称空间是唯一的, 不会相互干扰。 即在一般情况下, 保证同一个类中所关联的其他类都是由当前类的类加载器所加载的。

常见异常

• ClassNotFoundException 这是最常见的异常，产生这个异常的原因为在当前的ClassLoader 中加载类时，未找到类文件，
• NoClassDefFoundError 这个异常是因为 加载到的类中引用到的另外类不存在，例如要加载A，而A中盗用了B，B不存在或当前的ClassLoader无法加载B，就会抛出这个异常。
• LinkageError 该异常在自定义ClassLoader的情况下更容易出现，主要原因是此类已经在ClassLoader加载过了，重复的加载会造成该异常。