文章目录

一、Java程序启动并运行的过程
二、类加载器
三、Java8内置的类加载器
- 1. AppClassLoader
- 2. ExtClassLoader
- 3. BootStrap ClassLoader
- 4. 3个类加载器之间的关系
四、双亲委派模型
五、关键类java.lang.ClassLoader
- 1. loadClass(..)
- 2. denfineClass(..)
- 3. findClass(..)
- 4. findVBootstrapClassOrNull(..)
- 5. getParent()
六、实现自定义ClassLoader
七、类加载器的特性
- 1. 唯一性
- 2. 传递性
- 3. 可见性
八、打破“双亲委派模型”
- 1. Java SPI机制打破双亲委派模型
- 2. 热加载/热部署打破双亲委派模型
- 3. 自定义热部署/热加载示例
九、数组类的本质
- 1. 数组类的加载
- 2. 与数组类相关联的类加载器

一、Java程序启动并运行的过程

JVM在启动时，首先会加载并初始化main方法所在的类，这个类被称为起始类initial class，接着JVM会调用并执行main方法，在执行main方法的过程中，可能会触发进一步的执行，继续加载其他的类并执行其他的方法，直到程序退出。
需要注意的是，在加载某个类或执行某个方法的时候，也可能会触发其他类的加载，可以看到Java程序从启动到运行，类的加载无处不在，起到了举足轻重的作用。而且，Java中的类加载都是在运行时动态完成的，这种动态加载的特性，也正是Java语言灵活性的根源。

在这里插入图片描述

二、类加载器

在Java中，所有的类加载都通过类加载器（ClassLoader）来完成，加载的过程大致如下：
首先使用Java代码或JVM触发一个加载动作，然后将类的全限定名传给类加载器，类加载器再通过类名获取到字节码的二进制流，这可以从本地硬盘读取类文件，也可以是从网络远程读取到类文件，甚至还可以在运行时动态生成字节码，最后再根据字节码二进制流创建加载对应的Class对象。

在这里插入图片描述

三、Java8内置的类加载器

为了更好的理解Java的类加载机制，先介绍几个Java8中内置的ClassLoader，先看一个代码片段，它的目的是打印出指定类的类加载器，从输出可以看到Java8中内置的三个ClassLoader，分别是AppClassLoader、ExtClassLoader、BootStrap ClassLoader。

package cn.memset.sample;

import com.sun.javafx.util.Logging;

import java.util.ArrayList;

/**
 * 打印 Java 8 中内置的 ClassLoader
 */
public class BuiltinClassLoaderTest {
    public static void main(String[] args) {
        System.out.println("类 BuiltinClassLoaderTest 的加载器是: "
                + BuiltinClassLoaderTest.class.getClassLoader());

        System.out.println("类 Logging 的加载器是: "
                + Logging.class.getClassLoader());

        System.out.println("类 ArrayList 的加载器是: "
                + ArrayList.class.getClassLoader());
    }
}

在这里插入图片描述

1. AppClassLoader

AppClassLoader即应用类加载器，是系统默认的类加载器，它负责加载当前Java应用classpath中的类，而classpath通常是通过java命令的参数 -cp 或 -classpath 来指定。可以通过属性"java.class.path"来获取具体的值。

在这里插入图片描述

2. ExtClassLoader

ExtClassLoader即扩展类加载器，负责加载扩展目录中的类，扩展目录通常是<JAVA_HOME>/lib/ext，可以通过属性"java.ext.dirs"来设置或获取具体的值。

在这里插入图片描述

3. BootStrap ClassLoader

BootStrap ClassLoader即启动类加载器，负责加载JDK中核心类库中的类。例如：Java8中<JAVA_HOME>/jre/lib中的rt.jar。
在JVM中，BootStrap ClassLoader通常是使用C/C++语言原生实现的，它不能表现为一个Java类，所以将它打印出来是null。

在这里插入图片描述

4. 3个类加载器之间的关系

从JVM角度来看，只有2种类加载器，一种是BootStrap ClassLoader，它通常是JVM中的一部分，使用C/C++语言原生实现的，而另一种则是用户定义的ClassLoader，包括了JDK中内置的ExtClassLoader、AppClassLoader以及用户自行实现的ClassLoader。用户定义的ClassLoader都使用Java语言实现，并且要求继承抽象类java.lang.ClassLoader。
BootStrap ClassLoader、ExtClassLoader、AppClassLoader三者之间并非继承关系，而是组合关系， AppClassLoader显示拥有一个parent加载器ExtCLassLoader，而ExtClassLoader的parent加载器则隐式指向BootStrap ClassLoader。

在这里插入图片描述

四、双亲委派模型

类加载的“双亲委派模型”展示了类加载器之间的协作方式。

在这里插入图片描述

如果一个类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个加载请求，委派给“父”类加载器去完成，而且每一个层次的类加载器都是如此。因此所有的加载请求，最终都应该被传送到最顶层的启动类加载器中。只有当“父”加载器反馈自己无法完成这个加载请求时，“子”加载器才会尝试继续加载，如果到最后也无法加载指定的类，那么就抛出异常ClassnotFoundException。

这样做的好处是，越顶层的类加载器，对其可见的类总是被优先加载。例如：java.lang.String存放在rt.jar中，即使自行定义了一个同名的类，并且将其放到了classpath中，但最终都是委派给处于最顶层的启动类加载器进行加载，即最终会加载rt.jar中的String类，而不是classpath中自行定义的String类，这样可以保证Java类型体系的稳定性。

反之，对于类app.ClassA，只有当上层的类加载器都找不到对应的类时，才会被用户自定义的类加载器加载。

双亲委派模型的实现源码：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
	  // 加锁，保证线程安全
      synchronized (getClassLoadingLock(name)) {
          // 首先，检查这个类是否被加载过。同一个类不能被重复加载。
          Class<?> c = findLoadedClass(name);
          if (c == null) {
              long t0 = System.nanoTime();
              try {
              	  // 如果parent不为空，那么委派给parent类加载器来尝试加载
                  if (parent != null) {
                      c = parent.loadClass(name, false);
                  } else {
                  	 // 如果parent为空，那么委派给BootStrap ClassLoader来尝试加载
                      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();
                   // 如果parent类加载器未能加载成功，那么就通过findclass方法进行加载
                  // 用户自定义的类加载器通常需要覆盖findclass方法
                  c = findClass(name);

                  // this is the defining class loader; record the stats
                  PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                  PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                  PerfCounter.getFindClasses().increment();
              }
          }
          // 类的解析
          if (resolve) {
              resolveClass(c);
          }
          return c;
      }
  }

五、关键类java.lang.ClassLoader

ClassLoader类是Java类加载机制中的核心类。在JVM规范中，规定了所有用户自行定义的类加载器都必须继承类ClassLoader。因此如果要自定义一个类加载器，首先需要彻底弄明白类ClassLoader中的关键方法。
ClassLoader类中的关键方法：

loadClass(…)
denfineClass(…)
findClass(…)
findVBootstrapClassOrNull(…)
getParent()

1. loadClass(…)

在这里插入图片描述

2. denfineClass(…)

在这里插入图片描述

3. findClass(…)

在这里插入图片描述

4. findVBootstrapClassOrNull(…)

在这里插入图片描述

5. getParent()

在这里插入图片描述

六、实现自定义ClassLoader

实现自定义ClassLoader，它遵循“双亲委派模型”，从任意指定的某个目录中读取字节码类文件，然后创建加载对应的类。

package cn.memset.sample.classloaders;

import java.io.*;

/**
 * 从任意指定的某个目录中读取字节码类文件，然后创建加载对应的类
 * 自定义的类加载器必须继承抽象类ClassLoader
 */
public class MyCommonClassLoader extends ClassLoader {

	// 静态初始化块
    static {
        // 表明当前的ClassLoader可并行加载不同的类
        registerAsParallelCapable();
    }

    /**
     * 指定的字节码类文件所在的本地目录
     */
    private final String commonPath;

    /**
     * 构造函数。默认的parent ClassLoader是 AppClassLoader
     *
     * @param commonPath 字节码类文件所在的本地目录
     */
    public MyCommonClassLoader(String commonPath) {
        if (!commonPath.isEmpty()
                && commonPath.charAt(commonPath.length() - 1) != File.separatorChar) {
            commonPath += File.separator;
        }
        this.commonPath = commonPath;
    }

    /**
     * 构造函数。指定了一个 parent ClassLoader 。
     *
     * @param commonPath 字节码类文件所在的本地目录
     * @param parent     指定的parent ClassLoader
     */
    public MyCommonClassLoader(String commonPath, ClassLoader parent) {
        super(parent);
        if (!commonPath.isEmpty()
                && commonPath.charAt(commonPath.length() - 1) != File.separatorChar) {
            commonPath += File.separator;
        }
        this.commonPath = commonPath;
    }

    /**
     * 覆盖父类的 findClass(..) 方法。
     * 从指定的目录中查找字节码类文件，并创建加载对应的Class对象。
     *
     * @param name
     * @return
     * @throws ClassNotFoundException
     */
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            // 读取字节码的二进制流
            byte[] b = loadClassFromFile(name);
            // 调用 defineClass(..) 方法创建 Class 对象
            Class<?> c = defineClass(name, b, 0, b.length);
            return c;
        } catch (IOException ex) {
            throw new ClassNotFoundException(name);
        }
    }

    private byte[] loadClassFromFile(String name) throws IOException {
        String fileName = name.replace('.', File.separatorChar) + ".class";
        String filePath = this.commonPath + fileName;

        try (InputStream inputStream = new FileInputStream(filePath);
             ByteArrayOutputStream byteStream = new ByteArrayOutputStream()
        ) {
            int nextValue;
            while ((nextValue = inputStream.read()) != -1) {
                byteStream.write(nextValue);
            }
            return byteStream.toByteArray();
        }
    }

    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // System.out.println("准备使用 MyCommonClassLoader 加载类：" + name);
        return super.loadClass(name, resolve);
    }
}

七、类加载器的特性

1. 唯一性

ClassLoader虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。它还是JVM中类命名空间的一部分，用来确定某个类的唯一性：假设某个类的全限定名是N，加载定义它的加载器是L，那么这个类的唯一性可以通过元组<N，L>来确定。通俗来说，即如果要比较两个类是否相等，除了要看类的全限定类名是否相等外，还需要看这两个类的类加载器是否是同一个。这里所说的相等，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，以及instanceof关键字所做的类型判定等情况。

在这里插入图片描述

package cn.memset.sample;

import cn.memset.sample.classloaders.MyCommonClassLoader;

/**
 * Java中类的唯一性（命名空间）
 */
public class ClassNamespaceTest {
    private final static String COMMON_PATH = "D:\\anyuanwai\\common-sdk";
    public static void main(String[] args) throws Exception {
        MyCommonClassLoader l1 = new MyCommonClassLoader(COMMON_PATH);
        MyCommonClassLoader l2 = new MyCommonClassLoader(COMMON_PATH);

        String className = "cn.memset.app.entities.Employee";
        Class<?> c1 = Class.forName(className, false, l1);
        Class<?> c2 = Class.forName(className, false, l2);
        Object o1 = c1.newInstance();

        System.out.println("c1类型是否等于c2类型？" + c1.equals(c2));
        System.out.println("对象o1是否是c2类型？" + (c2.isInstance(o1)));
    }
}

用两个不同的ClassLoader实例对象，来加载同一个类，得到的结果并不相等。

2. 传递性

**加粗样式**

测试类加载器的传递性，在之前自定义的类加载器MyCommonClassLoader中增加一行代码，打印将要被加载的类名

package cn.memset.sample.classloaders;

import java.io.*;

/**
 * 从任意指定的某个目录中读取字节码类文件，然后创建加载对应的类
 * 自定义的类加载器必须继承抽象类ClassLoader
 */
public class MyCommonClassLoader extends ClassLoader {

	...

    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    	// 增加一行代码，打印将要被加载的类名
        System.out.println("准备使用 MyCommonClassLoader 加载类：" + name);
        return super.loadClass(name, resolve);
    }
}

CompanyService 实现了Service接口，并且编译后得到的类文件会被拷贝到"D:\anyuanwai\common-sdk"的目录下，

package cn.memset.service.api;

public interface Service {
    void start();

    void stop();
}

package cn.memset.app;

import cn.memset.app.entities.Employee;
import cn.memset.app.entities.Manager;
import cn.memset.service.api.Service;

public class CompanyService implements Service {
    @Override
    public void start() {
        System.out.println("start Service[" + this + ']');
        Employee employee = new Employee("张三");
        Manager manager = new Manager("李四");

        String employeeStr = employee.toString().toLowerCase();
        String managerStr = manager.toString().toLowerCase();

        System.out.println("公司员工: " + employeeStr);
        System.out.println("公司经理: " + managerStr);
    }

    @Override
    public void stop() {
        System.out.println("stop Service[" + this + ']');
    }
}

package cn.memset.sample;

import cn.memset.sample.classloaders.MyCommonClassLoader;
import cn.memset.service.api.Service;

/**
 * 类加载器“传递性”的示例代码
 */
public class ClassLoaderTransTest {
    private final static String COMMON_PATH = "D:\\anyuanwai\\common-sdk";

    public static void main(String[] args) throws Exception {
        ClassLoader myLoader = new MyCommonClassLoader(COMMON_PATH);
        Class<?> serviceCls = Class.forName(
                "cn.memset.app.CompanyService",
                false,
                myLoader);

        Service service = (Service) serviceCls.newInstance();
        service.start();
    }
}

运行测试代码可以看到CompanyService类是通过我们自定义的类加载器MyCommonClassLoader加载的，那么MyCommonClassLoader中所依赖的Employee、Manager 类，也同样会通过同一个类加载器实例来进行加载，甚至CompanyService类中所依赖的JDK核心类库中的类或接口。例如：String、StringBuilder也同样会通过同一个类加载器进行加载。当然String、StringBuilder最终会被委派给BootStrap ClassLoader进行加载。

类的传递性非常重要，通过它，我们可以从某个入口类开始，不断使用相同类加载器展开加载同一个模块或应用中的其他类。整体来说，是以某种递归的形式逐步加载所需的类。

在这里插入图片描述

3. 可见性

例如：如果“类A”是通过AppClassLoader加载的，而“类B”是通过ExtClassLoader加载的，那么“类B”对于“类A”是可见的。反过来“类A”对于“类B”则是不可见的。拓展开来，对于AppClassLoader加载的其他类来说，“类A”和“类B”都是可见的。但是，对于ExtClassLoader加载的其他类，只有“类B”是可见的，而“类A”是不可见的。

八、打破“双亲委派模型”

在这里插入图片描述

双亲委派模型并非是强制性约束，它更多是推荐给开发者的一种类加载器的实现方式。在Java世界中，我们通常会遵循“双亲委派模型”，但有的时候，由于“双亲委派模型”自身的局限性，我们不得不主动去打破它。

1. Java SPI机制打破双亲委派模型

在这里插入图片描述

Java SPI机制中的核心类是ServiceLoader，它在java.util包中，很显然类ServiceLoader是BootStrap ClassLoader加载的，但ServiceLoader中需要去实例化部署在classpath中的第三方厂商的服务提供类Service Provider。根据类加载的“传递性”，类ServiceLoader所依赖的类都应该由BootStrap ClassLoader来进行加载，但很明显，BootStrap ClassLoader是无法加载那些位于classpath中的第三方厂商的Service Provider类。
为了解决这个问题，Java团队提供了一个不太优雅的设计，“线程上下文类加载器”。首先要说明的是，“线程上下文类加载器”并非是一个具体的类，而是类Thread中的一个成员属性，可以理解为Java设计团队找了一个地方（当前线程），把某个具体的ClassLoader存储起来，然后在需要的时候再取出来。通常我们可以通过Thread类中的setContextClassLoader()方法对其进行设置。如果创建线程时还未设置，它将从父线程中继承一个。如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用类加载器（APPClassLoader）。

在这里插入图片描述

有了“线程上下文类加载器”，我们就可以在Java SPI的ServiceLoader中使用“线程上下文类加载器” 去加载classpath中的第三方厂商类，这种行为实际上是打破了“双亲委派模型”中的层次结构。在BootStrap ClassLoader加载的类中，再反向调用APPClassLoader来加载第三方厂商类，逆转了类之间的可见性。

在这里插入图片描述

2. 热加载/热部署打破双亲委派模型

例如：Tomcat允许在不重启Tomcat进程的前提下，部署新的war包。其实，所有的热加载/热部署机制的原理都一样，都是基于Java的类加载器来实现的。类加载器的唯一性、传递性、可见性正是实现热加载/热部署的基础。

3. 自定义热部署/热加载示例

在这里插入图片描述

package cn.memset.sample;

import cn.memset.sample.classloaders.MyCommonClassLoader;
import cn.memset.service.api.Service;

import java.util.Scanner;

/**
 * 简单的热加载示例
 */
public class ReloadableApplication {
    /**
     * Service类型的全局变量
     */
    private static Service service;

    /**
     * 加载指定目录中的 Service
     */
    private static void loadService() throws Exception {
        // 首先创建一个全新的 ClassLoader 对象
        // 自定义的类加载器MyCompanyClassLoader
        ClassLoader myLoader = new MyCommonClassLoader(
                "D:\\anyuanwai\\common-sdk");
        // 调用 Class.forName 加载指定的 Service 类
        Class<?> serviceCls = Class.forName(
                "cn.memset.app.CompanyService",
                false,
                myLoader);

        if (service != null) {
            service.stop();
        }

        // 创建 Service 对象，然后运行它
        // 动态加载类CompanyService，实现了热加载
        service = (Service) serviceCls.newInstance();
        service.start();
    }

    public static void main(String[] args) throws Exception {
        loadService();

        Scanner scanner = new Scanner(System.in);
        while (true) {
            String command = scanner.nextLine();
            // 在控制台输入reload命令时，会使用loadService()方法完成热加载的动作
            // 在实际中，我们可以通过监听指定目录中的文件变化，进而自动触发热加载动作
            if ("reload".equalsIgnoreCase(command)) {
                // 重新加载服务
                // 在不停止当前进程的前提下，加载最新版本的类
                loadService();
            } else if ("exit".equalsIgnoreCase(command)) {
                // 停止服务
                if (service != null) {
                    service.stop();
                }
                break;
            } else {
                System.out.println(command);
            }
        }
    }
}

先编译项目，然后把编译得到的类文件拷贝到指定的目录中，接着启动ReloadableApplication

在这里插入图片描述

接着修改项目，加一行代码。编译后将最新版本的类文件拷贝到指定目录，然后在控制台输入reload命令，可以看到最新版本的CompanyService成功运行了。

在这里插入图片描述

九、数组类的本质

所有的数组示例都属于Object，每个数组示例都有对应的Class。
数组类继承了Object，同时也实现了接口Cloneable和Serializable

package cn.memset.sample;

/**
 * 数组类的本质
 */
public class ArrayTest {
    public static void main(String[] args) {
        int[] ia = new int[3];
        System.out.println("数组类: " + ia.getClass());
        System.out.println("数组类的父类: "
                + ia.getClass().getSuperclass());
        for (Class<?> c : ia.getClass().getInterfaces())
            System.out.println("数组类的父接口: " + c);
    }
}

在这里插入图片描述

1. 数组类的加载

数组类的加载是JVM直接创建的，有专门的JVM指令newarray

在这里插入图片描述

2. 与数组类相关联的类加载器

在这里插入图片描述

package cn.memset.sample;

import cn.memset.sample.classloaders.MyCommonClassLoader;
import com.sun.javafx.util.Logging;

import java.lang.reflect.Array;

/**
 * 数组类关联的类加载器
 */
public class ArrayClassLoaderTest {
    public static void main(String[] args) throws Exception {
        int[] ia = new int[0];
        System.out.println("int数组:" + ia.getClass().getClassLoader());

        String[] sa = new String[0];
        System.out.println("String数组:" + sa.getClass().getClassLoader());

        Logging[] la = new Logging[0];
        System.out.println("Logging数组:" + la.getClass().getClassLoader());

        ArrayClassLoaderTest[] aa = new ArrayClassLoaderTest[0];
        System.out.println("ArrayClassLoaderTest数组:" + aa.getClass().getClassLoader());

        ClassLoader myLoader = new MyCommonClassLoader("D:\\anyuanwai\\common-sdk");
        Class<?> serviceCls = Class.forName(
                "cn.memset.app.CompanyService",
                true,
                myLoader);

        Object[] oa = (Object[]) Array.newInstance(serviceCls, 0);
        System.out.println("CompanyService数组:" + oa.getClass().getClassLoader());
    }
}