彻底理解JVM类加载机制

文章目录

一、类加载器和双亲委派机制
- 1.1、类加载器
- 1.2、双亲委派机制
- 1.3、自定义类加载器
- 1.4、打破双亲委派机制
二、类的加载

java代码的执行流程 图片来源：图灵学院
由上图可知，创建对象，执行其中的方法，在java层面，最重要的有获取类加载器以及加载类两部分

一、类加载器和双亲委派机制

1.1、类加载器

在JVM中，类加载器分为：

启动类加载器：最核心的类加载器，用于加载JRE的lib目录下的核心类库。
扩展类加载器：负责加载位于JRE的lib目录下的ext扩展目录中的JAR类包。
应用程序类加载器：负责加载ClassPath路径下的类包。
自定义类加载器：用于加载用户自定义路径的类包。

sun.misc包下的Launcher类，会在构造方法中对类加载器进行初始化：
在这里插入图片描述构造方法中的关键部分：
sun.misc.Launcher.AppClassLoader#getAppClassLoader（获取应用程序类加载器方法）的最底层，将参数中传入的扩展类加载器，赋值给成员变量。
ExtClassLoader扩展类加载器继承自ClassLoader
在这里插入图片描述

1.2、双亲委派机制

双亲委派机制的核心是，向上委派，向下加载：
在这里插入图片描述即当加载某个类时，会从最底层的类加载器开始，逐个向上查找目标类，如果加载过，就直接返回。如果查找到最上层依旧没有，则从最上层自身负责的类加载路径中查找并加载。

自己写的一个User类，第一次运行，应用程序类加载器没有找到，向上查找扩展类、启动类加载器，依然没有找到。就从最顶层的启动类加载器开始，查看该类是否在自己的加载范围内。很显然自定义的类，不在启动类加载器的范围内，向下委派到扩展类加载器，发现依旧不在自身的范围内，就再次委派给应用程序类加载器，这次发现在自己的加载范围内，就会加载。
java.lang包下的String类，第一次运行，应用程序类加载器没有找到，向上查找扩展类、启动类加载器，依然没有找到。就从最顶层的启动类加载器开始，查看该类是否在自己的加载范围内。java.lang包下的String类属于核心类库，启动类加载器发现它在自己应该加载的范围内，就会进行加载。

双亲委派机制在源码中的体现在于java.lang.ClassLoader#loadClass(java.lang.String, boolean)：

protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException
{synchronized (getClassLoadingLock(name)) {//首先查看当前的类加载器是否加载过目标（底层是c/c++实现的方法）Class<?> c = findLoadedClass(name);//当前的类加载器没有加载过if (c == null) {long t0 = System.nanoTime();try {//扩展类加载器进行查找//这里的parent属性是当前类加载器的父加载器if (parent != null) {c = parent.loadClass(name, false);}//启动类加载器进行查找 else {c = findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}//都没有加载过if (c == null) {// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();//查看当前的类路径，判断是否应该是自己加载。c = findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;}
}

第一次加载某个自定义类时的流程：
应用程序类加载器发现自身没有加载过，去执行扩展类加载器的loadClass方法：
在这里插入图片描述扩展类加载器发现自身没有加载过，去找启动类加载器（底层由c/c++执行）启动类加载器返回的c为空，在扩展类加载器进入if判断，尝试自己加载，但是自定义的类不在自己的加载范围内，将null值的c返回到应用程序类加载器:
在这里插入图片描述应用程序类加载器得到扩展类加载器的返回为空，就尝试自己加载并且返回：

1.3、自定义类加载器

自定义类加载器，需要继承ClassLoader，并且重写其中的findClass，loadClass方法：

public class MyClassLoaderTest1 {static class MyClassLoader extends ClassLoader {private String classPath;public MyClassLoader(String classPath) {this.classPath = classPath;}private byte[] loadByte(String name) throws Exception {name = name.replaceAll("\\.", "/");FileInputStream fis = new FileInputStream(classPath + "/" + name+ ".class");int len = fis.available();byte[] data = new byte[len];fis.read(data);fis.close();return data;}protected Class<?> findClass(String name) throws ClassNotFoundException {try {byte[] data = loadByte(name);//defineClass将一个字节数组转为Class对象，这个字节数组是class文件读取后最终的字节数组。return defineClass(name, data, 0, data.length);} catch (Exception e) {e.printStackTrace();throw new ClassNotFoundException();}}}public static void main(String args[]) throws Exception {//初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoaderMyClassLoader classLoader = new MyClassLoader("D:/test");//D盘创建 test/com/tuling/jvm 几级目录，将User类的复制类User1.class丢入该目录Class clazz = classLoader.loadClass("com.itbaima.jvm.User");Object obj = clazz.newInstance();Method method = clazz.getDeclaredMethod("sout", null);method.invoke(obj, null);System.out.println(clazz.getClassLoader().getClass().getName());}
}

上面的自定义类加载器，目的是为了加载D盘test文件夹下的com.itbaima.jvm的User.class文件，假设目前的classpath下和D盘指定目录下都有该文件？
在这里插入图片描述
那么根据双亲委派机制，User类应该由应用程序类加载器，而非自定义类加载器加载。原因很简单，当User类被启动类加载器向下加载时，在应用程序类加载器这一层，发现属于自己的classpath范围内有这个类，就会进行加载。
在这里插入图片描述把classpath下的User类删除，则由自定义类加载器进行加载：

1.4、打破双亲委派机制

打破双亲委派机制的关键在于自定义实现loadClass方法。在1.3案例的基础上，继续重写loadClass方法：

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass<?> c = findLoadedClass(name);if (c == null) {long t0 = System.nanoTime();// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();//让父类去加载Objectif (!name.startsWith("com.itbaima.jvm")) {c = this.getParent().loadClass(name);}else {c = findClass(name);}// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}if (resolve) {resolveClass(c);}return c;}

在重写的loadClass方法中，去除了向上委派的逻辑，而是由自身进行加载，为什么还要加上

if (!name.startsWith("com.itbaima.jvm")) {c = this.getParent().loadClass(name);}

的判断？原因在于，用当前的类加载器去加载User类没有问题，但是User类继承了java.lang包下的Object类，如果把判断条件去除：
在这里插入图片描述如果把Object.class文件复制一份到指定的目录呢？
答案也是否定的，因为在类加载的过程中JVM还有自己的安全监测机制，是不会允许核心的类被自定义加载的。