Java类中热替换的概念、设计与实现(3)
实现Java类的热替换
现在来介绍一下我们的实验方法,为了简单起见,我们的包为默认包,没有层次,并且省去了所有错误处理。要替换的类为Foo,实现很简单,仅包含一个方法sayHello:
- public class Foo{
- public void sayHello() {
- System.out.println("hello world! (version one)");
- }
- }
在当前工作目录下建立一个新的目录swap,把编译好的Foo.class文件放在该目录中。接下来要使用我们
- public void run(){
- try {
- // 每次都创建出一个新的类加载器
- HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
- Class clcls = cl.loadClass("Foo");
- Object foo = cls.newInstance();
- Method m = foo.getClass().getMethod("sayHello", new Class[]{});
- m.invoke(foo, new Object[]{});
- } catch(Exception ex) {
- ex.printStackTrace();
- }
- }
编译、运行我们的系统,会出现如下的打印:
图3.热替换前的运行结果
好,现在我们把Foo类的sayHello方法更改为:
- public void sayHello() {
- System.out.println("hello world! (version two)");
- }
在系统仍在运行的情况下,编译,并替换掉swap目录下原来的Foo.class文件,我们再看看屏幕的打印,奇妙的事情发生了,新更改的类在线即时生效了,我们已经实现了Foo类的热替换。屏幕打印如下:
图4.热替换后的运行结果
敏锐的读者可能会问,为何不用把foo转型为Foo,直接调用其sayHello方法呢?这样不是更清晰明了吗?下面我们来解释一下原因,并给出一种更好的方法。如果我们采用转型的方法,代码会变成这样:Foofoo=(Foo)cls.newInstance();读者如果跟随本文进行试验的话,会发现这句话会抛出ClassCastException异常,为什么吗?因为在Java中,即使是同一个类文件,如果是由不同的类加载器实例加载的,那么它们的类型是不相同的。在上面的例子中cls是由HowswapCL加载的,而foo变量类型声名和转型里的Foo类却是由run方法所属的类的加载器(默认为AppClassLoader)加载的,因此是完全不同的类型,所以会抛出转型异常。
那么通过接口调用是不是就行了呢?我们可以定义一个IFoo接口,其中声名sayHello方法,Foo实现该接口。也就是这样:IFoofoo=(IFoo)cls.newInstance();本来该方法也会有同样的问题的,因为外部声名和转型部分的IFoo是由run方法所属的类加载器加载的,而Foo类定义中implementsIFoo中的IFoo是由HotswapCL加载的,因此属于不同的类型转型还是会抛出异常的,但是由于我们在实例化HotswapCL时是这样的:
- HowswapCLcl=newHowswapCL("../swap",newString[]{"Foo"});
其中仅仅指定Foo类由HotswapCL加载,而其实现的IFoo接口文件会委托给系统类加载器加载,因此转型成功,采用接口调用的代码如下:
- public void run(){
- try {
- HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
- Class clcls = cl.loadClass("Foo");
- IFoo foo = (IFoo)cls.newInstance();
- foo.sayHello();
- } catch(Exception ex) {
- ex.printStackTrace();
- }
- }
确实,简洁明了了很多,在我们的实验中,每当定时器调度到run方法时,我们都会创建一个新的HotswapCL实例,在产品代码中,无需如此,仅当需要升级替换时才去创建一个新的类加载器实例。