Java热加载的实现

　　对于许多关键性业务或者庞大的 Java 系统来说，如果必须暂停系统服务才能进行系统升级，既会大大影响到系统的可用性，同时也增加了系统的管理和维护成本。因此，如果能够方便地在不停止系统业务的情况下进行系统升级，则可以很好地解决上述问题。应用服务器一般都支持热部署或者热加载(Hot Deployment或者Hot Swap)，即更新代码保存时把新编译类替换旧的类，后面的程序就执行新类中的代码。这也是由各种应用服务器的独有的类加载器层次实现的。那如何在我们的程序中也实现这种热加载功能呢（--项目中的副本和活动等模块都喜欢写成这种形式的脚本--script）？

　　即要在不重启JVM虚拟机的情况下，更新类的代码后，JVM就知道加载这个新类，执行新类中的逻辑。

　　在 Java 中，类的实例化流程分为两个部分：类的加载和类的实例化。类的加载又分为显式加载和隐式加载。大家使用 new 关键字创建类实例时，其实就隐式地包含了类的加载过程。对于类的显式加载来说，比较常用的是 Class.forName。其实，它们都是通过调用 ClassLoader 类的 loadClass 方法来完成类的实际加载工作的。直接调用 ClassLoader 的 loadClass 方法是另外一种不常用的显式加载类的技术。首先大致了解一下类加载器：

标准 Java 启动器的类加载器层次：

1. 引导类加载器(bootstrap)：加载内核 API，如 rt.jar(java.lang、java.io 等)
2. 扩展类加载器(extension)：加载的默认扩展来自于 jre/lib/ext
3. 系统类加载器(system)：类路径上的类，如 com.wuenqiang.*

说明：这只是标准 Java 启动器运行程序时的类加载器层次，像应用服务器中的类加载器通常会多一两层，也是在这个基础上的延伸。上面的类加载层次存在自上而下的委托关系。

类加载器的规则：

1. 一致性规则：类加载器不能多次加载同一个类。
2. 委托规则：在加载一个类之前，类加载器总参考父类加载器。
3. 可见性规则：类只能看到由其类加载器的委托加载的其他类，委托是类的加载器及其所有父类加载器的递归集。

 

下面就简单演示这样一个热加载的例子：

首先要建立两个普通的 Java 工程，分别是 TestHotDeployInf 和 TestHotDeployImpl。让 TestHotDeployImpl 依赖于 TestHotDeployInf 工程，即在 TestHotDeployImpl 的 Build Path 中，Projects 标签页里把 TestHotDeployInf 工程选进来，因为编译 TestHotDeployImpl 中的类要用到 TestHotDeployInf 中的类。

然后在工程式 TestHotDeployInf 中新建一个接口(Cat.java) 和一个类(Client.java)，内容分别是：

Cat.java(Cat 接口类，也可以用抽象类，用来引用需热加载的实现类的实例)

package com.wuenqiang;

/**
 * Cat 接口，要热加载的类一定要有一个接口或基类引用
 */
public interface Cat {
    public void miaow();
}

package com.wuenqiang;

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.net.URL;
import java.net.URLClassLoader;


/**
 * 测试热部署 Hot Deployment 的客户端类
 */
public class Client {
    
    private static ClassLoader cl;
    private static Class catClass;

    public static void main(String[] args) throws Exception{
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        Cat cat = createCat();
        System.out.println("miaow, reload, or exit");
        while(true){
　　　　　　　//根据不同的协议命令执行不同的逻辑，利用热加载，我们可以在修改具体的逻辑代码之后不重启服务器实现热加载
            String cmd = br.readLine();
            if(cmd.equalsIgnoreCase("exit")){
                return;
            } else if(cmd.equalsIgnoreCase("reload")){
                reloadImpl();
                cat = createCat();
                System.out.println("CatImpl reloaded.");
            } else if(cmd.equalsIgnoreCase("miaow")){
                cat.miaow();
            }
        }
    }

    /**
     * 使用加载的类 Cat 类创建 Cat 实例*/
    public static synchronized Cat createCat() throws Exception{
        if(catClass==null){
            reloadImpl();
        }
        Cat newCat = (Cat)catClass.newInstance();
        return newCat;
    }
    
    /**
     * 用自定义的类加载器重新加载 CatImpl 实现类，方便直接读取 TestHotDeployImpl 下随时修改后编译成的新的 CatImpl 类，避免了 class 文件编译后拷贝到别处
     */
    public static synchronized void reloadImpl() throws Exception{
        URL[] externalURLs = new URL[]{new URL("file:../TestHotDeployImpl/bin/")};
        cl = new URLClassLoader(externalURLs);
        catClass = cl.loadClass("com.wuenqiang.CatImpl");
    }
}

package com.wuenqiang;

/**
 * Cat 的实现类，观察是否加载了最新代码，可通过改变 miaow() 方法的输出*/
public class CatImpl implements Cat {

    @Override
    public void miaow() {
        System.out.println("I'm Hello Kity, I like play with you.");
    }
}

 

几个问题：

1) 为什么要在单独的工程里放置 CatImpl 类(重要)：
        主要是为了编译成的 CatImpl 类对于 TestHotDeployInf 的系统加载类不可见，就是不能放在 TestHotDeployInf 的程序的 classpath 中。
        这个问题可以说大，本应该提高一个层次来说明它。前面提过标准 Java 启动器加载器层次中有三个加载器，而在上面的 Client.java 中，我们看到用了一个自定义的 cl = new URLClassLoader(externalURLs) 类加载器来加载 com.wuenqiang.CatImpl。也就是标准的类加载器又多了一层，这里估且把它叫做应用程序加载器(AppClassloader)。

        根据委托规则，执行 Client 时，要加载 com.wuenqiang.CatImpl 时会首先委托加载 Client 类本身的系统加载器加载。如果编译出的 CatImpl.class 放在 Cat.class 相同的位置，那么就由系统加载器来加载 com.wuenqiang.CatImpl，自定义加载器 cl 是没机会了。所以必须放在外面让系统加载器看不到 com.wuenqiang.CatImpl 类。

        再依据一致性规则，如果系统加载器能加载了 com.wuenqiang.CatImpl 类，以后你怎么修改 CatImpl 类，替换掉原来的类，内存中总是最先加载的那个 com.wuenqiang.CatImpl 类版本。因为类只会加载一次。而用自定义的 cl 可不一样了，每次执行 cl.loadClass("com.wuenqiang.CatImpl") 时都是用的一个新的 ClassLoader 实例，所以不受一致性规则的约束，每次都会加载最新版本的 CatImpl 类。

2) 关于类的卸载的问题：

        上一条讲了加载 com.wuenqiang.CatImpl 时，每次都 new 了一个新了 ClassLoader 实例，每次都加载最新的 CatImpl 类，那就引出了不再使用的 ClassLoader 实例和早先旧版本的 CatImpl 类实例的回收问题。在多数 JVM 中，它们如同普通的 Java 对象一样的处理，当它们无从触及时被当作垃圾被收集掉。也可能在某些 JVM 中这种情况对 ClassLoader 和旧版本 Class 实例的回收要特殊关照一下。

       这里的 Class 实例，就是对象调用 getClass() 得到的实例，如 CatImpl.getClass()。类实例和类加载器是相关联的，所有会出现这样的问题，相同类的静态变量可能表现为不同的值，因为它们可能是由不同的类加载器加载的。

---

对于 ClassLoader 确未细细深入，其实要展开的话内容也不多，关键就知道两点(还是回到了前面的两点，等于什么都没说哦)：

      1)了解你的程序的类加载器层次，应该看看常见应用服务器(如 Tomcat) 的类加载器层次

      2) 理解类加载器的三个规则，着重理解委托机制

知道了类加载器层次，你就可以进行一些定制。如可以把一些包丢到 jre/lib/ext 中就能使用到；给 java 用参数 -Xbootclasspath 指定别的类或包就能替换掉 Java 核心 API 了。

对于可见性规则可以举两个例子：

      1) 对于标准的类加载器层次，放在 jre/lib/ext 中的类(由扩展类加载器加载)可以让放在 classpath 下的类(由系统类加载器加载) 访问到，反过来就不行了。

      2) 应用服务器中不同的 Web 应用中类不能相互访问，因为它们是由不同的类加载器加载的，且是在并行结构中。而在企业应用程序中的 WAR 包使用到 EJB 包和其他工具包，因为加载 WAR 包的类加载层是在加载 EJB 包和其他工具包的类加载器的下层。