5、双亲委派机制

案例2：

B类在扩展类加载器加载路径中，同样应用程序类加载器接到了加载任务，按照案例1中的方式一层一层向上查找，发现都没有加载过。那么启动类加载器会首先尝试加载。它发现这类不在它的加载目录中，向下传递给扩展类加载器。

扩展类加载器发现这个类在它加载路径中，加载成功并返回。

如果第二次再接收到加载任务，同样地向上查找。扩展类加载器发现已经加载过，就可以返回了。

双亲委派机制的作用

1.保证类加载的安全性。通过双亲委派机制避免恶意代码替换JDK中的核心类库，比如java.lang.String，确保核心类库的完整性和安全性。

2.避免重复加载。双亲委派机制可以避免同一个类被多次加载。

如何指定加载类的类加载器？

在Java中如何使用代码的方式去主动加载一个类呢？

方式1：使用Class.forName方法，使用当前类的类加载器去加载指定的类。

方式2：获取到类加载器，通过类加载器的loadClass方法指定某个类加载器加载。

例如：

三个面试题

1、如果一个类重复出现在三个类加载器的加载位置，应该由谁来加载？

启动类加载器加载，根据双亲委派机制，它的优先级是最高的

2、String类能覆盖吗，在自己的项目中去创建一个java.lang.String类，会被加载吗？

不能，会返回启动类加载器加载在rt.jar包中的String类。

3、类的双亲委派机制是什么？

• 当一个类加载器去加载某个类的时候，会自底向上查找是否加载过，如果加载过就直接返回，如果一直到最顶层的类加载器都没有加载，再由顶向下进行加载。
• 应用程序类加载器的父类加载器是扩展类加载器，扩展类加载器的父类加载器是启动类加载器。
• 双亲委派机制的好处有两点：第一是避免恶意代码替换JDK中的核心类库，比如java.lang.String，确保核心类库的完整性和安全性。第二是避免一个类重复地被加载。

  2.6、打破双亲委派机制

  打破双亲委派机制历史上有三种方式，但本质上只有第一种算是真正的打破了双亲委派机制：

  • 自定义类加载器并且重写loadClass方法。Tomcat通过这种方式实现应用之间类隔离，《面试篇》中分享它的做法。
  • 线程上下文类加载器。利用上下文类加载器加载类，比如JDBC和JNDI等。
  • Osgi框架的类加载器。历史上Osgi框架实现了一套新的类加载器机制，允许同级之间委托进行类的加载，目前很少使用。

    自定义类加载器

    一个Tomcat程序中是可以运行多个Web应用的，如果这两个应用中出现了相同限定名的类，比如Servlet类，Tomcat要保证这两个类都能加载并且它们应该是不同的类。如果不打破双亲委派机制，当应用类加载器加载Web应用1中的MyServlet之后，Web应用2中相同限定名的MyServlet类就无法被加载了。

    

    Tomcat使用了自定义类加载器来实现应用之间类的隔离。 每一个应用会有一个独立的类加载器加载对应的类。

    

    那么自定义加载器是如何能做到的呢？首先我们需要先了解，双亲委派机制的代码到底在哪里，接下来只需要把这段代码消除即可。

    ClassLoader中包含了4个核心方法，双亲委派机制的核心代码就位于loadClass方法中。

    public Class loadClass(String name)
    类加载的入口，提供了双亲委派机制。内部会调用findClass   重要
    protected Class findClass(String name)
    由类加载器子类实现,获取二进制数据调用defineClass ，比如URLClassLoader会根据文件路径去获取类文件中的二进制数据。重要
    protected final Class defineClass(String name, byte[] b, int off, int len)
    做一些类名的校验，然后调用虚拟机底层的方法将字节码信息加载到虚拟机内存中
    protected final void resolveClass(Class c)
    执行类生命周期中的连接阶段
    

    1、入口方法：

    

    2、再进入看下：

    

    如果查找都失败，进入加载阶段，首先会由启动类加载器加载，这段代码在findBootstrapClassOrNull中。如果失败会抛出异常，接下来执行下面这段代码：

    

    父类加载器加载失败就会抛出异常，回到子类加载器的这段代码，这样就实现了加载并向下传递。

    3、最后根据传入的参数判断是否进入连接阶段：

    

    接下来实现打破双亲委派机制：

    package classloader.broken;//package com.itheima.jvm.chapter02.classloader.broken;
    import org.apache.commons.io.IOUtils;
    import java.io.File;
    import java.io.FileInputStream;
    import java.io.IOException;
    import java.io.InputStream;
    import java.nio.charset.StandardCharsets;
    import java.security.ProtectionDomain;
    import java.util.regex.Matcher;
    /**
     * 打破双亲委派机制 - 自定义类加载器
     */
    public class BreakClassLoader1 extends ClassLoader {
        private String basePath;
        private final static String FILE_EXT = ".class";
        //设置加载目录
        public void setBasePath(String basePath) {
            this.basePath = basePath;
        }
        //使用commons io 从指定目录下加载文件
        private byte[] loadClassData(String name)  {
            try {
                String tempName = name.replaceAll("\.", Matcher.quoteReplacement(File.separator));
                FileInputStream fis = new FileInputStream(basePath + tempName + FILE_EXT);
                try {
                    return IOUtils.toByteArray(fis);
                } finally {
                    IOUtils.closeQuietly(fis);
                }
            } catch (Exception e) {
                System.out.println("自定义类加载器加载失败，错误原因：" + e.getMessage());
                return null;
            }
        }
        //重写loadClass方法
        @Override
        public Class loadClass(String name) throws ClassNotFoundException {
            //如果是java包下，还是走双亲委派机制
            if(name.startsWith("java.")){
                return super.loadClass(name);
            }
            //从磁盘中指定目录下加载
            byte[] data = loadClassData(name);
            //调用虚拟机底层方法，方法区和堆区创建对象
            return defineClass(name, data, 0, data.length);
        }
        public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, IOException {
            //第一个自定义类加载器对象
            BreakClassLoader1 classLoader1 = new BreakClassLoader1();
            classLoader1.setBasePath("D:\lib\");
            Class clazz1 = classLoader1.loadClass("com.itheima.my.A");
             //第二个自定义类加载器对象
            BreakClassLoader1 classLoader2 = new BreakClassLoader1();
            classLoader2.setBasePath("D:\lib\");
            Class clazz2 = classLoader2.loadClass("com.itheima.my.A");
            System.out.println(clazz1 == clazz2);
            Thread.currentThread().setContextClassLoader(classLoader1);
            System.out.println(Thread.currentThread().getContextClassLoader());
            System.in.read();
         }
    }
    

    自定义类加载器父类怎么是AppClassLoader呢？

    默认情况下自定义类加载器的父类加载器是应用程序类加载器：

    

    以Jdk8为例，ClassLoader类中提供了构造方法设置parent的内容：

    

    这个构造方法由另外一个构造方法调用，其中父类加载器由getSystemClassLoader方法设置，该方法返回的是AppClassLoader。

    

    两个自定义类加载器加载相同限定名的类，不会冲突吗？

    不会冲突，在同一个Java虚拟机中，只有相同类加载器+相同的类限定名才会被认为是同一个类。

    在Arthas中使用sc –d 类名的方式查看具体的情况。

    如下代码：

     public static void main(String[] args) throws ClassNotFoundException, InstantiationException, IllegalAccessException, IOException {
            //第一个自定义类加载器对象
            BreakClassLoader1 classLoader1 = new BreakClassLoader1();
            classLoader1.setBasePath("D:\lib\");
            Class clazz1 = classLoader1.loadClass("com.itheima.my.A");
             //第二个自定义类加载器对象
            BreakClassLoader1 classLoader2 = new BreakClassLoader1();
            classLoader2.setBasePath("D:\lib\");
            Class clazz2 = classLoader2.loadClass("com.itheima.my.A");
            System.out.println(clazz1 == clazz2);
         }
    

    打印的应该是false，因为两个类加载器不同，尽管加载的是同一个类名，最终Class对象也不是相同的。

    通过Arthas看：

    

    也会出现两个不同的A类。

    线程上下文类加载器

    利用上下文类加载器加载类，比如JDBC和JNDI等。

    我们来看下JDBC的案例：

    1、JDBC中使用了DriverManager来管理项目中引入的不同数据库的驱动，比如mysql驱动、oracle驱动。

    package classloader.broken;//package com.itheima.jvm.chapter02.classloader.broken;
    import com.mysql.cj.jdbc.Driver;
    import java.sql.*;
    /**
     * 打破双亲委派机制 - JDBC案例
     */
    public class JDBCExample {
        // JDBC driver name and database URL
        static final String JDBC_DRIVER = "com.mysql.cj.jdbc.Driver";
        static final String DB_URL = "jdbc:mysql:///bank1";
        //  Database credentials
        static final String USER = "root";
        static final String PASS = "123456";
        public static void main(String[] args) {
            Connection conn = null;
            Statement stmt = null;
            try {
                conn = DriverManager.getConnection(DB_URL, USER, PASS);
                stmt = conn.createStatement();
                String sql;
                sql = "SELECT id, account_name FROM account_info";
                ResultSet rs = stmt.executeQuery(sql);
                //STEP 4: Extract data from result set
                while (rs.next()) {
                    //Retrieve by column name
                    int id = rs.getInt("id");
                    String name = rs.getString("account_name");
                    //Display values
                    System.out.print("ID: " + id);
                    System.out.print(", Name: " + name + "\n");
                }
                //STEP 5: Clean-up environment
                rs.close();
                stmt.close();
                conn.close();
            } catch (SQLException se) {
                //Handle errors for JDBC
                se.printStackTrace();
            } catch (Exception e) {
                //Handle errors for Class.forName
                e.printStackTrace();
            } finally {
                //finally block used to close resources
                try {
                    if (stmt != null)
                        stmt.close();
                } catch (SQLException se2) {
                }// nothing we can do
                try {
                    if (conn != null)
                        conn.close();
                } catch (SQLException se) {
                    se.printStackTrace();
                }//end finally try
            }//end try
        }//end main
    }//end FirstExample
    

    2、DriverManager类位于rt.jar包中，由启动类加载器加载。

    

    3、依赖中的mysql驱动对应的类，由应用程序类加载器来加载。

    

    在类中有初始化代码：

    

    DriverManager属于rt.jar是启动类加载器加载的。而用户jar包中的驱动需要由应用类加载器加载，这就违反了双亲委派机制。（这点存疑，一会儿再讨论）

    那么问题来了，DriverManager怎么知道jar包中要加载的驱动在哪儿？

    1、在类的初始化代码中有这么一个方法LoadInitialDrivers：

    

    2、这里使用了SPI机制，去加载所有jar包中实现了Driver接口的实现类。

    

    3、SPI机制就是在这个位置下存放了一个文件，文件名是接口名，文件里包含了实现类的类名。这样SPI机制就可以找到实现类了。

    

    

    4、SPI中利用了线程上下文类加载器（应用程序类加载器）去加载类并创建对象。

    

    总结：

    

    JDBC案例中真的打破了双亲委派机制吗？

    最早这个论点提出是在周志明《深入理解Java虚拟机》中，他认为打破了双亲委派机制，这种由启动类加载器加载的类，委派应用程序类加载器去加载类的方式，所以打破了双亲委派机制。

    但是如果我们分别从DriverManager以及驱动类的加载流程上分析，JDBC只是在DriverManager加载完之后，通过初始化阶段触发了驱动类的加载，类的加载依然遵循双亲委派机制。

    所以我认为这里没有打破双亲委派机制，只是用一种巧妙的方法让启动类加载器加载的类，去引发的其他类的加载。

    Osgi框架的类加载器

    历史上，OSGi模块化框架。它存在同级之间的类加载器的委托加载。OSGi还使用类加载器实现了热部署的功能。热部署指的是在服务不停止的情况下，动态地更新字节码文件到内存中。

    

    由于这种机制使用已经不多，所以不再过多讨论OSGi，着重来看下热部署在实际项目中的应用。

    案例：使用阿里arthas不停机解决线上问题

    背景：

    小李的团队将代码上线之后，发现存在一个小bug，但是用户急着使用，如果重新打包再发布需要一个多小时的时间，所以希望能使用arthas尽快的将这个问题修复。

    思路：

    1. 在出问题的服务器上部署一个 arthas，并启动。
    2. jad --source-only 类全限定名 > 目录/文件名.java jad 命令反编译，然后可以用其它编译器，比如 vim 来修改源码
    3. mc –c 类加载器的hashcode 目录/文件名.java -d 输出目录

       mc 命令用来编译修改过的代码

    4. retransform class文件所在目录/xxx.class

       用 retransform 命令加载新的字节码

    详细流程：

    1、这段代码编写有误，在枚举中的类型判断上使用了== 而不是equals。

    

    2、枚举中是这样定义的，1001是普通用户，1002是VIP用户：

    

    3、由于代码有误，导致传递1001参数时，返回的是收费用户的内容。

    

    4、jad --source-only 类全限定名 > 目录/文件名.java 使用 jad 命令反编译，然后可以用其它编译器，比如 vim 来修改源码

    

    也可以直接双击文件使用finalShell编辑：

    5、mc –c 类加载器的hashcode 目录/文件名.java -d 输出目录 使用mc 命令用来编译修改过的代码

    

    6、retransform class文件所在目录/xxx.class 用 retransform 命令加载新的字节码

    

    7、测试：

    

    注意事项：

    1、程序重启之后，字节码文件会恢复，除非将class文件放入jar包中进行更新。

    2、使用retransform不能添加方法或者字段，也不能更新正在执行中的方法。

    2.7、JDK9之后的类加载器

    JDK8及之前的版本中，扩展类加载器和应用程序类加载器的源码位于rt.jar包中的sun.misc.Launcher.java。

    

    由于JDK9引入了module的概念，类加载器在设计上发生了很多变化。

    1.启动类加载器使用Java编写，位于jdk.internal.loader.ClassLoaders类中。

    Java中的BootClassLoader继承自BuiltinClassLoader实现从模块中找到要加载的字节码资源文件。

    启动类加载器依然无法通过java代码获取到，返回的仍然是null，保持了统一。

    2、扩展类加载器被替换成了平台类加载器（Platform Class Loader）。

    平台类加载器遵循模块化方式加载字节码文件，所以继承关系从URLClassLoader变成了BuiltinClassLoader，BuiltinClassLoader实现了从模块中加载字节码文件。平台类加载器的存在更多的是为了与老版本的设计方案兼容，自身没有特殊的逻辑。