自定义ClassLoader

2020-05-28 16:03:39来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

自定义ClassLoader

简单地纯粹地记录下如何进行自定义一个自己的ClassLoader

什么双亲委派模型啊,双亲委派模型的破坏啊,好处啊,缺点啊什么的,一概不说。

自定义ClassLoader的博客啥的,看过不少,但是就是没自己亲手写一下,今天尝试写一下,发现古人诚不欺我!

纸上得来终觉浅,绝知此事要躬行

失败版本

最开始是这么写的

public class MyClassLoader extends ClassLoader {

    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/");
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

这里错误比较多,不过还是记住了一个,我是重写了findClass方法,而不是重写了loadClass方法,推荐也是通过重写findClass方法,以前是重写loadClass方法的方式。

即使是错误的,但是写之前还是绞尽脑汁的想了好久,试图把记忆中那点破碎的,分崩离析而又即将消失的关于自定义ClassLoader的记忆,给重新恢复了。可惜的是,我并不具体这个能力,凭着那点仅存的记忆,写下我的第一个自定义ClassLoader,很遗憾它是错误的。

写完后,就去测试跑了下,发现并没有出现我期许的结果 。

这里说下期许的结果是什么

  1. 加载class文件后生成的Class对象,调用其getClassLoader方法,应该是输出MyClassLoader
  2. Class对象和使用系统类加载器加载的同一个class代表的Class对象,并不相等,==会返回false
  3. 自定义类加载器加载的对象,是没办法强转成系统类加载器加载的Class类型。

然后,没有一个结果符合预期的。

看到输出的ClassLoader还是AppClassLoader,很奇怪,我明明自定义了类加载还去加载了啊!

最终发现,直接继承ClassLoader时,使用默认的无参构造

protected ClassLoader() {
    this(checkCreateClassLoader(), getSystemClassLoader());
}

默认情况下,继承自ClassLoader的子类,会拥有一个父类加载,就是 AppClassLoader,而 要加载的类 ,发现已经被父类加载器加载过了,所以实际上并没有子类的findClass方法

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    // 同步,保证加载的安全性
    synchronized (getClassLoadingLock(name)) {
        // 检查是否已经被加载了
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // 存在父加载器,先委托给父加载器,双亲委派模型的体现 
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                  	// 不存在父加载器,使用启动类加载器去加载 
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
            }
	    // 如果以上都找不到,就使用下面的逻辑去查找 
            if (c == null) {
                long t1 = System.nanoTime();
                // 这个就是各个子类来实现的了
                c = findClass(name);

                // 一些信息记录,记录到虚拟机里
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
      	// 上面仅仅完成了一个加载class的动作,但是整个类的加载并没有完成
        // 如果需要解析,则会对Class对象进行解析,这个名字有误导性,其实这是类加载阶段的链接阶段 
        // 也就是 验证 准备 解析三个阶段
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

所以问题就很明了了,

第一次修改后的版本

public class MyClassLoader extends ClassLoader {
    public MyClassLoader () {
      // 不使用系统类加载器作为此类加载的父加载器
      // 这样它的父加载器就是启动类加载器
      super(null);
    }
    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/");
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

这个一跑,也是完蛋,不过好解决。

一般调用loadClass方法时,传的都是包名,这里是要去加载字节码的,也就是找class文件,所以要转换成具体的路径,这里的路径使用的是相对路径,类位于classpath目录下,所以直接使用ClassLoader#getResourceAsStream就可以获取class文件的字节流`了。

这里实现的字节码来源是从文件系统加载的class文件,实际上任何符合Java虚拟机规范的Class结构的字节数组,都可以被加载进来,动态代理就是在运行时生成字节码,然后直接加载的。

可运行版本

public class MyClassLoader extends ClassLoader {

    public MyClassLoader () {
        super(null);

    }

    @Override
    protected Class findClass (String name) throws ClassNotFoundException {

        String classPath = name.replace(".", "/")+".class";
        InputStream classInputStream = getSystemClassLoader().getResourceAsStream(classPath);
        try {
            byte[] classBytes = new byte[classInputStream.available()];
            classInputStream.read(classBytes);
            Class clazz = defineClass(name, classBytes, 0, classBytes.length);
            resolveClass(clazz);
            return clazz;
        } catch (IOException e) {
            throw new ClassNotFoundException();
        }

    }
}

这就是一个麻雀虽小五脏俱全的自定义类加载器了。

两个重要知识点

就想到这俩,肯定不止俩

同一个类的Class对象在同一个虚拟机进程中,可以存在多个实例,在虚拟机中,是根据Class所属的类加载器,来确定唯一一个Class

Hotspot虚拟机在进行类加载时,采用了类似的TLAB的方式,会给每个类加载器分配一块内存,这样这个类加载器加载的类,直接在这里分配,提高效率,也便于管理,不过遇到有很多类加载的话,会出现OOM的可能,原因就是每个类加载器分配一块,多整一些 ,空间不够了,OOM

TLAB(Thread Local Allocate Buffer),目的是提升性能的,每一个线程在新生代的Eden区都有一个自己的一亩三分地,这样在分配内存时,不需要加锁做同步,提升分配的效率。


原文链接:https://www.cnblogs.com/heartlake/p/12980009.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:程序员发面试短信,HR十天后才回复信息还被拒:你算什么东西?

下一篇:引入mybatis-plus报 Invalid bound statement错误怎么办,动动手