黑马程序员技术交流社区

标题: Java类加载原理解析 [打印本页]

作者: 李江 时间: 2013-10-7 17:46
标题: Java类加载原理解析
[转载]http://www.blogjava.net/zhuxing/archive/2008/08/08/220841.html

1 基本信息

摘要：

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

由于关于java类加载的内容较多，所以打算分三篇文章简述一下：

第一篇：java类加载原理解析

第二篇：插件环境下类加载原理解析

第三篇：线程上下文类加载器

分类：开发技术－>J2EE

标签：Java类加载类加载器双亲委派机制自定义类加载器

作者：朱兴创建于2007-6-22 MSN：zhu_xing@live.cn

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

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

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

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

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

系统（System）类加载器：系统类加载器是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。

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

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

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

file:///C:/Users/river/AppData/Local/Temp/msohtmlclip1/01/clip_image005.jpg
图五扩展类加载器和系统类加载器公共父类成员大纲视图

通过图四和图五可以看出，标准扩展类加载器和系统类加载器及其父类（java.net.URLClassLoader和java.security.SecureClassLoader）都没有覆写java.lang.ClassLoader中默认的加载委派规则---loadClass（…）方法。有关java.lang.ClassLoader中默认的加载委派规则前面已经分析过，如果父加载器为null，则会调用本地方法进行启动类加载尝试。所以，图三中，启动类加载器、标准扩展类加载器和系统类加载器之间的委派关系事实上是仍就成立的。（在后面的用户自定义类加载器部分，还会做更深入的分析）。

2.3 类加载双亲委派示例

以上已经简要介绍了虚拟机默认使用的启动类加载器、标准扩展类加载器和系统类加载器，并以三者为例结合JDK代码对JVM默认使用的双亲委派类加载机制做了分析。下面我们就来看一个综合的例子。首先在eclipse中建立一个简单的java应用工程，然后写一个简单的JavaBean如下：

package classloader.test.bean;

publicclass TestBean {

public TestBean() {}

}

在现有当前工程中另外建立一测试类（ClassLoaderTest.java）内容如下：

测试一：

publicclass ClassLoaderTest {

publicstaticvoid main(String[]args) {

try {

//查看当前系统类路径中包含的路径条目

System.out.println(System.getProperty("java.class.path"));

//调用加载当前类的类加载器（这里即为系统类加载器）加载TestBean

Class typeLoaded = Class.forName("classloader.test.bean.TestBean");

//查看被加载的TestBean类型是被那个类加载器加载的

System.out.println(typeLoaded.getClassLoader());

} catch (Exception e) {

e.printStackTrace();

}

对应的输出如下：

D:"DEMO"dev"Study"ClassLoaderTest"bin

sun.misc.Launcher$AppClassLoader@197d257

（说明：当前类路径默认的含有的一个条目就是工程的输出目录）

作者: 李江 时间: 2013-10-7 17:47
本帖最后由李江于 2013-10-7 17:49 编辑

第二部分

4.3 在编写自定义类加载器时，如果没有设定父加载器，那么父加载器是？

前面讲过，在不指定父类加载器的情况下，默认采用系统类加载器。可能有人觉得不明白，现在我们来看一下JDK对应的代码实现。众所周知，我们编写自定义的类加载器直接或者间接继承自java.lang.ClassLoader抽象类，对应的无参默认构造函数实现如下：

//摘自java.lang.ClassLoader.java

protected ClassLoader() {

SecurityManager security = System.getSecurityManager();

if (security != null) {

security.checkCreateClassLoader();

}

this.parent = getSystemClassLoader();

initialized = true;

}

我们再来看一下对应的getSystemClassLoader()方法的实现:

privatestaticsynchronizedvoid initSystemClassLoader() {

//...

sun.misc.Launcher l = sun.misc.Launcher.getLauncher();

scl = l.getClassLoader();

//...

}

我们可以写简单的测试代码来测试一下：

System.out.println(sun.misc.Launcher.getLauncher().getClassLoader());

本机对应输出如下:

sun.misc.Launcher$AppClassLoader@197d257

所以，我们现在可以相信当自定义类加载器没有指定父类加载器的情况下，默认的父类加载器即为系统类加载器。同时，我们可以得出如下结论：

即时用户自定义类加载器不指定父类加载器，那么，同样可以加载如下三个地方的类：

1. <Java_Runtime_Home>/lib下的类

2. < Java_Runtime_Home >/lib/ext下或者由系统变量java.ext.dir指定位置中的类

3. 当前工程类路径下或者由系统变量java.class.path指定位置中的类

4.4 在编写自定义类加载器时，如果将父类加载器强制设置为null，那么会有什么影响？如果自定义的类加载器不能加载指定类，就肯定会加载失败吗？

JVM规范中规定如果用户自定义的类加载器将父类加载器强制设置为null，那么会自动将启动类加载器设置为当前用户自定义类加载器的父类加载器(这个问题前面已经分析过了)。同时，我们可以得出如下结论：

即时用户自定义类加载器不指定父类加载器，那么，同样可以加载到<Java_Runtime_Home>/lib下的类，但此时就不能够加载<Java_Runtime_Home>/lib/ext目录下的类了。

说明：问题3和问题4的推断结论是基于用户自定义的类加载器本身延续了java.lang.ClassLoader.loadClass（…）默认委派逻辑，如果用户对这一默认委派逻辑进行了改变，以上推断结论就不一定成立了，详见问题5。

作者: 李江 时间: 2013-10-7 17:50
第三部分

4.5 编写自定义类加载器时，一般有哪些注意点？
1.    一般尽量不要覆写已有的loadClass（…）方法中的委派逻辑
一般在JDK 1.2之前的版本才这样做，而且事实证明，这样做极有可能引起系统默认的类加载器不能正常工作。在JVM规范和JDK文档中（1.2或者以后版本中），都没有建议用户覆写loadClass(…)方法，相比而言，明确提示开发者在开发自定义的类加载器时覆写findClass(…)逻辑。举一个例子来验证该问题：
//用户自定义类加载器WrongClassLoader.Java（覆写loadClass逻辑）
publicclassWrongClassLoaderextends ClassLoader {
      public Class<?> loadClass(String name) throws ClassNotFoundException {
         returnthis.findClass(name);
      }
      protected Class<?> findClass(String name) throws ClassNotFoundException {
         //假设此处只是到工程以外的特定目录Ｄ：/library下去加载类
         具体实现代码省略
      }
}
通过前面的分析我们已经知道，用户自定义类加载器（WrongClassLoader）的默
   认的类加载器是系统类加载器，但是现在问题4种的结论就不成立了。大家可以简
   单测试一下，现在<Java_Runtime_Home>/lib、< Java_Runtime_Home >/lib/ext和工
   程类路径上的类都加载不上了。
   //问题5测试代码一
publicclass WrongClassLoaderTest {
      publicstaticvoid main(String[] args) {
         try {
            WrongClassLoader loader = new WrongClassLoader();
            Class classLoaded = loader.loadClass("beans.Account");
            System.out.println(classLoaded.getName());
            System.out.println(classLoaded.getClassLoader());
         } catch (Exception e) {
            e.printStackTrace();
         }
      }
}
（说明：D:"classes"beans"Account.class物理存在的）
输出结果：
java.io.FileNotFoundException: D:"classes"java"lang"Object.class (系统找不到指定的路径。)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at WrongClassLoader.findClass(WrongClassLoader.java:40)
at WrongClassLoader.loadClass(WrongClassLoader.java:29)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:400)
at WrongClassLoader.findClass(WrongClassLoader.java:43)
at WrongClassLoader.loadClass(WrongClassLoader.java:29)
at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)
Exception in thread "main" java.lang.NoClassDefFoundError: java/lang/Object
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at java.lang.ClassLoader.defineClass(ClassLoader.java:400)
at WrongClassLoader.findClass(WrongClassLoader.java:43)
at WrongClassLoader.loadClass(WrongClassLoader.java:29)
at WrongClassLoaderTest.main(WrongClassLoaderTest.java:27)
这说明，连要加载的类型的超类型java.lang.Object都加载不到了。这里列举的由于覆写loadClass（…）引起的逻辑错误明显是比较简单的，实际引起的逻辑错误可能复杂的多。
//问题5测试二
//用户自定义类加载器WrongClassLoader.Java(不覆写loadClass逻辑)
publicclassWrongClassLoaderextends ClassLoader {
      protected Class<?> findClass(String name) throws ClassNotFoundException {
         //假设此处只是到工程以外的特定目录Ｄ：/library下去加载类
         具体实现代码省略
      }
}
将自定义类加载器代码WrongClassLoader.Java做以上修改后，再运行测试代码，输出结果如下：
beans.Account
WrongClassLoader@1c78e57
这说明，beans.Account加载成功，且是由自定义类加载器WrongClassLoader加载。
这其中的原因分析，我想这里就不必解释了，大家应该可以分析的出来了。
2.    2、正确设置父类加载器
通过上面问题4和问题5的分析我们应该已经理解，个人觉得这是自定义用户类加载器时最重要的一点，但常常被忽略或者轻易带过。有了前面JDK代码的分析作为基础，我想现在大家都可以随便举出例子了。
3.    3、保证findClass（String ）方法的逻辑正确性
事先尽量准确理解待定义的类加载器要完成的加载任务，确保最大程度上能够获取到对应的字节码内容。
4.6 如何在运行时判断系统类加载器能加载哪些路径下的类？
一是可以直接调用ClassLoader.getSystemClassLoader()或者其他方式获取到系统类加载器（系统类加载器和扩展类加载器本身都派生自URLClassLoader），调用URLClassLoader中的getURLs()方法可以获取到；
二是可以直接通过获取系统属性java.class.path 来查看当前类路径上的条目信息， System.getProperty("java.class.path")
4.7 如何在运行时判断标准扩展类加载器能加载哪些路径下的类？
方法之一：
try {
            URL[] extURLs = ((URLClassLoader)ClassLoader.getSystemClassLoader().getParent()).getURLs();
            for (int i = 0; i < extURLs.length; i++) {
                  System.out.println(extURLs[i]);
            }
   } catch (Exception e) {//…}
   本机对应输出如下：
file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/dnsns.jar
file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/localedata.jar
file:/D:/DEMO/jdk1.5.0_09/jre/lib/ext/sunjce_provider.jar
file:/D:/D

EMO/jdk1.5.0_09/jre/lib/ext/sunpkcs11.jar
5    总结：
中间参考了JVM规范、jdk文档和代码、《Inside Java Virtual Machine》一书等资料

作者: To 时间: 2013-10-7 18:25
顶一个~~~继续保持分享

欢迎光临黑马程序员技术交流社区 (http://bbs.itheima.com/)

黑马程序员IT技术论坛 X3.2