彻底理解JVM类加载机制

文章目录

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

图片来源：图灵学院

由上图可知，创建对象，执行其中的方法，在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)：

java 复制代码

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 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;
    }
}

第一次加载某个自定义类时的流程：

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

1.3、自定义类加载器

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

java 复制代码

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，其中会把自定义类加载器的父加载器设置为应用程序类加载器AppClassLoader
        MyClassLoader 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方法：

java 复制代码

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class<?> 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();
            //让父类去加载Object
            if (!name.startsWith("com.itbaima.jvm")) {
                c = this.getParent().loadClass(name);
            }else {
                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;
    }

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

java 复制代码

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

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

二、类的加载

类的加载，通过loadClass方法，会经历验证、准备、解析、初始化四个阶段：

验证阶段：主要是校验class文件是否符合规范，以及对正确性进行校验，最经典的是cafe babe模数校验。
准备阶段：给类的静态属性分配内存，并且赋初值(基本数据类型为默认值，引用类型为null)。
解析阶段：将符号引用转变为直接引用，符号引用简单可以理解为类中的方法名，变量名等。而直接引用，是符号引用真正指向的内存地址。
初始化：在这一步才是给类的静态属性赋值，并且执行静态代码块。

静态代码块的执行先于构造方法：