《Java类加载原理解析.doc》由会员分享，可在线阅读，更多相关《Java类加载原理解析.doc（12页珍藏版）》请在金锄头文库上搜索。
1、Java类加载原理解析 分类： java应用 2010-07-14 14:07 55人阅读 评论(0) 收藏 举报 Java 类加载原理解析 1 基本信息 摘要： 每个 java开发人员对 java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生，这背后就涉及到了 java技术体系中的类加载。 Java的类加载机制是 java技术体系中比较核心的部分，虽然和大部分开发人员直接打交道不多，但是对其背后的机理有一定理解有助于排查程序中出现的类加载失败等技术问题，对理解 java虚拟机的连接模型和 java语言的动态性都有很大帮助。 由于关于 java类加载的内容较多，所
2、以打算分三篇文章简述一下： 第一篇： java类加载原理解析 第二篇：插件环境下类加载原理解析 第三篇：线程上下文类加载器 分类 ： 开发技术 J2EE 标签： Java 类加载 类加载器 双亲委派机制 自定义类加载器 作者： 朱兴 创建于 2007-6-22 MSN ： zhu_2 Java虚拟机类加载器结构简述 2.1 JVM三种预定义类型类加载器 我们首先看一下 JVM预定义的三种类型类加载器，当一个 JVM 启动的时候， Java 缺省开始使用如下三种类型类装入器： 启动（ Bootstrap ）类加载器 ：引导类装入器是用本地代码实现的类装入器，它负责将 /lib 下面的类库加载到内
3、存中。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。 标准扩展（ Extension ）类加载器 ：扩展类加载器是由 Sun 的 ExtClassLoader（ sun.misc.Launcher$ExtClassLoader） 实现的。它负责将 /lib/ext 或者由系统变量 java.ext.dir 指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器。 系统（ System ）类加载器 ：系统类加载器是由 Sun 的 AppClassLoader（ sun.misc.Launcher$AppClassLoa
4、der）实现的。它负责将系统类路径（ CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。 除了以上列举的三种类加载器，还有一种比较特殊的类型就是线程上下文类加载器 ，这个将在后面单独介绍。 2.2 类加载双亲委派机制介绍和分析 在这里，需要着重说明的是， JVM在加载类时默认采用的是双亲委派 机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。关于虚拟机默认的双亲委派机制，我们可以从系统类加载器和标准扩展类加载器为例作简单
5、分析。 图一 标准扩展类加载器继承层次图 图二 系统类加载器继承层次图 通过图一和图二我们可以看出，类加载器均是继承自 java.lang.ClassLoader抽象类。我们下面我们就看简要介绍一下 java.lang.ClassLoader中几个最重要的方法 :/加载指定名称（包括包名）的二进制类型，供用户调用的接口 public Class loadClass (String name) throws ClassNotFoundException/加载指定名称（包括包名）的二进制类型，同时指定是否解析（但是，这里的 resolve参数不一定真正能达到解析的效果 _），供继承用 protec
6、ted synchronized Class loadClass (String name, boolean resolve) throws ClassNotFoundException/findClass方法一般被 loadClass方法调用去加载指定名称类，供继承用 protected Class findClass (String name) throws ClassNotFoundException /定义类型，一般在 findClass方法中读取到对应字节码后调用，可以看出不可继承（说明： JVM已经实现了对应的具体功能，解析对应的字节码，产生对应的内部数据结构放置到方法区，所以无需
7、覆写，直接调用就可以了） protected final Class defineClass (String name, byte b, int off, int len)throws ClassFormatError/ 通过进一步分析标准扩展类加载器（ sun.misc.Launcher$ExtClassLoader）和系统类加载器（ sun.misc.Launcher$AppClassLoader）的代码以及其公共父类（ .URLClassLoader和 java.security.SecureClassLoader）的代码可以看出，都没有覆写 java.lang.ClassLoader中
8、默认的加载委派规则 -loadClass（ ）方法。既然这样，我们就可以通过分析 java.lang.ClassLoader中的 loadClass（ String name）方法的代码就可以分析出虚拟机默认采用的双亲委派机制到底是什么模样： public Class loadClass (String name) throws ClassNotFoundException return loadClass(name, false ); protected synchronized Class loadClass(String name, boolean resolve) throws Cla
9、ssNotFoundException / 首先判断该类型是否已经被加载 Class c = findLoadedClass(name); if (c = null ) / 如果没有被加载，就委托给父类加载或者委派给启动类加载器加载 try if (parent != null ) / 如果存在父类加载器，就委派给父类加载器加载 c = parent.loadClass(name, false ); else / 如果不存在父类加载器，就检查是否是由启动类加载器加载的类，通过调用本地方法 native Class findBootstrapClass(String name) c = find
10、BootstrapClass0(name); catch (ClassNotFoundException e) / 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能 c = findClass (name); if (resolve) resolveClass(c); return c; 通过上面的代码分析，我们可以对 JVM采用的双亲委派类加载机制有了更感性的认识，下面我们就接着分析一下启动类加载器、标准扩展类加载器和系统类加载器三者之间的关系。可能大家已经从各种资料上面看到了如下类似的一幅图片：图三 类加载器默认委派关系图 上面图片给人的直观印象是系统类加载器的父类加载
11、器是标准扩展类加载器，标准扩展类加载器的父类加载器是启动类加载器，下面我们就用代码具体测试一下： 示例代码：public static void main(Stringargs) try System.out.println(ClassLoader.getSystemClassLoader();System.out.println(ClassLoader.getSystemClassLoader().getParent();System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent(); catch (
12、Exceptione)e.printStackTrace(); 说明：通过 java.lang.ClassLoader.getSystemClassLoader () 可以直接获取到系统类加载器。 代码输出如下： sun.misc.Launcher$AppClassLoader197d257 sun.misc.Launcher$ExtClassLoader7259da null 通过以上的代码输出，我们可以判定系统类加载器的父加载器是标准扩展类加载器，但是我们试图获取标准扩展类加载器的父类加载器时确得到了 null ，就是说标准扩展类加载器本身强制设定父类加载器为 null 。我们还是借助于代
13、码分析一下： 我们首先看一下 java.lang.ClassLoader 抽象类中默认实现的两个构造函数： protected ClassLoader() SecurityManager security = System.getSecurityManager (); if (security != null ) security.checkCreateClassLoader(); / 默认将父类加载器设置为系统类加载器， getSystemClassLoader() 获取系统类加载器 this .parent = getSystemClassLoader(); initialized = true ; protected ClassLoader(ClassLoader parent) SecurityManager security = System.getSecurityManager (); if (security != null )
