如何手写一个Java类（热）加载器
目录
一、什么是类加载？
从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。
启动类加载器（Bootstrap ClassLoader）： 负责加载存放在 <JAVA_HOME>\lib 目录中的核心类库，如rt.jar、resources.jar等（或者被 -Xbootclasspath 参数所指定的路径中的，并且是虚拟机识别的类库）。这个加载器是 C++ 编写的，随着JVM启动。
扩展类加载器（Extension ClassLoader）： 负责加载<JAVA_HOME>\lib\ext 目录中的类库，（同样也可以用 java.ext.dirs 系统变量来指定路径）。
应用程序类加载器（Application ClassLoader）： 负责加载用户类路径 classpath 上所有的 jar 包和 .class 文件。
自定义类加载器： 可以支持一些个性化的扩展功能。
二、类加载过程
1.加载
加载指的是将类的class文件读入到内存，并为之创建一个java.lang.Class对象，也就是说，当程序中使用任何类时，系统都会为之建立一个java.lang.Class对象。
类的加载由类加载器完成，类加载器通常由JVM提供，这些类加载器也是前面所有程序运行的基础，JVM提供的这些类加载器通常被称为系统类加载器。除此之外，开发者可以通过继承ClassLoader基类来创建自己的类加载器。
通过使用不同的类加载器，可以从不同来源加载类的二进制数据，通常有如下几种来源。
- 从本地文件系统加载class文件，这是前面绝大部分示例程序的类加载方式。
- 从JAR包加载class文件，这种方式也是很常见的，JDBC编程时用到的数据库驱动类就放在JAR文件中，JVM可以从JAR文件中直接加载该class文件。
- 通过网络加载class文件。
- 把一个Java源文件动态编译，并执行加载。
类加载器通常无须等到“首次使用”该类时才加载该类，Java虚拟机规范允许系统预先加载某些类。
总结：
①通过一个类的全限定名（或其他方式）来获取定义此类的二进制字节流。
②将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
③在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
2.链接
当类被加载之后，JVM内存为之生成一个对应的Class对象，接着将会进入连接阶段，连接阶段负责把类的二进制数据合并到JRE中。类连接又可分为如下3个阶段。
(1)验证：验证阶段用于检验被加载的类是否有正确的内部结构，并和其他类协调一致。确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。
Java是相对C++语言是安全的语言，例如它有C++不具有的数组越界的检查。这本身就是对自身安全的一种保护。验证阶段是Java非常重要的一个阶段，它会直接的保证应用是否会被恶意入侵的一道重要的防线，越是严谨的验证机制越安全。验证的目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，不会危害虚拟机自身安全。其主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证。
文件格式验证：主要验证字节流是否符合Class文件格式规范，并且能被当前的虚拟机加载处理。例如：主，次版本号是否在当前虚拟机处理的范围之内。常量池中是否有不被支持的常量类型。指向常量的中的索引值是否存在不存在的常量或不符合类型的常量。
元数据验证：对字节码描述的信息进行语义的分析，分析是否符合java的语言语法的规范。
字节码验证：最重要的验证环节，分析数据流和控制，确定语义是合法的，符合逻辑的。主要的针对元数据验证后对方法体的验证。保证类方法在运行时不会有危害出现。
符号引用验证：主要是针对符号引用转换为直接引用的时候，是会延伸到第三解析阶段，主要去确定访问类型等涉及到引用的情况，主要是要保证引用一定会被访问到，不会出现类等无法访问的问题。
(2)准备：类准备阶段负责为类的静态变量分配内存，并设置默认初始值。
在准备阶段，进行分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。
(3)解析：将类的二进制数据中的符号引用替换成直接引用。
说明一下：符号引用：符号引用是以一组符号来描述所引用的目标，符号可以是任何的字面形式的字面量，只要不会出现冲突能够定位到就行。布局和内存无关。直接引用：是指向目标的指针，偏移量或者能够直接定位的句柄。该引用是和内存中的布局有关的，并且一定加载进来的。
3.初始化
初始化是为类的静态变量赋予正确的初始值，准备阶段和初始化阶段看似有点矛盾，其实是不矛盾的，如果类中有语句：private static int a = 10，它的执行过程是这样的，首先字节码文件被加载到内存后，先进行链接的验证这一步骤，验证通过后准备阶段，给a分配内存，因为变量a是static的，所以此时a等于int类型的默认初始值0，即a=0,然后到解析（后面在说），到初始化这一步骤时，才把a的真正的值10赋给a,此时a=10。
三、类加载时机（什么时候触发类加载器）
- 创建类的实例，也就是new一个对象
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（Class.forName(“com.lyj.load”)）
- 初始化一个类的子类（会首先初始化子类的父类）
- JVM启动时标明的启动类，即文件名和类名相同的那个类
除此之外，下面情形需要特别指出：
对于一个final类型的静态变量，如果该变量的值在编译时就可以确定下来，那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值，因此即使程序使用该静态变量，也不会导致该类的初始化。反之，如果final类型的静态Field的值不能在编译时确定下来，则必须等到运行时才可以确定该变量的值，如果通过该类来访问它的静态变量，则会导致该类被初始化。
四、如何实现热加载？
1、先介绍下类的加载机制
（1）JVM的类加载机制主要有如下3种
- 全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
- 双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
- 缓存机制。缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为什么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。
（2）双亲委派模型
为了避免类的重复加载，确保一个类的全局唯一性，以及保护程序安全，防止核心API被随意篡改，JVM会采用双亲委派模型进行加载，双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。
双亲委派机制： 其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，当⽗类加载器为null时，会使⽤启动类加载器 BootstrapClassLoader 作为⽗类加载器。这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己才想办法去完成。
双亲委派机制的优势： 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。
如何打破双亲委派模型：
打破双亲委派模型
方法1：自定义类加载器，重写ClassLoader类中的loadClass()方法；
方法2：使用线程上下文类加载器 Thread Context ClassLoader
如果不想打破双亲委派模型，就重写ClassLoader类中的findClass()方法即可。
2、实现热加载
在上面我们知道了在默认情况下，类加载器是遵循双亲委派规则的。所以我们要实现热加载，那么我们需要加载的那些类就不能交给系统加载器来完成。所以我们要自定义类加载器来写我们自己的规则
实现自己的类加载器
要想实现自己的类加载器，只需要继承ClassLoader类即可。而我们要打破双亲委派规则，那么我们就必须要重写loadClass方法，因为默认情况下loadClass方法是遵循双亲委派的规则的。
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进行加载，那么不还是双亲委派的规则了吗？
监控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);
}
}
}
效果图：
可以看到在上面的演示图中我们简单的实现了热加载的功能。
优化
在上面的方法调用中我们是使用了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();