深入理解Java类加载器：Java类加载原理解析

Posted 好好学习312

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深入理解Java类加载器：Java类加载原理解析相关的知识，希望对你有一定的参考价值。

1 基本信息


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


2 Java虚拟机类加载器结构简述


2.1 JVM三种预定义类型类加载器


　　我们首先看一下JVM预定义的三种类型类加载器，当一个 JVM启动的时候，Java缺省开始使用如下三种类型类装入器：

　　启动（Bootstrap）类加载器：引导类装入器是用本地代码实现的类装入器，它负责将 <Java_Runtime_Home>/lib下面的核心类库或-Xbootclasspath选项指定的jar包加载到内存中。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。

　　扩展（Extension）类加载器：扩展类加载器是由Sun的ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将< Java_Runtime_Home >/lib/ext或者由系统变量-Djava.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。

　　系统（System）类加载器：系统类加载器是由 Sun的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径java -classpath或-Djava.class.path变量所指的目录下的类库加载到内存中。开发者可以直接使用系统类加载器。

　　除了以上列举的三种类加载器，还有一种比较特殊的类型就是线程上下文类加载器，这个将在后面单独介绍。


2.2 类加载双亲委派机制介绍和分析


       在这里，需要着重说明的是，JVM在加载类时默认采用的是双亲委派机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。关于虚拟机默认的双亲委派机制，我们可以从系统类加载器和扩展类加载器为例作简单分析。

图一 标准扩展类加载器继承层次图

图二系统类加载器继承层次图

通过图一和图二我们可以看出，类加载器均是继承自java.lang.ClassLoader抽象类。我们下面我们就看简要介绍一下java.lang.ClassLoader中几个最重要的方法：

[java]  view plain  copy
  1. //加载指定名称（包括包名）的二进制类型，供用户调用的接口  
  2. public Class<?> loadClass(String name) throws ClassNotFoundException …   
  3.   
  4. //加载指定名称（包括包名）的二进制类型，同时指定是否解析（但是这里的resolve参数不一定真正能达到解析的效果），供继承用  
  5. protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException …   
  6.   
  7. //findClass方法一般被loadClass方法调用去加载指定名称类，供继承用  
  8. protected Class<?> findClass(String name) throws ClassNotFoundException  …   
  9.   
  10. //定义类型，一般在findClass方法中读取到对应字节码后调用，可以看出不可继承  
  11. //（说明：JVM已经实现了对应的具体功能，解析对应的字节码，产生对应的内部数据结构放置到方法区，所以无需覆写，直接调用就可以了）  
  12. protected final Class<?> defineClass(String name, byte[] b, int off, int len) throws ClassFormatError …   
　　 通过进一步分析标准扩展类加载器（ sun.misc.Launcher$ExtClassLoader ）和系统类加载器（ sun.misc.Launcher$AppClassLoader ）的代码以及其公共父类（ java.net.URLClassLoader 和 java.security.SecureClassLoader ）的代码可以看出，都没有覆写 java.lang.ClassLoader中默认的加载委派规则---loadClass（… ）方法。既然这样，我们就可以通过分析 java.lang.ClassLoader 中的 loadClass （ String name）方法的代码就可以分析出虚拟机默认采用的双亲委派机制到底是什么模样： [java]  view plain  copy
  1. public Class<?> loadClass(String name) throws ClassNotFoundException   
  2.     return loadClass(name, false);  
  3.   
  4.   
  5. protected synchronized Class<?> loadClass(String name, boolean resolve)  
  6.         throws ClassNotFoundException   
  7.   
  8.     // 首先判断该类型是否已经被加载  
  9.     Class c = findLoadedClass(name);  
  10.     if (c == null)   
  11.         //如果没有被加载，就委托给父类加载或者委派给启动类加载器加载  
  12.         try   
  13.             if (parent != null)   
  14.                 //如果存在父类加载器，就委派给父类加载器加载  
  15.                 c = parent.loadClass(name, false);  
  16.              else   
  17.                 //如果不存在父类加载器，就检查是否是由启动类加载器加载的类，  
  18.                 //通过调用本地方法native findBootstrapClass0(String name)  
  19.                 c = findBootstrapClass0(name);  
  20.               
  21.          catch (ClassNotFoundException e)   
  22.             // 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能  
  23.             c = findClass(name);  
  24.           
  25.       
  26.     if (resolve)   
  27.         resolveClass(c);  
  28.       
  29.     return c;  
  30.   
　　通过上面的代码分析，我们可以对 JVM 采用的双亲委派类加载机制有了更感性的认识，下面我们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。可能大家已经从各种资料上面看到了如下类似的一幅图片：

图三 类加载器默认委派关系图

　　上面图片给人的直观印象是系统类加载器的父类加载器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面我们就用代码具体测试一下：

[java]  view plain  copy
  1. public class LoaderTest   
  2.   
  3.     public static void main(String[] args)   
  4.         try   
  5.             System.out.println(ClassLoader.getSystemClassLoader());  
  6.             System.out.println(ClassLoader.getSystemClassLoader().getParent());  
  7.             System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());  
  8.          catch (Exception e)   
  9.             e.printStackTrace();  
  10.           
  11.       
  12.   
　　说明：通过java.lang.ClassLoader.getSystemClassLoader()可以直接获取到系统类加载器。
　　代码输出如下：
[plain]  view plain  copy
  1. sun.misc.Launcher$AppClassLoader@6d06d69c  
  2. sun.misc.Launcher$ExtClassLoader@70dea4e  
  3. null  
　　通过以上的代码输出，我们可以判定系统类加载器的父加载器是标准扩展类加载器，但是我们试图获取标准扩展类加载器的父类加载器时确得到了 null，就是说标准扩展类加载器本身强制设定父类加载器为null 。我们还是借助于代码分析一下。

　　我们首先看一下java.lang.ClassLoader抽象类中默认实现的两个构造函数：

[java]  view plain  copy
  1. protected ClassLoader()   
  2.     SecurityManager security = System.getSecurityManager();  
  3.     if (security != null)   
  4.         security.checkCreateClassLoader();  
  5.       
  6.     //默认将父类加载器设置为系统类加载器，getSystemClassLoader()获取系统类加载器  
  7.     this.parent = getSystemClassLoader();  
  8.     initialized = true;  
  9.   
  10.   
  11. protected ClassLoader(ClassLoader parent)   
  12.     SecurityManager security = System.getSecurityManager();  
  13.     if (security != null)   
  14.         security.checkCreateClassLoader();  
  15.       
  16.     //强制设置父类加载器  
  17.     this.parent = parent;  
  18.     initialized = true;  
  19.   
　　 我们再看一下 深入理解Java类加载器：Java类加载原理解析

深入理解Java类加载器：Java类加载原理解析

深入理解：java类加载器

深入理解Java类

类加载器盲区整理

深入理解JVM——类加载器原理