类加载器、双亲委派、打破双亲委派浅析

最新推荐文章于 2022-09-15 23:49:05 发布

cj_eryue

最新推荐文章于 2022-09-15 23:49:05 发布

阅读量142

点赞数 1

分类专栏： JVM 文章标签： java jvm

本文链接：https://blog.csdn.net/cj_eryue/article/details/115136644

版权

JVM 专栏收录该内容

5 篇文章 0 订阅

订阅专栏

类加载过程

虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转化解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。

整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）。

类加载器

所谓的类加载器（Class Loader）就是加载Java类到Java虚拟机中

在JVM中有三类ClassLoader构成：启动类（或根类）加载器（Bootstrap ClassLoader）、扩展类加载器（ExtClassLoader）、应用类加载器（AppClassLoader）。不同的类加载器负责不同区域的类的加载。

启动类加载器：这个加载器不是一个Java类，而是由底层的c++实现，负责加载存放在JAVA_HOME下lib目录中的类库，比如rt.jar。因此，启动类加载器不属于Java类库，无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

扩展类加载器：由sun.misc.Launcher$ExtClassLoader实现，负责加载JAVA_HOME下lib\ext目录下的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用类加载器：由sun.misc.Launcher$AppClassLoader实现的。由于这个类加载器是ClassLoader中的getSystemClassLoader方法的返回值，所以也叫系统类加载器。它负责加载用户类路径上所指定的类库，可以被直接使用。如果未自定义类加载器，默认为该类加载器。

双亲委派模型

双亲委派模型：当一个类加载器接收到类加载请求时，会先请求其父类加载器加载，依次递归，当父类加载器无法找到该类时（根据类的全限定名称），子类加载器才会尝试去加载。

由此可见双亲委派模型的作用是：保证JDK核心类的优先加载

这样看上去好像很完美吗，真的吗？然后并不是

双亲委派机制有什么缺陷？
如何打破双亲委派机制？

问题1：通过双亲委派机制的原理可以得出一下结论：由于BootstrapClassloader是顶级类加载器，BootstrapClassloader无法委派AppClassLoader来加载类，也就是说BootstrapClassloader中加载的类中无法使用由AppClassLoader加载的类。可能绝大部分情况这个不算是问题，因为BootstrapClassloader加载的都是基础类，供AppClassLoader加载的类调用的类。但是万事万物都不是绝对的比如经典的JAVA SPI机制。

JAVA SPI机制：

SPI的全名为Service Provider Interface，主要是应用于厂商自定义组件或插件中。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java SPI机制的思想：我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块、xml解析模块、jdbc模块等方案。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。

SPI具体约定：

Java SPI的具体约定为：当服务的提供者提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader。

来看一个小demo：

先定义一个接口UserService：


package com.cjian.javaspi.service;

public interface UserService {
    String getUser();
}

有2个实现类：



package com.cjian.javaspi.service.impl;

import com.cjian.javaspi.service.UserService;

public class UserServiceImpl1 implements UserService {
    @Override
    public String getUser() {
        System.out.println("111");
        return "My name is cjian-1 !";
    }
}

package com.cjian.javaspi.service.impl;

import com.cjian.javaspi.service.UserService;

public class UserServiceImpl2 implements UserService {
    @Override
    public String getUser() {
        System.out.println("222");
        return "My name is cjian-2 !";
    }
}

配置：

测试：

package com.cjian.javaspi;

import com.cjian.javaspi.service.UserService;

import java.util.ServiceLoader;

public class JavaSpiDemo {
    public static void main(String[] args) {
        ServiceLoader<UserService> load = ServiceLoader.load(UserService.class);
        for (UserService userService : load) {
            String msg = userService.getUser();
            System.out.println(msg);
        }
    }

}

输出：

实际上，java 的spi机制被大量使用，如dubbo的spi，以及我们使用的数据库连接

con.mysql.cj.jdbc.Driver 实现了java.sql.Driver，而java.sql.Driver是在rt.jar包里的

这就引申出来我们对双亲委派机制的缺陷的讨论，接口：java.sql.Driver，定义在java.sql包中，包所在的位置是：jdk\jre\lib\rt.jar中，java.sql包中还提供了其它相应的类和接口比如管理驱动的类:DriverManager类，很明显java.sql包是由BootstrapClassloader加载器加载的；而接口的实现类com.mysql.jdbc.Driver是由第三方实现的类库，由AppClassLoader加载器进行加载的，我们的问题是DriverManager再获取链接的时候必然要加载到com.mysql.jdbc.Driver类，这就是由BootstrapClassloader加载的类使用了由AppClassLoader加载的类，很明显和双亲委托机制的原理相悖，那它是怎么解决这个问题的？这就引申了我们第二个问题：如何打破双亲委派机制？

自定义类加载器，重写findClass方法；
使用线程上下文类加载器；

我们先来看下第一种：


package com.cjian.classLoader;

import java.io.ByteArrayOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.InputStream;


public class MyClassLoader extends ClassLoader {
    private String classpath;

    public MyClassLoader(String classpath) {
        this.classpath = classpath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] classDate = getClassBinaryData(name);
            if (classDate == null) {
                System.out.println("class file is null!!");
            } else { // defineClass方法将字节码转化为类
                return defineClass(name, classDate, 0, classDate.length);
            }
        } catch (IOException e) {
            e.printStackTrace();
        }
        return super.findClass(name);
    } // 返回类的字节码

    private byte[] getClassBinaryData(String className) throws IOException {
        InputStream in = null;
        ByteArrayOutputStream out = null;
        String path = classpath + File.separatorChar + className.replace('.', File.separatorChar) + ".class";
        try {
            in = new FileInputStream(path);
            out = new ByteArrayOutputStream();
            byte[] buffer = new byte[2048];
            int len = 0;
            while ((len = in.read(buffer)) != -1) {
                out.write(buffer, 0, len);
            }
            return out.toByteArray();
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } finally {
            in.close();
            out.close();
        }
        return null;
    }
}

测试：

package com.cjian.classLoader;

import java.lang.reflect.InvocationTargetException;
import java.lang.reflect.Method;

public class Demo {

    public static void main(String[] args)
        throws ClassNotFoundException, IllegalAccessException, InstantiationException, NoSuchMethodException,
               InvocationTargetException {
       /* System.out.println("boot:" + System.getProperty("sun.boot.class.path"));
        System.out.println("ext:" + System.getProperty("java.ext.dirs"));
        System.out.println("app:" + System.getProperty("java.class.path"));*/

        // 自定义类加载器的加载路径
        MyClassLoader myClassLoader = new MyClassLoader("D:\\classLoader"); // 包名+类名
        Class c = myClassLoader.loadClass("com.test.Test");
        if (c != null) {
            Object obj = c.newInstance();
            Method method = c.getMethod("say", null);
            method.invoke(obj, null);
            System.out.println(c.getClassLoader().toString());
        }

    }

}

输出：

第二种也是JAVA SPI 的原理了：

我们还以mysql的连接为例，通常我们可以通过如下代码来获取一个数据库连接：

public class Test {

    public static void main(String[] args) {
        // TODO Auto-generated method stub

        //1.加载数据库驱动
        try {
            Class.forName("com.mysql.jdbc.Driver");
        } catch (ClassNotFoundException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        
        //2.建立连接，获得Connection对象
        Connection conn = null;
        try {

            conn = DriverManager.getConnection("jdbc:mysql://xxx", "root", "root");
            System.out.println("连接成功");

        } catch (SQLException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
        
        //3.关闭资源
        try {
            conn.close();
        } catch (SQLException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }
}

我们很惊喜的发现：加载JDBC驱动程序实现的代码Class.forName("com.mysql.jdbc.Driver")被注释掉，代码依然能够正常运行，这很奇怪, 继续查看DriverManager.getConnection(url,"name","password");

重点就是DriverManager类的静态代码块，我们都是知道调用类的静态方法会初始化该类，然后执行该类静态代码块，DriverManager的静态代码块如下：

private static void loadInitialDrivers() {
        String drivers;
        try {
            drivers = AccessController.doPrivileged(new PrivilegedAction<String>() {
                public String run() {
                    //获取环境变量中jdbc.drivers的列表
                    return System.getProperty("jdbc.drivers");
                }
            });
        } catch (Exception ex) {
            drivers = null;
        }
      
        //如果按照spi的约定在jar包中的META-INF/services设置了文件,将会加载为服务
        AccessController.doPrivileged(new PrivilegedAction<Void>() {
            public Void run() {
                ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
                Iterator<Driver> driversIterator = loadedDrivers.iterator();
                
                try{
                    while(driversIterator.hasNext()) {
                        //依次加载所有驱动
                        driversIterator.next();
                    }
                } catch(Throwable t) {
                // Do nothing
                }
                return null;
            }
        });

        println("DriverManager.initialize: jdbc.drivers = " + drivers);       
        //如果环境变量中没有设置的驱动程序,就可以结束了
        //否则就将环境变量中的驱动程序加载一下
        if (drivers == null || drivers.equals("")) {
            return;
        }
        String[] driversList = drivers.split(":");
        println("number of Drivers:" + driversList.length);
        for (String aDriver : driversList) {
            try {
                println("DriverManager.Initialize: loading " + aDriver);
                Class.forName(aDriver, true,
                        ClassLoader.getSystemClassLoader());
            } catch (Exception ex) {
                println("DriverManager.Initialize: load failed: " + ex);
            }
        }
    }

我们前文提过JAVA SPI使用的扫描服务实现类的工具类是ServiceLoader，刚好在源码中发现了这个方法，这说明DriverManager.getConnection()方法在被调用的时候就已经从classpath中去加载由第三方实现的java.sql.Driver接口的实现类了。继续查看ServiceLoader.load(Driver.class);方法

 public static <S> ServiceLoader<S> load(Class<S> service) {
        ClassLoader cl = Thread.currentThread().getContextClassLoader();
        return ServiceLoader.load(service, cl);
    }

发现类加载器使用的是线程上下文类加载器（Thread.currentThread().getContextClassLoader()），这是打破双亲委托机制的关键。

什么是线程上下文类加载器？

Q: 越基础的类由越上层的加载器进行加载，如果基础类又要调用回用户的代码，那该怎么办？
A: 解决方案：使用“线程上下文类加载器”

为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoaser()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文类加载器，也就是父类加载器请求子类加载器去完成类加载的动作（即，父类加载器加载的类，使用线程上下文加载器去加载其无法加载的类），这种行为实际上就是打通了双亲委派模型的层次结构来逆向使用类加载器，实际上已经违背了双亲委派模型的一般性原则。

简单来说：在BootstrapClassLoader或ExtClassLoader加载的类A中如果使用到AppClassLoader类加载器加载的类B，由于双亲委托机制不能向下委托，那可以在类A中通过线上线程上下文类加载器获得AppClassLoader，从而去加载类B，这不是委托，说白了这是作弊，也是JVM为了解决双亲委托机制的缺陷不得已的操作！