十九、ClassLoader与双亲委派机制的补充

一、概述

1、说明

本篇是对《类加载子系统》的补充。

2、ClassLoader的作用

ClassLoader是Java的核心组件，所有的Class都是由ClassLoader进行加载的，ClassLoader负责通过各种方式将Class信息的二进制数据流读入JVM内部，转换为一个与目标类对应的java.lang.Class对象实例。然后交给Java虚拟机进行链接、初始化等操作。因此，ClassLoader在整个装载阶段，只能影响到类的加载，而无法通过ClassLoader去改变类的链接和初始化行为。至于它是否可以运行，则由Execution Engine决定。

3、类加载分类

1、类的加载分类：显式加载和隐式加载。

2、Class文件的显式加载与隐式加载的方式是指JVM加载Class文件到内存的方式

• 显式加载指的是在代码中通过调用ClassLoader加载Class对象，如直接使用Class.forName(name)或this.getClass().getClassLoader().loadClass()加载Class对象。

• 隐式加载则是不直接在代码中调用ClassLoader的方法加载Class对象，而是通过虚拟机自动加载到内存中，如在加载某个类的Class文件时，该类的Class文件中引用了另外一个类的对象，此时额外引用的类将通过JVM自动加载到内存中。

/**
 * @Date: 2022/1/2
 * 隐式加载与显式加载
 */
public class ClassLoaderTest {
    public static void main(String[] args) {
        User user = new User();//隐式加载

        try {
            Class clazz1 = Class.forName("com.itan.middle.day5.User");//显示加载
            Class clazz2 = ClassLoader.getSystemClassLoader().loadClass("com.itan.middle.day5.User");//显示加载
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

class User {
    private int num;
}

4、类的唯一性与命名空间

1、对于任意一个类，都需要由加载它的类加载器和这个类本身一同确认其在Java虚拟机中的唯一性。每一个类加载器，都拥有一个独立的类名称空间：比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义。否则，即使这两个类源自同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。

2、命名空间

• 每个类加载器都有自己的命名空间，命名空间由该加载器以及所有的父加载器所加载的类组成。

• 在同一命名空间中，不会出现类的完整名字（包括类的包名）相同的两个类。

• 在不同的命名空间中，有可能会出现类的完整名字（包括类的包名）相同的两个类。

3、在大型应用中，往往借助这一特性，来运行同一个类的不同版本。

5、类加载机制的基本特征

1、双亲委派模型。但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现。例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。

2、 可见性，子类加载器可以访问父加载器加载的类型，但是反过来是不允许的。不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。

3、单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。但是注意，类加载器"邻居"间，同一类型仍然可以被加载多次，因为相互并不可见。

6、数组类的Class说明

对于数组类的Class对象，不是由类加载器去创建的，而是在Java运行期JVM根据需要自动创建的。对于数组类的类加载器来说，是通过Class.geetClassLoader()返回的，与数组当中元素类型的类加载器是一样的；如果数组当中的元素类型是基本数据类型，数组类是没有类加载器的。

/**
 * @Date: 2022/1/3
 * 对于数组类型的加载，使用的类的加载器与数组元素的类的加载器相同
 */
public class ClassLoaderTest1 {
    public static void main(String[] args) {
        //String类是由引导类加载器进行加载的
        String [] strArr = new String[10];
        System.out.println(strArr.getClass().getClassLoader());//null，表示使用的是引导类加载器

        //自定义的类默认使用系统类加载器
        ClassLoaderTest1[] classArr = new ClassLoaderTest1[10];
        System.out.println(classArr.getClass().getClassLoader());//sun.misc.Launcher$AppClassLoader@18b4aac2

        //对于基本数据类型的数组，数组类是没有类加载器的
        int [] intArr = new int[10];
        System.out.println(intArr.getClass().getClassLoader());
    }
}

二、ClassLoader源码分析

1、ClassLoader与Launcher的初步分析

1、首先看一张图，ClassLoader与现有类加载器的关系，除了以下虚拟机自带的加载器外，用户还可以定制自己的类加载器。Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

2、ClassLoader类上的几点重要说明：

• 类加载器是负责加载类的对象。 ClassLoader类是一个抽象类。 给定类的二进制名称，类加载器应该尝试定位或生成构成类定义的数据。 典型的策略是将名称转换为文件名，然后从文件系统中读取该名称的“类文件”。

• 数组类的类对象不是由类加载器创建的，而是根据Java运行时的需要自动创建的。Class.getClassLoader()返回的数组类的类加载器与其元素类型的类加载器相同； 如果元素类型是原始类型，则数组类没有类加载器。

• ClassLoader类使用委托模型来搜索类和资源。 ClassLoader的每个实例都有一个关联的父类加载器。当请求查找类或资源时，ClassLoader实例会将类或资源的搜索委托给其父类加载器，然后再尝试查找类或资源本身。虚拟机的内置类加载器，称为“引导类加载器”，它本身没有父级，但可以作为ClassLoader实例的父级。

3、getClassLoader()方法的说明：

4、ExtClassLoader与AppClassLoader是在Launcher类的构造器中创建的。

2、ClassLoader的主要方法

1、public final ClassLoader getParent()：返回该类加载器的父类加载器。

2、public Class loadClass(String name) throws ClassNotFoundException：加载名称为name的类，返回结果为java.lang.Class类的实例。如果找不到类，则抛出ClassNotFoundException异常。该方法中的逻辑就是双亲委派模式的实现。loadClass方法的具体代码如下：

//测试代码，涉及到对loadClass方法的调用
ClassLoader.getSystemClassLoader().loadClass("com.itan.middle.day5.User");

public Class<?> loadClass(String name) throws ClassNotFoundException {
    return loadClass(name, false);
}

/**
 * 加载具有指定二进制名称的类。 此方法的默认实现按以下顺序搜索类：
 * 1、调用findLoadedClass(String)来检查类是否已经加载。
 * 2、在父类加载器上调用loadClass方法。 如果parent为null ，则使用虚拟机内置的类加载器。
 * 3、调用findClass(String)方法来查找类。
 * 如果使用上述步骤找到了该类，并且解析标志为真，则此方法将在生成的Class对象上调用resolveClass(Class)方法。
 * 鼓励ClassLoader的子类覆盖findClass(String) ，而不是这个方法。
 * 除非被覆盖，否则在整个类加载过程中，此方法会同步getClassLoadingLock方法的结果。
 * 参数：name - 类的二进制名称
 * 		resolve - 如果为true，则解析类
 * 返回：生成的Class对象
 * 抛出：ClassNotFoundException – 如果找不到类
 */
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 {
                    //当parent为null，也就是父类加载器是引导类加载器
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }
			//当前类的加载器的父类加载器未加载要加载的类或者当前类的加载器未加载要加载的类
            if (c == null) {
                long t1 = System.nanoTime();
                //调用当前ClassLoader的findClass方法
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        //是否需要进行解析操作
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

3、protected Class findClass(String name) throws ClassNotFoundException：查找二进制名称为name的类，返回结果为java.lang.Class类的实例。这是一个受保护的方法，JVM鼓励我们重写此方法，需要自定义加载器遵循双亲委托机制，该方法会在检查完父类加载器之后被loadClass方法调用。

• 在JDK1.2之前，在自定义类加载时，总会去继承ClassLoader类并重写loadClass方法，从而实现自定义的类加载器。但是在JDK1.2之后已不再建议用户去覆盖loadClass方法，而是建议把自定义的类加载逻辑写在findClass方法中，从前面的分析可知，findClass方法是在loadClass方法中被调用的，当loadClass方法中父加载器加载失败后，则会调用自己的findClass方法来完成类加载，这样就可以保证自定义的类加载器也符合双亲委托模式。

• 需要注意的是ClassLoader类中并没有实现findClass方法的具体代码逻辑，取而代之的是抛出ClassNotFoundException异常，同时应该知道的是findClass方法通常是和defineClass方法一起使用的。一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass方法生成类的Class对象。

4、protected final Class defineClass(byte[] b, int off, int len)：根据给定的字节数组b转换为Class的实例，off和len参数表示实际Class信息在byte数组中的位置和长度，其中byte数组b是ClassLoader从外部获取的。这是受保护的方法，只有在自定义ClassLoader子类中可以使用。

• defineClass方法是用来将byte字节流解析成JVM能够识别的Class对象（ClassLoader中已实现该方法逻辑），通过这个方法不仅能够通过Class文件实例化Class对象，也可以通过其他方式实例化Class对象，如通过网络接收一个类的字节码，然后转换为byte字节流创建对应的Class对象。

• defineClass方法通常与findClass方法一起使用，一般情况下，在自定义类加载器时，会直接覆盖ClassLoader的findClass方法并编写加载规则，取得要加载类的字节码后转换成流，然后调用defineClass方法生成类的Class对象。

5、protected final void resolveClass(Class c)：链接指定的一个Java类。使用该方法可以使用类的Class对象创建完成的同时也被解析（即加载的同时也进行解析）。链接阶段主要是对字节码进行验证，为类变量分配内存并设置初始值同时将字节码文件中的符号引用转换为直接引用。

6、protected final Class findLoadedClass(String name)：查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例。这个方法是final方法，无法被修改。

7、private final ClassLoader parent：它也是一个ClassLoader的实例，这个字段所表示的ClassLoader也称为这个ClassLoader的双亲。在类加载的过程中，ClassLoader可能会将某些请求交予自己的双亲处理。

3、SecureClassLoader与URLClassLoader两个子类

1、SecureClassLoader扩展了ClassLoader，新增了几个与使用相关的代码源（对代码源的位置及其证书的验证）和权限定义类验证（主要指对class源码的访问权限）的方法，一般不会直接跟这个类打交道，更多是与它的子类URLClassLoader有所关联。

2、ClassLoader是一个抽象类，很多方法是空的没有实现，比如findClass()、findResource()等。而URLClassLoader这个实现类为这些方法提供了具体的实现。并新增了URLClassPath类协助取得Class字节码流等功能。在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

4、ExtClassLoader与AppClassLoader两个子类

1、这两个类都继承自URLClassLoader，是sun.misc.Launcher的静态内部类。

2、sun.misc.Launcher主要被系统用于启动主应用程序，ExtClassLoader和AppClassLoader都是由sun.misc.Launcher创建的，其类主要类结构如下：

3、可以看到ExtClassLoader并没有重写loadClass()方法，这足以说明其遵循双亲委派模式，而AppClassLoader重载了loadclass()方法，但最终调用的还是父类loadClass()方法，因此依然遵守双亲委派模式。

三、双亲委派机制

1、概述

1、类加载器用来把类加载到Java虚拟机中。从JDK1.2版本开始，类的加载过程采用双亲委派机制，这种机制能更好地保证Java平台的安全。

2、定义：如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

3、本质：规定了类加载的顺序是引导类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。

2、双亲委派的优势

1、避免类的重复加载，确保一个类的全局唯一性。Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关系可以避免类的重复加载，当父类已经加载了该类时，就没有必要子ClassLoader再加载一次。

2、保护程序安全，防止核心API被随意篡改。

• 比如自定义一个java.lang.String类，在使用的时候就会有如下提示。

3、双亲委派机制在代码中的体现

1、双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)方法中（第2、3步操作）体现。逻辑如下：

1. 先在当前加载器的缓存中查找有无目标类，如果有，直接返回。

2. 判断当前加载器的父加载器是否为空，如果不为空，则调用parent.loadClass(name，false)方法进行加载。

3. 反之，如果当前加载器的父类加载器为空，则调用findBootstrapClassOrNull(name)方法，让引导类加载器进加载。

4. 如果通过以上3条路径都没能成功加载，则调用findClass(name)方法进行加载。该接口最终会调用java.lang.ClassLoader接口的defineClass系列的native接口加载目标Java类。

2、举例说明：假设当前加载的是java.lang.Object这个类，很显然，该类属于JDK中核心得不能再核心的一个类，因此一定只能由引导类加载器进行加载。当JVM准备加载java.lang.Object时，JVM默认会使用系统类加载器去加载，按照上面4步加载的逻辑，在第1步从系统类的缓存中肯定查找不到该类，于是进入第2步。由于系统类加载器的父加载器是扩展类加载器，于是扩展类加载器继续从第1步开始重复。由于扩展类加载器的缓存中也一定查找不到该类，因此进入第2步。扩展类的父加载器是null，因此系统调用findClass(String)，最终通过引导类加载器进行加载。

3、补充说明：如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String, boolean)方法，抹去其中的双亲委派机制，仅保留上面这4步中的第1步与第4步，那么是不是就能够加载核心类库了呢？

• 答案是否定的！因为JDK还为核心类库提供了一层保护机制。不管是自定义的类加载器，还是系统类加载器还是扩展类加载器，最终都必须调用java.lang.classLoader.defineClass(String,byte[], int, int, ProtectionDomain)方法，而该方法会执行preDefineClass()方法，该方法中提供了对JDK核心类库的保护。

4、双亲委派机制的弊端

1、检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。

2、通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。

3、总结：由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而己。比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。

5、破坏双亲委派进制

1、双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者们的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，直到Java模块化出现为止，双亲委派模型主要出现过3次较大规模“被破坏”的情况。

2、双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前（即JDK1.2面世以前的“远古”时代）。由于双亲委派模型在JDK 1.2之后才被引入，但是类加载器的概念和抽象类java.lang.ClassLoader则在Java的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加一个新的protected方法findClass()，并引导用户编写的类加载逻辑时尽可能去重写这个方法，而不是在loadClass()中编写代码。双亲委派的具体逻辑就实现在loadClass()方法里面，按照loadClass()方法的逻辑，如果父类加载失败，会自动调用自己的findClass()方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

3、双亲委派模型的第二次“被破坏”是由这个模型自身的缺陷导致的，双亲委派很好地解决了各个类加载器协作时基础类型的一致性问题〈越基础的类由越上层的加载器进行加载），基础类型之所以被称为“基础”，是因为它们总是作为被用户代码继承、调用的API存在，但程序设计往往没有绝对不变的完美规则，如果有基础类型又要调用回用户的代码，那该怎么办呢？

• 一个典型的例子便是JNDI服务，JNDI现在已经是Java的标准服务，它的代码由启动类加载器来完成加载（在JDK1.3时加入到rt.jar的)，肯定属于Java中很基础的类型了。但JNDI存在的目的就是对资源进行查找和集中管理，它需要调用由其他厂商实现并部署在应用程序的ClassPath下的NDI服务提供者接口（Service Provider Interface，SPI）的代码，现在问题来了，启动类加载器是绝不可能认识、加载这些代码的，那该怎么办？（SPI：在Java平台中，通常把核心类rt.jar中提供外部服务、可由应用层自行实现的接口称为SPI）

• 为了解决这个困境，只好引入了一个不太优雅的设计：线程上下文类加载器（Thread ContextClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

4、双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：代码热替换（Hot Swap)、模块热部署（Hot Deployment）等。IBM公司主导的JSR-291(即OSGI R4.2）实现模块化热部署的关键是它自定义的类加载器机制的实现，每一个程序模块（OSGI中称为Bundle)都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器一起换掉以实现代码的热替换。在OSGI环境下，类加载器不再双亲委派模型推荐的树状结构，而是进一步发展为更加复杂的网状结构。当收到类加载请求时，OSGI将按照下面顺序进行类搜索。

• 将以java.*开头的类，委派给父类加载器加载。

• 否则，将委派列表名单内的类，委派给父类加载器加载。

• 否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。

• 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。

• 否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。

• 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。

• 否则，类查找失败。

• 说明：只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的。

6、热替换的实现

1、热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比如：PHP，只要替换了PHP源文件，这种改动就会立即生效，而无需重启Web服务器。

2、但对Java来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重新定义这个类。因此，在Java中实现这一功能的一个可行的方法就是灵活运用ClassLoader。

3、注意：由不同ClassLoader加载的同名类属于不同的类型，不能相互转换和兼容。即两个不同的ClassLoader加载同个类，在虚拟机内部，会认为这2个类是完全不同的。根据这个特点，可以用来模拟热替换的实现，基本思路如下图：

/**
 * @Date: 2022/1/4
 * 自定义类加载器
 */
public class CustomClassLoader extends ClassLoader {
    private String classPath;

    public CustomClassLoader(String classPath) {
        this.classPath = classPath;
    }

    public CustomClassLoader(ClassLoader parent, String classPath) {
        super(parent);
        this.classPath = classPath;
    }

    @Override
    protected Class<?> findClass(String className) throws ClassNotFoundException {
        //在缓存中判断是否已经加载同名的类
        Class<?> clazz = this.findLoadedClass(className);
        FileChannel fileChannel = null;
        WritableByteChannel outChannel = null;
        if (null == clazz) {
            try {
                String classFile = getClassFile(className);
                //获取一个输入流
                FileInputStream fis = new FileInputStream(classFile);
                fileChannel = fis.getChannel();
                //获取一个输出流
                ByteArrayOutputStream bos = new ByteArrayOutputStream();
                outChannel = Channels.newChannel(bos);
                ByteBuffer buffer = ByteBuffer.allocateDirect(1024);
                //具体读入数据并写出的过程
                while (true) {
                    int i = fileChannel.read(buffer);
                    if (i == 0 || i == -1) {
                        break;
                    }
                    buffer.flip();
                    outChannel.write(buffer);
                    buffer.clear();
                }
                //获取内存中的完整的字节数组的数据
                byte[] bytes = bos.toByteArray();
                //调用defineClass()，将字节数组的数据转换为Class的实例
                clazz = defineClass(className, bytes, 0, bytes.length);
            } catch (FileNotFoundException e) {
                e.printStackTrace();
            } catch (IOException e) {
                e.printStackTrace();
            } finally {
                try {
                    if (fileChannel != null) {
                        fileChannel.close();
                    }
                } catch (IOException e) {
                    e.printStackTrace();
                }
                try {
                    if (outChannel != null) {
                        outChannel.close();
                    }
                } catch (IOException e) {
                    e.printStackTrace();
                }
            }
        }
        return clazz;
    }

    /**
     * 类文件的完全路径
     * @param className
     * @return
     */
    private String getClassFile(String className) {
        return classPath + "\\" + className.replace('.', '\\') + ".class";
    }
}

/**
 * @Date: 2022/1/5
 * 测试自定义类加载器
 */
public class CustomClassLoaderTest {
    @Test
    public void test1() {
        while (true) {
            try {
                //创建自定义加载器的实例
                CustomClassLoader ccl = new CustomClassLoader("D:\\IdeaProbject\\JVM\\src\\main\\java\\");
                //加载指定的类
                Class<?> clazz = ccl.findClass("com.itan.middle.day5.Demo");
                //创建运行时类的实例
                Object demo = clazz.newInstance();
                //获取运行时类的方法
                Method method1 = clazz.getMethod("method1");
                method1.invoke(demo);
                System.out.println("加载此类的类的加载器为：" + clazz.getClassLoader().getClass().getName());
                System.out.println("加载当前Demo1类的类的加载器的父类加载器为：" + clazz.getClassLoader().getParent().getClass().getName());
                //每隔20s输出一次
                Thread.sleep(20000);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
}

/**
 * 先将文件编译，然后放到要测试的路径下吗，后面再次修改之后再编译放到测试路径下
 */
public class Demo {
    public void method1() {
        System.out.println("Demo中的method1方法");
        //修改之后的
        //System.out.println("Demo中的method1方法被修改过");
    }
}

1、将Demo编译，放到指定的测试路径下，运行测试类。

2、再将Demo中代码修改，并替换测试路径下的Class文件，观察控制台输出

四、自定义类加载器

1、为什么需要自定义加载器

1、隔离加载类

• 在某些框架内进行中间件与应用的模块隔离，把类加载到不同的环境。比如：某容器框架通过自定义类加载器确保应用中依赖的jar包不会影响到中间件运行时使用的jar包。再比如：Tomcat这类web应用服务器，内部自定义了好几种类加载器，用于隔离同一个web应用服务器上的不同应用程序。

2、修改类的加载方式

• 类的加载模型并非强制，除Bootstrap外，其他的加载并非一定要引入，或者根据实际情况在某个时间点进行按需进行动态加载。

3、扩展加载源

• 比如从数据库、网络、甚至是电视机机顶盒进行加载二进制数据。

4、防止源码泄露

• Java代码容易被编译和篡改，可以进行编译加密。那么类加载也需要自定义，还原加密的字节码。

2、常见应用场景

1、实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是Java EE和OSGI、JPMS等框架。

2、应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。或者是需要自己操纵字节码，动态修改或者生成类型。

3、注意：在一般情况下，使用不同的类加载器去加载不同的功能模块，会提高应用程序的安全性。但是，如果涉及Java类型转换，则加载器反而容易产生不美好的事情。在做Java类型转换时，只有两个类型都是由同一个加载器所加载，才能进行类型转换，否则转换时会发生异常。

3、自定义类加载器的实现方式

1、用户通过定制自己的类加载器，这样可以重新定义类的加载规则，以便实现一些自定义的处理逻辑。

2、实现方式

• Java提供了抽象类java.lang.ClassLoader，所有用户自定义的类加载器都应该继承ClassLoader类。

• 在自定义ClassLoader的子类时候，常见两种做法是：

  1. 方式一：重写loadClass方法

  2. 方式二：重写findClass()方法【推荐使用】

3、两种方式对比：

• 这两种方法本质上差不多，毕竟loadClass()也会调用findClass()，但是从逻辑上讲我们最好不要直接修改loadClass()的内部逻辑。建议的做法是只在findClass()里重写自定义类的加载方法，根据参数指定类的名字，返回对应的Class对象的引用。

• loadClass()这个方法是实现双亲委派模型逻辑的地方，擅自修改这个方法会导致模型被破坏，容易造成问题。因此我们最好是在双亲委派模型框架内进行小范围的改动，不破坏原有的稳定结构。同时，也避免了自己重写loadClass()方法的过程中必须写双亲委托的重复代码，从代码的复用性来看，不直接修改loadClass()方法始终是比较好的选择。

• 当编写好自定义类加载器后，便可以在程序中调用loadClass(方法来实现类加载操作。

4、说明：

• 自定义类加载的父类加载器是系统类加载器。

• JVM中的所有类加载都会使用java.lang.ClassLoader.loadClass(String)方法（自定义类加载器并重写java.lang.ClassLoader.loadClass(String)方法的除外），连JDK的核心类库也不能例外。

5、代码实现参考热替换中的代码