如何本身手写一个热加载

时间 2019-12-05

标签如何本身手写一个加载繁體版

原文原文链接

如何本身手写一个热加载

热加载：在不中止程序运行的状况下，对类（对象）的动态替换

Java ClassLoader 简述

Java中的类从被加载到内存中到卸载出内存为止，一共经历了七个阶段：加载、验证、准备、解析、初始化、使用、卸载。html

接下来咱们重点讲解加载和初始化这两步java

加载

在加载的阶段，虚拟机须要完成如下三件事：数组

经过一个类的全限定名来获取定义此类的二进制字节流
将这个字节流所表明的的静态存储结构转化为方法区的运行时数据结构
在内存中生成一个表明这个类的java.lang.Class对象，做为方法区这个类的各类数据的访问入口。

这三步都是经过类加载器来实现的。而官方定义的Java类加载器有BootstrapClassLoader、ExtClassLoader、AppClassLoader。这三个类加载器分别负责加载不一样路径的类的加载。并造成一个父子结构。数据结构

类加载器名称	负责加载目录
`BootstrapClassLoader`	处于类加载器层次结构的最高层，负责 sun.boot.class.path 路径下类的加载，默认为 jre/lib 目录下的核心 API 或 -Xbootclasspath 选项指定的 jar 包
`ExtClassLoader`	加载路径为 java.ext.dirs，默认为 jre/lib/ext 目录或者 -Djava.ext.dirs 指定目录下的 jar 包加载
`AppClassLoader`	加载路径为 java.class.path，默认为环境变量 CLASSPATH 中设定的值。也能够经过 -classpath 选型进行指定

默认状况下，例如咱们使用关键字 new或者 Class.forName都是经过 AppClassLoader 类加载器来加载的

正由于是此父子结构，因此默认状况下若是要加载一个类，会优先将此类交给其父类进行加载（直到顶层的BootstrapClassLoader 也没有），若是父类都没有，那么才会将此类交给子类加载。这就是类加载器的双亲委派规则。ide

初始化

当咱们要使用一个类的执行方法或者属性时，类必须是加载到内存中而且完成初始化的。那么类是何时被初始化的呢？有如下几种状况优化

使用new关键字实例化对象的时候、读取或者设置一个类的静态字段、以及调用一个类的静态方法。
使用java.lang.reflect包的方法对类进行反射调用时，若是类没有进行初始化，那么先进行初始化。
初始化一个类的时候，若是发现其父类没有进行初始化，则先触发父类的初始化。
当虚拟机启动时，用户须要制定一个执行的主类(包含main()方法的那个类)虚拟机会先初始化这个主类。

如何实现热加载？

在上面咱们知道了在默认状况下，类加载器是遵循双亲委派规则的。因此咱们要实现热加载，那么咱们须要加载的那些类就不能交给系统加载器来完成。因此咱们要自定义类加载器来写咱们本身的规则。this

实现本身的类加载器

要想实现本身的类加载器，只须要继承ClassLoader类便可。而咱们要打破双亲委派规则，那么咱们就必需要重写loadClass方法，由于默认状况下loadClass方法是遵循双亲委派的规则的。spa

public class CustomClassLoader extends ClassLoader{

    private static final String CLASS_FILE_SUFFIX = ".class";

    //AppClassLoader的父类加载器
    private ClassLoader extClassLoader;

    public CustomClassLoader(){
        ClassLoader j = String.class.getClassLoader();
        if (j == null) {
            j = getSystemClassLoader();
            while (j.getParent() != null) {
                j = j.getParent();
            }
        }
        this.extClassLoader = j ;
    }

    protected Class<?> loadClass(String name, boolean resolve){

        Class cls = null;
        cls = findLoadedClass(name);
        if (cls != null){
            return cls;
        }
        //获取ExtClassLoader
        ClassLoader extClassLoader = getExtClassLoader() ;
        //确保自定义的类不会覆盖Java的核心类
        try {
            cls = extClassLoader.loadClass(name);
            if (cls != null){
                return cls;
            }
        }catch (ClassNotFoundException e ){

        }
        cls = findClass(name);
        return cls;
    }

    @Override
    public Class<?> findClass(String name) {
        byte[] bt = loadClassData(name);
        return defineClass(name, bt, 0, bt.length);
    }

    private byte[] loadClassData(String className) {
        // 读取Class文件呢
        InputStream is = getClass().getClassLoader().getResourceAsStream(className.replace(".", "/")+CLASS_FILE_SUFFIX);
        ByteArrayOutputStream byteSt = new ByteArrayOutputStream();
        // 写入byteStream
        int len =0;
        try {
            while((len=is.read())!=-1){
                byteSt.write(len);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        // 转换为数组
        return byteSt.toByteArray();
    }

    public ClassLoader getExtClassLoader(){
        return extClassLoader;
    }
}

为何要先获取ExtClassLoader类加载器呢？其实这里是借鉴了Tomcat里面的设计，是为了不咱们自定义的类加载器覆盖了一些核心类。例如java.lang.Object。设计

为何是获取ExtClassLoader 类加载器而不是获取AppClassLoader 呢？这是由于若是咱们获取了AppClassLoader 进行加载，那么不仍是双亲委派的规则了吗？code

监控class文件

这里咱们使用ScheduledThreadPoolExecutor 来进行周期性的监控文件是否修改。在程序启动的时候记录文件的最后修改时间。随后周期性的查看文件的最后修改时间是否改动。若是改动了那么就从新生成类加载器进行替换。这样新的文件就被加载进内存中了。

首先咱们创建一个须要监控的文件

public class Test {

    public void test(){
        System.out.println("Hello World! Version one");
    }
}

咱们经过在程序运行时修改版本号，来动态的输出版本号。接下来咱们创建周期性执行的任务类。

public class WatchDog implements Runnable{

    private Map<String,FileDefine> fileDefineMap;

    public WatchDog(Map<String,FileDefine> fileDefineMap){
        this.fileDefineMap = fileDefineMap;
    }

    @Override
    public void run() {
        File file = new File(FileDefine.WATCH_PACKAGE);
        File[] files = file.listFiles();
        for (File watchFile : files){
            long newTime = watchFile.lastModified();
            FileDefine fileDefine = fileDefineMap.get(watchFile.getName());
            long oldTime = fileDefine.getLastDefine();
            //若是文件被修改了,那么从新生成累加载器加载新文件
            if (newTime!=oldTime){
                fileDefine.setLastDefine(newTime);
                loadMyClass();
            }
        }
    }

    public void loadMyClass(){
        try {
            CustomClassLoader customClassLoader = new CustomClassLoader();
            Class<?> cls = customClassLoader.loadClass("com.example.watchfile.Test",false);
            Object test = cls.newInstance();
            Method method = cls.getMethod("test");
            method.invoke(test);
        }catch (Exception e){
            System.out.println(e);
        }
    }
}

能够看到在上面的gif演示图中咱们简单的实现了热加载的功能。

优化

在上面的方法调用中咱们是使用了getMethod()方法来调用的。此时或许会有疑问，为何不直接将newInstance()强转为Test类呢？

若是咱们使用了强转的话，代码会变成这样Test test = (Test) cls.newInstance()。可是在运行的时候会抛ClassCastException 异常。这是为何呢？由于在Java中肯定两个类是否相等，除了看他们两个类文件是否相同之外还会看他们的类加载器是否相同。因此即便是同一个类文件，若是是两个不一样的类加载器来加载的，那么它们的类型就是不一样的。

WatchDog类是由咱们new出来的。因此默认是AppClassLoader 来加载的。因此test 变量的声明类型是WatchDog 方法中的一个属性，因此也是由AppClassLoader 来加载的。所以两个类不相同。

该如何解决呢？问题就出在了=号双方的类不同，那么咱们给它搞成同样不就好了吗？怎么搞？答案就是接口。默认状况下，若是咱们实现了一个接口，那么此接口通常都是以子类的加载器为主的。意思就是若是没有特殊要求的话，例如A implements B 若是A的加载器是自定义的。那么B接口的加载器也是和子类是同样的。

因此咱们要将接口的类加载器搞成是AppClassLoader 来加载。因此自定义加载器中加入这一句

if ("com.example.watchfile.ITest".equals(name)){
    try {
        cls = getSystemClassLoader().loadClass(name);
    } catch (ClassNotFoundException e) {

    }
    return cls;
}

创建接口

public interface ITest {

    void test();
}

这样咱们就能愉快的调用了。直接调用其方法。不会抛异常，由于=号双方的类是同样的。

CustomClassLoader customClassLoader = new CustomClassLoader();
Class<?> cls = customClassLoader.loadClass("com.example.watchfile.Test",false);
ITest test = (ITest) cls.newInstance();
test.test();

[源代码地址Github]()

参考文章

https://www.ibm.com/developerworks/cn/java/j-lo-hotswapcls/index.html
[Java虚拟机]()