类加载机制、双亲委派机制深度解析以及如何自定义类加载器

当我们运行一个类的时候，首先要通过类加载机制把类加载到JVM中

1.类加载运行的全过程

从JVM创建 到 类被加载的步骤：

• ①：c++程序先创建java虚拟机
• ②：c++程序创建引导类加载器
• ③：c++创建JVM启动器 Launcher 实例
• ④：在Launcher实例中获取其他类加载器（扩展、应用类加载器）
• ⑤：通过双亲委派机制，决定哪个类加载器加载
• ⑥：找到合适的类加载器后，通过loadClass的类加载过程： 加载 >> 验证 >> 准备 >> 解析 >> 初始化等步骤把类加载到JVM

类加载步骤详解：

• 加载：从硬盘上读取字节码文件，使用到的时候才会加载
• 验证：检验字节码文件的正确性
• 准备：给类的静态变量分配内存，并赋一个默认值（0，null等）
• 解析：将符号引用转换为直接引用。在类加载时属于静态链接的过程，与之对应的还有一个动态链接
  • 符号引用：一个 java 文件会编译成一个class文件。class文件中的每个方法、属性等内容都可以被视为一个符号，存储在constant pool静态常量池中， 在准备阶段之前，由于没有在jvm中为其分配堆栈内存，所以没有具体的引用地址，因此只能使用符号引用来代替。
  • 直接引用：在准备阶段之后，由于class被加载到方法区中，constant pool静态常量池变为运行时常量池！ 同时该class中的属性和方法都已经分配好内存。有具体指针指向该块内存取域，被称为直接引用。所以在解析阶段会把之前的符号引用都转换成直接引用！
  • 静态链接：在类加载过程中，只会把静态方法的符号引用转换为直接引用，而一些非静态的方法在此时不会转换。因为该阶段只是加载，并没有运行，只有在运行时才会把非静态方法的符号引用转换为直接引用。
  • 动态链接：在程序运行时，且执行到某个非静态方法时，才会把该方法的符号引用转换为直接引用，这个过程被称为动态链接！
• 初始化：对类的静态变量初始化为指定的值，此时会执行静态代码块，修改准备阶段时静态变量的默认值为初始值，但不会对实例变量进行初始化，实例变量需要等到对象被 new出来的时候才会进行初始化赋值

1.1 java程序运行的时候是不是一开始就把所有的类加载到内存？

        不会。 Java程序启动时，并不是一次把所有的类全部加载后再运行，它总是先把保证程序运行的基础类一次性加载到jvm中，其它类等到jvm用到的时候再加载。如果一开始就把所有的、用不到的类加载到jvm中，势必会占用很多宝贵的内存空间，而有些class可能在整个运行过程中都不会使用。

• new User() 由于使用到了User类，因此会加载User类，执行静态代码块 和 构造器
• User user = null 只是定义一下User类，并没有使用，因此不会加载User类，也不会执行静态代码块 和 构造器

2. JVM类加载器的初始化

类的加载 主要通过类加载器来实现，java中有以下几种类加载器

2.1 类加载器分类

• ①：引导类加载器：负责加载JVM运行的位于jre/lib目录下的核心库（String类等），比如rt.jar等
• ②：扩展类加载器：负责加载JVM运行的位于jre/ext/lib目录下jar包
• ③：应用类加载器：负责加载ClassPath路径下的类包，主要是加载你自己写的那些类
• ④：自定义类加载器：负责加载用户自定义路径下的类包

2.2类加载器初始化过程

• 1）类加载器由jvm启动器实例Launcher所创建。 Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个sun.misc.Launcher实例。
• 2）在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。
• 3）JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们的应用程序

类加载器初始化过程源码：

3.双亲委派机制

双亲委派机制：说简单点就是，先找父亲加载，不行再由儿子自己加载

比如我们自己写的User类，会遵循以下的加载步骤：

1. 加载时会先找到 应用类加载器进行加载，应用类加载器会把这个加载请求委托给父亲扩展类加载器，扩展类加载器再委托给引导类加载器。
2. 引导类加载器在自己的类加载路径里找了半天 没找到User类，则向下退回User的加载请求
3. 扩展类加载器收到回复就自己加载，在自己的类加载路径里找了半天也没找到User类，又向下退回Math类的加载请求给应用程序类加载器
4. 应用程序类加载器于是在自己的类加载路径里找User类，结果找到了就自己加载了。。

        

问题一：为什么会先由应用程序类加载器加载类？为什么不直接由启动类加载器加载，而是选择从下往上，往返两次？

首先从源码层面看一下为什么先由应用程序类加载器加载类：源码中首先把程序类加载器赋值给了this.loader，说明第一个使用的就是程序类加载器！

        

问题二：那么为什么要往返两次，直接由启动类加载器加载岂不是更省事?

        答：在生产应用中，95%的类其实都是由应用类加载器加载的，如果类已经被加载过一次，就会被保存在应用类加载器中，下次使用可直接从应用类加载器中获取。

        但是如果由启动类加载器加载，大部分的类的获取都要走一个 启动类加载器 >> 扩展类加载器 >> 应用类加载器的过程，下次使用时也要走一遍上述过程，效率显然比直接从应用类加载器中获取要慢不少，所以为了后续调用节省时间，宁可第一次加载浪费点时间，也要选择应用程序类加载器。

        

3.2 双亲委派机制核心源码

首先看一下类加载器的继承关系图，而双亲委派的源码就在顶层父类ClassLoader类中的loadClass()方法实现的。

ClassLoader类中的loadClass()方法源码如下：

        

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

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

        
        

4.编写自定义类加载器

自定义类加载器需要继承承 java.lang.ClassLoader 类。
该类有两个核心方法:

• ①：loadClass(String, boolean) 实现了双亲委派机制（继承即可起作用）
• ②：findClass 默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法

public class MyLoadClass {

    //自定义类加载器MyClassLoadeTest   extends ClassLoader
    static class MyClassLoadeTest extends ClassLoader {

        private String classPath;  //定义要加载的类的路径

        public MyClassLoadeTest(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文件读取后最终的字节 数组。 由native方法实现
                return defineClass(name, data, 0, data.length);
            } catch (Exception e) {
                e.printStackTrace();
                throw new ClassNotFoundException();
            }
        }
    }

	//测试
    public static void main(String[] args) throws ClassNotFoundException {
        //初始化自定义类加载器，会先初始化父类ClassLoader，其中会把自定义类加载器的父加载 器设置为应用程序类加载器AppClassLoader
        MyClassLoadeTest classLoader = new MyClassLoadeTest("D:/test");

        //D盘创建 test/com/tuling/jvm 几级目录，将User类的复制类User.class丢入该目录
        Class clazz = classLoader.loadClass("com.chinalife.policy_manage.user.entity.User");
        
        //输出类加载器类型
        System.out.println(clazz.getClassLoader().getClass().getName());
    }
}

输出结果：

注意：由于自定义类加载器默认父亲是 应用类加载器，如果不删除掉classpath下的user.class，打印的类加载器类型会是sun.misc.Launcher$AppClassLoader。

        

5.（Tomcat）如何打破双亲委派机制

打破双亲委派机制需要重写ClassLoader中的双亲委派方法loadClass（）

打破双亲委派机制代码：

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 (c == null) {
                        long t1 = System.nanoTime();
                        //如果不是这个包下的类,比如Object，使用 自定义类加载器的父亲 >> 应用类加载器，双亲委派
                        if(!name.startsWith("com.chinalife.policy_manage.user.entity")){
                            c = this.getParent().loadClass(name);
                        }else {
                            //如果是这个包下的类 ，比如User，打破双亲委派机制
                            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;
            }
        }

        

5.1 打破双亲委派机制的应用：tomcat

以Tomcat类加载为例，Tomcat 如果使用默认的双亲委派类加载机制行不行？答案是不行的。为什么？

• ①：tomcat是一个web容器，可能需要部署多个应用程序。不同的应用程序可能会依赖同一个第三方类库的不同版本。
  • 比如：一个应用依赖的spring4，另外一个应用依赖的spring5。spring4和spring5底层也会依赖大量相同得类，如果按照以前的双亲委派机制，这些相同的类只能存在一份，如果被加载的是spring4的类，那么当spring5去使用某个类时，只能加载到spring4的类，那就可能丢失了spring5中对这个类的扩展功能。因此要保证每个应用程序的类库都是独立的，保证相互隔离。所以tomcat需要打破双亲委派机制
• ②：web容器也有自己依赖的类库，不能与应用程序的类库混淆。基于安全考虑，应该让容器的类库和程序的类库隔离开来。

如果使用默认的类加载器机制，那么是无法加载两个相同类库的不同版本的，默认 的类加器是不管你是什么版本的，只在乎你的全限定类名，并且只有一份。

        

5.2 Tomcat自定义加载器详解

如上图所示：

• tomcat 为了实现隔离性，打破了双亲委派机制，每个webappClassLoader加载自己的目录下的class文件，不会传递给父类加载器
• 当然，Tomcat的基础设施还是需要遵循双亲委派机制的，只是为了实现应用隔离这一功能，局部打破双亲委派机制。其实现原理如上代码所示，也是经过过滤，让tomcat基础设施目录下的类加载时遵循双亲委派，存放不同应用的目录在加载时自定义类加载器！