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
。解决方法很简单，只要该对象实现一个接口，然后用父类去强制转换就没有问题了。
以上只是我在学习过程中的一点积累，如果有什么错误，欢迎大家评论。