JAVA类动态载入的实现【转】-优快云博客

1 前言

前段时间因为项目的需要，我搞了一套类似Servlet重新载入的一个框架，实现了类的动态载入过程。本文写了一些我的学习成果以及心得供大家分享一下。

2 类载入的原理

（下面引用网上的一篇文章）：

当JVM（Java虚拟机）启动时，会形成由三个类加载器组成的初始类加载器层次结构：

        bootstrap classloader
                 |
        extension classloader
                 |
        system classloader

bootstrap classloader －引导（也称为原始）类加载器，它负责加载Java的核心类。在Sun的JVM中，在执行java的命令中使用-Xbootclasspath选项或使用-D选项指定sun.boot.class.path系统属性值可以指定附加的类。这个加载器的是非常特殊的，它实际上不是java.lang.ClassLoader的子类，而是由JVM自身实现的。大家可以通过执行以下代码来获得bootstrap classloader加载了那些核心类库：
    URL[] urls=sun.misc.Launcher.getBootstrapClassPath().getURLs();
    for (int i = 0; i < urls.length; i++) {
      System.out.println(urls.toExternalForm());
    }
在我的计算机上的结果为：
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/dom.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/sax.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xalan-2.3.1.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xercesImpl-2.0.0.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xml-apis.jar
file:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xsltc.jar
file:/C:/j2sdk1.4.1_01/jre/lib/rt.jar
file:/C:/j2sdk1.4.1_01/jre/lib/i18n.jar
file:/C:/j2sdk1.4.1_01/jre/lib/sunrsasign.jar
file:/C:/j2sdk1.4.1_01/jre/lib/jsse.jar
file:/C:/j2sdk1.4.1_01/jre/lib/jce.jar
file:/C:/j2sdk1.4.1_01/jre/lib/charsets.jar
file:/C:/j2sdk1.4.1_01/jre/classes
这时大家知道了为什么我们不需要在系统属性CLASSPATH中指定这些类库了吧，因为JVM在启动的时候就自动加载它们了。

extension classloader －扩展类加载器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ext或者由java.ext.dirs系统属性指定的）中JAR的类包。这为引入除Java核心类以外的新功能提供了一个标准机制。因为默认的扩展目录对所有从同一个JRE中启动的JVM都是通用的，所以放入这个目录的JAR类包对所有的JVM和system classloader都是可见的。在这个实例上调用方法getParent()总是返回空值null，因为引导加载器bootstrap classloader不是一个真正的ClassLoader实例。所以当大家执行以下代码时：
    System.out.println(System.getProperty("java.ext.dirs"));
    ClassLoader extensionClassloader=ClassLoader.getSystemClassLoader().getParent();
    System.out.println("the parent of extension classloader : "+extensionClassloader.getParent());
结果为：
C:\j2sdk1.4.1_01\jre\lib\ext
the parent of extension classloader : null
extension classloader是system classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一个实际的classloader，所以为null。

system classloader －系统（也称为应用）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系统属性或者CLASSPATH操作系统属性所指定的JAR类包和类路径。总能通过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。如果没有特别指定，则用户自定义的任何类加载器都将该类加载器作为它的父加载器。执行以下代码即可获得：
    System.out.println(System.getProperty("java.class.path"));
输出结果则为用户在系统属性里面设置的CLASSPATH。
classloader加载类用的是全盘负责委托机制。所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入；委托机制则是先让parent（父）类加载器(而不是super，它与parent classloader类不是继承关系)寻找，只有在parent找不到的时候才从自己的类路径中去寻找。此外类加载还采用了cache机制，也就是如果cache中保存了这个Class就直接返回它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么我们修改了Class但是必须重新启动JVM才能生效的原因。

每个ClassLoader加载Class的过程是：
1.检测此Class是否载入过（即在cache中是否有此Class），如果有到8,如果没有到2
2.如果parent classloader不存在（没有parent，那parent一定是bootstrap classloader了），到4
3.请求parent classloader载入，如果成功到8，不成功到5
4.请求jvm从bootstrap classloader中载入，如果成功到8
5.寻找Class文件（从与此classloader相关的类路径中寻找）。如果找不到则到7.
6.从文件中载入Class，到8.
7.抛出ClassNotFoundException.
8.返回Class.

其中5.6步我们可以通过覆盖ClassLoader的findClass方法来实现自己的载入策略。甚至覆盖loadClass方法来实现自己的载入过程。

类加载器的顺序是：
先是bootstrap classloader，然后是extension classloader，最后才是system classloader。大家会发现加载的Class越是重要的越在靠前面。这样做的原因是出于安全性的考虑，试想如果system classloader“亲自”加载了一个具有破坏性的“java.lang.System”类的后果吧。这种委托机制保证了用户即使具有一个这样的类，也把它加入到了类路径中，但是它永远不会被载入，因为这个类总是由bootstrap classloader来加载的。大家可以执行一下以下的代码：
    System.out.println(System.class.getClassLoader());
将会看到结果是null，这就表明java.lang.System是由bootstrap classloader加载的，因为bootstrap classloader不是一个真正的ClassLoader实例，而是由JVM实现的，正如前面已经说过的。

下面就让我们来看看JVM是如何来为我们来建立类加载器的结构的：
sun.misc.Launcher，顾名思义，当你执行java命令的时候，JVM会先使用bootstrap classloader载入并初始化一个Launcher，执行下来代码：
   System.out.println("the Launcher's classloader is "+sun.misc.Launcher.getLauncher().getClass().getClassLoader());
结果为：
   the Launcher's classloader is null (因为是用bootstrap classloader加载,所以class loader为null)
Launcher会根据系统和命令设定初始化好class loader结构，JVM就用它来获得extension classloader和system classloader,并载入所有的需要载入的Class，最后执行java命令指定的带有静态的main方法的Class。extension classloader实际上是sun.misc.Launcher$ExtClassLoader类的一个实例，system classloader实际上是sun.misc.Launcher$AppClassLoader类的一个实例。并且都是java.net.URLClassLoader的子类。

让我们来看看Launcher初试化的过程的部分代码。

Launcher的部分代码：
public class Launcher {
    public Launcher() {
        ExtClassLoader extclassloader;
        try {
            //初始化extension classloader
            extclassloader = ExtClassLoader.getExtClassLoader();
        } catch(IOException ioexception) {
            throw new InternalError("Could not create extension class loader");
        }
        try {
            //初始化system classloader，parent是extension classloader
            loader = AppClassLoader.getAppClassLoader(extclassloader);
        } catch(IOException ioexception1) {
            throw new InternalError("Could not create application class loader");
        }
        //将system classloader设置成当前线程的context classloader（将在后面加以介绍）
        Thread.currentThread().setContextClassLoader(loader);
        ......
    }
    public ClassLoader getClassLoader() {
        //返回system classloader
        return loader;
    }
}

extension classloader的部分代码：
static class Launcher$ExtClassLoader extends URLClassLoader {

    public static Launcher$ExtClassLoader getExtClassLoader()
        throws IOException
    {
        File afile[] = getExtDirs();
        return (Launcher$ExtClassLoader)AccessController.doPrivileged(new Launcher$1(afile));
    }
   private static File[] getExtDirs() {
        //获得系统属性“java.ext.dirs”
        String s = System.getProperty("java.ext.dirs");
        File afile[];
        if(s != null) {
            StringTokenizer stringtokenizer = new StringTokenizer(s, File.pathSeparator);
            int i = stringtokenizer.countTokens();
            afile = new File;
            for(int j = 0; j < i; j++)
                afile[j] = new File(stringtokenizer.nextToken());

        } else {
            afile = new File[0];
        }
        return afile;
    }
}

system classloader的部分代码：
static class Launcher$AppClassLoader extends URLClassLoader
{

    public static ClassLoader getAppClassLoader(ClassLoader classloader)
        throws IOException
    {
        //获得系统属性“java.class.path”
        String s = System.getProperty("java.class.path");
        File afile[] = s != null ? Launcher.access$200(s) : new File[0];
        return (Launcher$AppClassLoader)AccessController.doPrivileged(new Launcher$2(s, afile, classloader));
    }
}

    看了源代码大家就清楚了吧，extension classloader是使用系统属性“java.ext.dirs”设置类搜索路径的，并且没有parent。system classloader是使用系统属性“java.class.path”设置类搜索路径的，并且有一个parent classloader。Launcher初始化extension classloader，system classloader，并将system classloader设置成为context classloader，但是仅仅返回system classloader给JVM。

　　这里怎么又出来一个context classloader呢？它有什么用呢？我们在建立一个线程Thread的时候，可以为这个线程通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader，当此线程运行的时候，我们可以通过getContextClassLoader方法来获得此context classloader，就可以用它来载入我们所需要的Class。默认的是system classloader。利用这个特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前线程的context classloader，而这个context classloader可以是它的子classloader或者其他的classloader，那么父classloader就可以从其获得所需的Class，这就打破了只能向父classloader请求的限制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的classloader加载的时候,由system classloader(即在jvm classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的classloader中是其实现),例如web应用中的servlet就是用这种机制加载的.

    好了，现在我们了解了classloader的结构和工作原理，那么我们如何实现在运行时的动态载入和更新呢？只要我们能够动态改变类搜索路径和清除classloader的cache中已经载入的Class就行了，有两个方案，一是我们继承一个classloader，覆盖loadclass方法，动态的寻找Class文件并使用defineClass方法来；另一个则非常简单实用，只要重新使用一个新的类搜索路径来new一个classloader就行了，这样即更新了类搜索路径以便来载入新的Class，也重新生成了一个空白的cache(当然,类搜索路径不一定必须更改)。

（结束）

以上所述，想必大家对Jvm类载入的原理有了一定的了解，大致也猜到实现的方法了吧。

3 实现类的动态载入

结合上面说到，要JVM重新载入一个类，一共有3种办法：（我加了一种）

1. 重新写一个新的路径，更换包名或类名都是可行的方法。

2. 自己写一个类的寻找机制取代SystemClassLoader中的，再调用defineClass方法。

3. 覆盖loadClass方法，自己实现一个类载入过程。

显而易见，第一种方法是我自己添加上去的，而且应该是用得最多得方法，因为在对JVM的类搜索、载入机制不是很熟悉的前提下，只要做一些简单的修改就能达到所要的效果。（至少在我的项目中，这是首选，因为不会出错）

但如果第一种方法能实现，本文就没有写的意义了。在一个7 x 24 的大型系统中（如电信，银行等），用第一种方法，就凸现出它最大问题，就是代码变得无比庞大。因为每一个类的名字不同导致相同功能的类具有两个或以上的类文件存在，对代码的开发和维护来说，这是非常严重的问题。

好，现在又退回到开始，排除掉第一种方法，如果使用第三种方法，应该是可控性最高的方法，但本人才疏学浅，没有把握把整个类载入过程摸透，因此还是排除的第三种方法。

剩下只有第二种方法了。在ClassLoader中，defineClass方法是比较好理解的，只要传入类的字节流即可，因此，我只要重写一次类文件的载入。下面是我的实现代码：

public class testClassLoader extends ClassLoader {

private static testClassLoader cl = null;

private static boolean flag = true;

private InputStream classFile = null;

private String name = null;

/**

* @param name String 类全名

* @param url URL 类路径

* @throws FileNotFoundException

* @throws IOException

public testClassLoader(String name, URL url) throws

FileNotFoundException, IOException {

super(getSystemClassLoader());

this.name = name + ".class";

//打开URL指定的资源

URLConnection con = url.openConnection();

InputStream classIs = con.getInputStream();

this.classFile = classIs;

ByteArrayOutputStream baos = new ByteArrayOutputStream();

byte buf[] = new byte[1024];

//读取文件流

for (int i = 0; (i = classIs.read(buf)) != -1; ) {

baos.write(buf, 0, i);

}

classIs.close();

baos.close();

//创建新的类对象

byte[] data = baos.toByteArray();

defineClass(name, data, 0, data.length);

}

/**

* 重载 getResourceAsStream() 是为了返回该类的文件流。

* @return an InputStream of the class bytes, or null

public InputStream getResourceAsStream(String resourceName) {

try {

if (resourceName.equals(name)) {

return this.classFile;

}

} catch (Exception e) {

return null;

}

return null;

}

相信大家已经明白了吧。我在ClassLoader构造时便载入了指定的类文件，因此，就跳过了在new 新的对象时去查找Cache中该类是否有载入的过程。（注明一下：我的类路径用了URL的方式传入，目的是为了适应多平台的机制，因为Window和Linux的路径命名不一样）

相信聪明的你一定猜到后面应该怎么做了吧，没错，就是用Class.forName构建类：

String name = "test.testBlank";

URL url = new URL("file:/c:/test/classes/test/testBlank.class");

ClassLoader cl = new testClassLoader(name, url);

Class c = Class.forName(name, false, cl);

//实例化

Object obj = c.newInstance();

testInterface i = (testInterface) obj;

i.run();

你一定注意到了，为什么我用了一个testInterface，其实自定义ClassLoader中，不能直接以当前的类去直接强制转换，因为在JVM中，不同的ClassLoader载入同一个类，在JVM中是两个完全不同的类。因此，默认的class文件都是SystemClassLoader，所以会抛出ClassCastException。解决方法很简单，只要该对象实现一个接口，然后用父类去强制转换就没有问题了。

以上只是我在学习过程中的一点积累，如果有什么错误，欢迎大家评论