前面说了类加载器的双亲委派机制, 也知道了一个类是如何被类加载器加载进来的. 接下来. 我们来看一看如何自定义类加载器

对于类加载器, 我们知道他的重点是loadClass(...)方法, 里面的双亲委派机制也是在loadClass方法里面实现的. loadClass方法里面实际上去加载类的是findClass()方法. 对于我们自定义的类加载器来说需要做到两点即可

1. 这个自定义的类加载器继承自ClassLoader

2. 这个类加载器要重写ClassLoader类中的findClass()方法

下面我自己定义了一个类加载器

 第一步是继承ClassLoader类, 然后定义一个构造方法, 用来接收要加载的类名

 这里有两步操作,

第一个是: 从类路径中读取要加载类的文件内容, 自定义

第二个是: 调用构造类的方法, 调用的系统的defineClass

记下来来看看自定义的loadByte是如何实现的

 这里的实现就是找到类, 并且将类的内容读取出来, 转换成二进制的字节码, 返回

最后一部分就是如何调用了.

 用类加载器加载类, 然后实例化, 使用反射机制调用User1 的方法sout

package com.lxl.jvm;

public class User1 {
    public void sout() {
        System.out.println("进入到User1");
    }
}

这里面System.out.println(clazz.getClassLoader().getClass().getName()); 获取当前类的类加载器, 猜一猜这里打印的会是谁?

 看到了么? 是AppClassLoader, 为什么呢?

原因是我的项目里已经有一个类User1了

 我们自定义类加载器的父类是AppClassLoader. 而程序代码中的User1刚好是被AppClassLoader加载, 因为找到了,所以就不会再去我们指定的文件夹中查找了

这就是类的双亲委派机制的特点呀.

那么如果我们将项目中的User1类删除掉, 这是类加载器是谁呢? 当然就是我们自定义的类加载器了.

那么问题来了, 自定义类加载器的父类为什么是AppClassLoader呢?

二. 自定义类加载的父类为什么是appClassLoader?

我们来看一下源码

我们自定义的类加载器, 继承自ClassLoader类加载器, 那么在加载自定义类加载器之前, 应该先加载父类ClassLoader.

首先会执行ClassLoader的无参的构造方法.

 而无参的构造方法会调用自身的构造方法

 里面有一个parent, 我们就是要看看这个parent到底是谁. 也就是要看看getSystemClassLoader是谁?

 之前我们已经研究过getClassLoader()这个方法了, 这里面定义的loadClass是谁呢?就是AppClassLoader.

 这就是为什么自定义class类加载器的父类是AppClassLoader的原因了