前言

本篇文章主要讲述了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 loaderClassLoader 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 applicationtry {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 statssun.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方法调用本地方法实现类加载@Overrideprotected 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 loadedClass<?> 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需要解决什么问题

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

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

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

1. 如果使用默认的类加载机制，那么是无法加载两个相同类库的不同版本的，默认的类加载器不管你是什么版本，只在乎你的全限定名，并只有一份。因此第一、三问题不能解决。
2. 默认的类加载器是能够实现相同程序相同类库共享问题，因为它的职责就是保证唯一性。
3. 怎样实现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方法调用本地方法实现类加载@Overrideprotected 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方法//作用：打破双亲委派机制@Overrideprotected 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();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类加载器，在这里就不多赘述。