【JVM】Java类加载器 和 双亲委派机制

1、java类加载器的分类

JDK8及之前

• 启动类加载器，BootStrap Class Loader,加载核心类,加载jre/lib目录下的类，C++实现的
• 拓展类加载器， Extension Class Loader，加载java拓展类库，jre/lib/ext目录下，比如javax,java.util包等
• 应用程序类加载器，Application Class Loader, 也成系统类加载器，负责加载应用程序类，classpath下的类文件，maven依赖的类文件
• 自定义加载器：继承ClassLoader，并重写findClass方法。

类加载器的作用？

负责在类的加载过程中，获取字节码文件并加载到内存中。通过加载字节码数据转换为byte[]数组，接下来调用虚拟机底层方法将byte[]数组转换成方法区和堆中的数据。

2、双亲委派机制

2.1 双亲委派机制为了解决什么问题？

核心是为了解决一个类到底是由哪个类加载器来加载

2.2 介绍一下双亲委派机制？

当一个类加载器需要去加载类时，会 首先委派给其父类加载器进行加载，如果父类加载器无法加载，才由该类加载器自己去加载

2.3、双亲委派机制有什么好处？

这种层级关系使得类加载器能实现类的共享，避免类被重复加载，

提高了代码的安全性和可靠性，避免恶意覆盖jdk的核心类库。

比如，你重写了java.lang.String类，因为双亲委派模型机制，jvm只会通过bootstrap类加载器加载jre/lib包下的String类，由于父类加载器已经加载过这个类，就不会重复加载自己定义的，这样一定程度上保障了jvm的安全。

2.4、双亲委派机制有什么缺点？

有时候，需要多次加载同名的目录下的类，比如，当在Tomcat上部署多个服务时，不同服务可能依赖了不同版本的第三方jar，如果使用双亲委派机制进行加载，那么多个服务中的第三方jar就只会加载一次，那么依赖另外一个版本的jar的服务就有可能产生异常。

为了解决这种情况，需要打破双亲委派机制，不在让父类加载器加载，而是每个服务创建自己的子类加载器。

3、双亲委派机制原理？

不多说，看代码

java.lang.ClassLoader

public Class<?> loadClass(String name) throws ClassNotFoundException {
    return loadClass(name, false);
}

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 能够查到类，就说明类已经被加载了，直接返回了。
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // 双亲委派机制就在这里，如果父加载器不为空，就调用父加载器来尝试加载类
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    // 拓展类加载器的父加载器是null，
                    // 但是上层还有一个C++实现的启动类加载器
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {

            }

            // 父加载器没有加载到，就自己尝试加载
            if (c == null) {
                long t1 = System.nanoTime();
                // 加载方法，protected修饰的，因此如果自定义类加载器，不想破坏双亲委派模型的话，就重写这个方法
                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();
            }
        }
        // resolveClass方法就是类加载阶段的连接 阶段，loadClass方法是赋值为false的，不会进行连接
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

4、如何破坏双亲委派机制呢？

4.1：自定义类加载器，重写loadClass方法

但是如果只为了定义自定义加载器，建议重写findClass方法，这样不会破坏双亲委派机制。

public class MyClassLoader extends ClassLoader {
    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        // 核心类库还是交给双亲委派机制进行加载
        if (name.startsWith("java.")) {
            super.loadClass(name);
        }
        
        // 通过类的全限定名，找到字节码文件，并转为byte数组 不写了
        byte[] data  = loadClassData(name);
        
        // 类的加载就是由defineClass这个底层方法实现的。
        return defineClass(name, data, 0, data.length);
    }
}

4.2 打破双亲委派机制的另外一种案例：JDBC

介绍：JDBC中使用了DriverManger来管理项目中引入的不同数据库的驱动，比如mysql，oracle驱动等。DriverManger这个类，位于rt.jar包中，由启动类加载器进行加载。但是DriverManger这个类是要去加载引入的jar包中的驱动类的，但是引入的jar包应该是由应用程序类加载器加载的，

这就出现了一个问题：启动类加载器加载完成DriverManger后，会委托应用类加载器去加载jar包中的驱动。这种委托关系就打破了双亲委派机制。

DriverManger怎么知道jar包中要加载的驱动在哪里？

spi机制（service provider interface），jdk内置的一种服务发现机制。查找classpath路径下的META-INF/services 文件夹下面的文件，并自动加载文件里所定义的类（这个文件中定义的就是需要加载的类的全限定名称）.

这个文件中定义的就是需要加载的类的全限定名称，在JDBC中，比如mysql，oracle等第三方jar包驱动，就在META-INF/services 文件下面定义了以接口为名称的文件，文件内容就是对接口具体的实现类。

在springboot中，会引入一些其他依赖，自动注入的过程中，因为第三方jar包类和当前启动项不在一个包中，所以不能通过扫描进行注入，而且注入也要尽可能的和第三方依赖解耦。

springboot就规定了在META-INF文件夹中可以定义spring.factories文件，项目启动的时候会遍历所有jar包中的spring.factories，将里面定义的类加载到IOC中。

---- 上述就是springboot 中SPI机制的实现。

4.3 怎么理解JDBC案例中打破双亲委派机制？

1.  首先是DriverManager这个类，是由启动类加载器加载的，毫无疑问符合双亲委派机制
2. DriverManager加载驱动类时，不知道这些驱动类在哪里（比如引入了mysql或者oracle），就在初始化阶段的时候通过SPI机制去寻找，把加载这些类交给了应用类加载器去加载。（问题就出在这里了，启动类加载器委托应用类加载器去加载具体的驱动类。从这一层理解，好像是打破了双亲委派机制。）
3. 但是启动类加载器知道要加载哪些类了之后，加载这些类的过程，还是符合双亲委派机制的。
4. 通过上面的描述，JDBC是否打破双亲委派机制这个事情，见仁见智吧。