【JVM类加载机制】深度剖析JVM类加载机制

深度剖析JVM类加载机制

- 前言
- 类加载运行全过程
- - loadClass的类加载过程
- 类加载器和双亲委派机制
- - 类加载器的类型
  - 类加载器的初始化过程
  - 双亲委派机制
  - 为什么要设置双亲委派机制？
  - 全盘负责委托机制
  - 自定义类加载器实例
  - 打破双亲委派机制
  - Tomcat打破双亲委派机制
  - Tomcat自定义加载器详解

前言

本篇文章主要讲述了JVM类加载机制的过程，包括类加载器、双亲委派机制两个方面，结合了相关源码进行阐述，通过阅读本篇文章可以让你对JVM类加载机制有全新的理解，更好的学习JVM。希望本篇文章对你有所帮助。如果在阅读本篇文章有什么独到的见解或者问题，可以留言或者私信，进行探讨。希望各位点赞加关注，让我创作出更多的文章，后续对于JVM的文章也会持续更新，对jvm有兴趣的也可以订阅专栏。

类加载运行全过程

当我们用java命令运行某个类的main函数启动程序时，首先需要通过类加载器把主类加载到 JVM。

public class Math {
    public static final  int DATA = 666;
    public static User user = new User();
    public int compute() {
        int a = 1;
        int b = 2;
        int c = (a + b) * 2;
        return c;
    }
    public static void main(String[] args) {
        Math math = new Math();
        math.compute();
    }
}

当我们运行main方法时，类加载的全流程如下：
在这里插入图片描述

这里主要关注两个地方：一个是loadClass(),这里完成了类的加载;一个是sun.misc.Launcher.getLauncher()，这里完成了类加载器的创建;

loadClass的类加载过程

加载->验证->准备->解析->初始化->使用->卸载

在这里插入图片描述

加载：在硬盘上查找并通过IO读入字节码文件，使用到类的时候才会进行加载，例如调用类的mian方法，new对象等等，在加载阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
- 类被加载到方法区中后主要包含，运行时常量池、类型信息、字段信息、方法信息、类加载器的引用和对应class实例的引用等信息。
  - 类加载器的引用：这个类到类加载器实例的引用
  - 对应class实例的引用：类加载器在加载类的信息放到方法区中后，会创建一个对应的Class类型的对象实例放到堆中，作为开发人员访问方法区中类定义的入口和切入点
验证：校验字节码文件(.class)的正确性（文件格式）
准备：给类的静态变量分配内存，并赋予默认值

注意：这里是给静态变量分配内存，而不是所有的变量，并且是赋予默认值，具体的赋值在初始化阶段。
解析：将符号引用替换为直接引用，该阶段会把一些静态方法(符号引用，比如mian方法)替换为指向数据所存内存的指针或者句柄等(直接引用)，这也就是静态链接的过程(在类加载期间完成)，而动态链接是在程序运行期间完成的将符号引用替换为直接引用。

**静态链接和动态链接的区别：**对象不同：静态链接针对的就是静态方法，动态链接针对的就是非静态方法；时期不同：静态链接是在类加载期间完成，动态链接是在程序运行期间完成。
初始化：对类的静态变量初始化为指定的值，执行静态代码块(static{}包裹的就是静态代码块)。

**注意：**主类在运行过程中如果用到其他类，会逐步加载这些类。

jar包或者war包里的类不是一次性全部加载的，是使用到时才加载，也就是懒加载。

类加载器和双亲委派机制

类加载器的类型

上面的类加载过程主要是通过类加载器来实现的，java里面的类加载器主要有以下几种：

引导类加载器： 负责加载支撑JVM运行的位于JRE的lib目录下的核心类库。(C++实现)
扩展类加载器： 负责加载支撑JVM运行的位于JRE的lib目录下的ext拓展目录中的JAR包。
应用程序类加载器： 负责加载ClassPath路径下的类包，也就是自己写的类。
自定义加载器： 负责加载用户自定义路径下的类包。

类加载器的初始化过程

通过类运行加载的群过程流程图可知，其中会创建JVM实例sun.misc.Launcher。

sun.misc.Launcher初始化使用了单例模式设计，保证了一个JVM虚拟机内只有一个sun.misc.Launcher实例。

在Launcher构造方法内部，其创建了两个类加载器，分别是sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)，JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序。

public Launcher() {
    // Create the extension class loader
    ClassLoader extcl;
    try {
        extcl = ExtClassLoader.getExtClassLoader();
    } catch (IOException e) {
        throw new InternalError(
            "Could not create extension class loader", e);
    }

    // Now create the class loader to use to launch the application
    try {
        loader = AppClassLoader.getAppClassLoader(extcl);
    } catch (IOException e) {
        throw new InternalError(
            "Could not create application class loader", e);
    }
  	public ClassLoader getClassLoader() {
        return loader;
    }
}

双亲委派机制

在Launcher构造方法创建了两个类加载器（扩展类加载器、应用程序类加载器）会自动建立亲子结构，也就形成了双亲委派机制。

在这里插入图片描述

这里的类加载其实就是一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有的父类加载器在自己的加载类路径上都找不到目标类，则在自己的类加载路径上查找并载入目标类。

比如我们的例子Math类，最先会找到应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展器类加载器再委托引导类加载器，引导类加载器找不到会向下退回加载Math类的请求，扩展类加载器收到请求后，就会自己加载，假如自己也加载不到，就会向下退回加载Math类的请求到应用程序类加载器，应用程序类加载器就会自己加载。

注意：这里的子类跟父类不是继承里面的子类和父类，类加载器之间没有继承关系，只是类加载器的parent属性值是父类加载器。

在这里插入图片描述

双亲委派机制就是，先找父类加载器加载，不行由儿子自己加载。

从源码可以看出，子类先交给父类加载，父类加载不了再自己加载
public Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    int i = name.lastIndexOf('.');
    if (i != -1) {
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            sm.checkPackageAccess(name.substring(0, i));
        }
    }

    if (ucp.knownToNotExist(name)) {
        // The class of the given name is not found in the parent
        // class loader as well as its local URLClassPath.
        // Check if this class has already been defined dynamically;
        // if so, return the loaded class; otherwise, skip the parent
        // delegation and findClass.
        Class<?> c = findLoadedClass(name);
        if (c != null) {
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
        throw new ClassNotFoundException(name);
    }

    return (super.loadClass(name, resolve));

//双亲委托机制代码实现（代码的校验进行了删减，只提取了有用的部分）
protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        //首先判断自己加载过的集合里面有没有该类
        Class<?> c = findLoadedClass(name);
        if (c == null) {
        //自己加载过的集合里面没有该类
            long t0 = System.nanoTime();
                if (parent != null) {
                //父类不为空，则继续找父类加载
                    c = parent.loadClass(name, false);
                } else {
                //父类为空，此时到了引导类加载器，没找到就返回null，
                    c = findBootstrapClassOrNull(name);
                }
            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;
    }
}

为什么要设置双亲委派机制？

沙箱安全机制：自己写的java.lang.String.class类不会被加载，这样便可以防止核心API库被随意篡改。
避免类的重复加载：当父亲已经加载了该类时，就没有必要让子类的类加载器再加载一次，保证被加载类的唯一性。

全盘负责委托机制

"全盘负责"是指当一个ClassLoader装载一个类时，除非显示的使用另外一个ClassLoader，该类所依赖以及引用的类也由这个ClassLoader载入。

就是在加载一个类的时候，加载该类的加载器会加载该类以及该类所依赖的类。

自定义类加载器实例

自定义类加载器只需要继承java.lang.ClassLoader类，该类有两个核心方法，一个是loadClass(String，boolean)，实现了双亲委派机制，还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。

public class MyClassLoaderTest {
    static class MyClassLoader extends ClassLoader {
        private String classPath;
        public MyClassLoader(String classPath){
            this.classPath = classPath;
        }
        //将类文件读取到字节数组中
        private byte[] loadByte(String name) throws Exception {
            name = name.replace("\\.","/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
        //重写findClass方法
        //作用：根据传过来的类名，在磁盘上找对应的类，通过defineClass方法调用本地方法实现类加载
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                return defineClass(name,data,0, data.length);
            } catch (Exception e) {
                throw new ClassNotFoundException();
            }
        }
    }
    public static void main(String args[]) throws Exception {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父类加载器设置为应用程序类加载器
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
        Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
        //这里利用了反射调用了User1类的sout方法
        Object obj = clazz.newInstance();
        
        Method method = clazz.getDeclaredMethod("sout", null);
        method.invoke(obj,null);
        //输出User1类加载器
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

打破双亲委派机制

想要自定义类加载器去加载类，而不是委托父类加载器去加载

实现双亲委派机制的关键在于loadClass，只需要重写loadClass就可以打破双亲委派机制。重写也只需要将ClassLoader的loadClass方法里的try-catch部分删去就可以。**但是这样修改，假如需要加载的类依赖核心核心类，由于全盘负责委托机制，当前类加载器还需要加载核心类，但是找不到核心类，就会出现报错，由于有沙箱安全机制，所以不能直接将依赖的核心类通过复制来解决问题。**此时就需要对加载的类进行判断（改进代码在// 之间//），整体代码如下：

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();
            long t1 = System.nanoTime();
            //
            if(!name.startsWith("com.ez.jvm")) {
            	c = this.getParent().loadClass(name);
            } else {
            	c = findClass(name);
            }
            //
            sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
            sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
            sun.misc.PerfCounter.getFindClasses().increment();
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

Tomcat打破双亲委派机制

思考，Tomcat如果使用默认的双亲委派类加载机制行不行？

解决这个问题的思路，首先我们要弄懂Tomcat需要解决什么问题

不同程序第三方库版本问题。Tomcat是一个web容器，作为一个容器，可能需要部署两个应用程序，不同的应用程序可能会依赖同一个第三方库的不同版本，因此要保证每一个应用程序的类库都是独立的，相互隔离的。
相同程序相同类库共享问题。部署在同一个容器里面的相同类库的相同版本可以共享。防止类库重复加载。
容器类库与程序类库隔离问题。web容器也有自己依赖的类库，不能和程序的类库相混淆。基于安全考虑，应该让容器类库与程序类库相隔离。
**jsp修改后不用重启问题。**web容器要支持jsp修改，jsp文件最终也是要编译成class文件才能在虚拟机中运行，但程序运行后可能经常性修改jsp，因此web容器需要支持jsp修改后不需要重启。

进而回答我们的问题。Tomcat如果使用默认的双亲委派类加载机制行不行？

相信在了解了双亲委派机制和Tomcat需要解决的问题，这个题目的答案是不行的，针对上面的问题，来看看默认的类加载机制能否满足要求。

如果使用默认的类加载机制，那么是无法加载两个相同类库的不同版本的，默认的类加载器不管你是什么版本，只在乎你的全限定名，并只有一份。因此第一、三问题不能解决。
默认的类加载器是能够实现相同程序相同类库共享问题，因为它的职责就是保证唯一性。
怎样实现jsp的热加载呢？jsp文件实际上也就是class文件，虽然内容修改了，但是类名是一样的，类加载器会直接从方法去中存在的进行加载，修改后的jsp是不会重新加载的。每个jsp文件会对应一个唯一的类加载器，当一个jsp文件被修改，我们只需要重新创建类加载器，就能实现jsp的热加载了。

那么下一个问题，Tomcat是怎么打破双亲委派机制的呢？

tomcat为了实现隔离性，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器，打破了双亲委派机制

Tomcat自定义加载器详解

Tomcat类加载机制流程图

在这里插入图片描述

tomcat的主要类加载器

commonClassLoader：Tomcat最基本的类加载器，加载路径中的class可以被Tomcat容器本身以及各个Webapp访问；
catalinaClassLoader：Tomcat容器私有的类加载器，加载路径中的class对于Webapp不可见；
sharedClassLoader：各个Webapp共享的类加载器，加载路径中的class对于所有的Webapp可见，但对于Tomcat容器不可见；解决了容器类库与程序类库隔离问题。
WebappClassLoader：各个Webapp私有的类加载器，加载路径中的class只对当前Webapp可见；比如加载war包里的相关类，每个war包应用都有自己的WebappClassLoader，实现相互隔离。也就解决了不同程序第三方库版本问题。

实现Tomcat自定义加载器

其实在学习打破双亲委派机制时的代码，就已经差不多实现了Tomcat自定义加载器，只需要把对于不同的war包生成不同的类加载实例即可。

   public class MyClassLoaderTest {
    static class MyClassLoader extends ClassLoader {
        private String classPath;
        public MyClassLoader(String classPath){
            this.classPath = classPath;
        }
        //将类文件读取到字节数组中
        private byte[] loadByte(String name) throws Exception {
            name = name.replace("\\.","/");
            FileInputStream fis = new FileInputStream(classPath + "/" + name + ".class");
            int len = fis.available();
            byte[] data = new byte[len];
            fis.read(data);
            fis.close();
            return data;
        }
        //重写findClass方法
        //作用：根据传过来的类名，在磁盘上找对应的类，通过defineClass方法调用本地方法实现类加载
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            try {
                byte[] data = loadByte(name);
                return defineClass(name,data,0, data.length);
            } catch (Exception e) {
                throw new ClassNotFoundException();
            }
        }
        //重写loadClass方法
        //作用：打破双亲委派机制
        @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();
            		long t1 = System.nanoTime();
            		//
            		if(!name.startsWith("com.ez.jvm")) {
            			c = this.getParent().loadClass(name);
            		} else {
            			c = findClass(name);
            		}
            		//
            		sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
            		sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
            		sun.misc.PerfCounter.getFindClasses().increment();
        		}
        		if (resolve) {
            		resolveClass(c);
        		}
        		return c;
    		}
		}
    }
    public static void main(String args[]) throws Exception {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父类加载器设置为应用程序类加载器
        MyClassLoader classLoader = new MyClassLoader("D:/test");
        //文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
        Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
        //这里利用了反射调用了User1类的sout方法
        Object obj = clazz.newInstance();
        
   		Method method = clazz.getDeclaredMethod("sout", null);
    	method.invoke(obj,null);
    	//输出User1类加载器
    	System.out.println(clazz.getClassLoader().getClass().getName());
//再new一个类加载实例即可    	
    	MyClassLoader classLoader = new MyClassLoader("D:/test");
        //文件路径D:/test/com/ez/jvm/User1,User1是User的复制类，
        Class<?> clazz = classLoader.loadClass("com.ez.jvm.User1");
        //这里利用了反射调用了User1类的sout方法
        Object obj = clazz.newInstance();
        
   		Method method = clazz.getDeclaredMethod("sout", null);
    	method.invoke(obj,null);
    	//输出User1类加载器
    	System.out.println(clazz.getClassLoader().getClass().getName());
	}
}

这里的代码只是简单的实现了下Tomcat类加载的原理，真实情况肯定不会那么简单，比如对于jsp的热加载，肯定会用到线程、定时任务等等，启动一个线程对文件改动进行监听，改动了就修改jsp类加载器，在这里就不多赘述。
/这里利用了反射调用了User1类的sout方法
Object obj = clazz.newInstance();

   		Method method = clazz.getDeclaredMethod("sout", null);
    	method.invoke(obj,null);
    	//输出User1类加载器
    	System.out.println(clazz.getClassLoader().getClass().getName());
	}
}

这里的代码只是简单的实现了下Tomcat类加载的原理，真实情况肯定不会那么简单，比如对于jsp的热加载，肯定会用到线程、定时任务等等，启动一个线程对文件改动进行监听，改动了就修改jsp类加载器，在这里就不多赘述。