【JVM】打破双亲委派机制

📝个人主页：五敷有你

🔥系列专栏：JVM

⛺️ 稳中求进，晒太阳

打破双亲委派机制

打破双亲委派机制三种方法

自定义类加载器

ClassLoader包含了四个核心方法

java 复制代码

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

双亲委派机制核心代码阅读

阅读双亲委派机制的核心代码，分析如何通过自定义类加载器打破双亲委派机制。

打破双亲委派机制的核心就是讲下面的代码重写

思考

问题一：

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

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

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

问题2

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

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

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

线程上下文类加载器(JDBC案例)

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

DrvierManager类位于rt.jar包中，由启动类加载器加载

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

DriverManager属于rt.jar是启动类加载器的，而用户jar包中的驱动需要由应用程序类加载器加载，这就违反了双亲委派机制。

思考

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

DriverManager使用SPI机制，最终加载jar包中的对应驱动类

SPI机制

SPI全称(Service Provider Interface)是JDK内置的服务提供发现机制。

工作原理

在ClassPath路径下的META-INF/services文件夹中(路径是固定的SPI机制会扫描这个文件夹)，以接口的全限定名来命名文件名，对应的文件里面写接口的实现
在使用ServiceLoader加载实现类

总结

启动类加载器加载DriverManager
在初始化DriverManager时，通过SPI机制加载Jar包中的mysql驱动
SPI中利用线程上下文类加载器(应用程序类加载器) 去加载并创建对象。

OSGi模块化

历史上，OSGi模块化框架，它存在同级之间的类加载器的委托加载，OSGi还使用类加载器实现了热部署功能

热部署指的是在服务器不停止的情况下，动态的更新字节码文件到内存中

案例：

使用arthas不停机解决线上问题

背景：小李的团队将代码上线后，发现bug,但用户着急使用，如果重新打包在发布需要一个多小时的时间，所以希望使用arthas尽快解决问题

思路：

在出问题的服务上部署一个arthas并启动。

jad(反编译) --source-only 类全限定名 > 目录/文件名.java

jad 命令反编译，然后可以用其他编辑器修改源码（比如Vim）

mc -c 类加载器的hashcode 目录/文件名.java -d 输出目录

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

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

retransform命令加载新的字节码

注意：

只是暂时更新到内存中，程序重启后，字节码文件会恢复，除非将class文件放入jar包更新，
使用retransform不能添加方法或字段，也不能更新正在执行的方法

JDK9之后的类加载器

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

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

启动类加载器使用Java编写，位于jdk.internal.loader.ClassLoaders类中。
1. Java中的BootClassLoader继承自BuiltinClassLoader实现从模块中找到要加载的字节码资源文件。
2. 启动类加载器依然无法通过java代码获取到，返回的仍然是null，保持了统一

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

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

总结

1、类加载器的作用是什么？

类加载器（ClassLoader）负责在类加载过程中的字节码获取并加载到内存这一部分。通过加载字节码数据放入内存转换成byte[]，接下来调用虚拟机底层方法将byte[]转换成方法区和堆中的数据

2、有几种常见的类加载器？

1.启动类加载器（Bootstrap ClassLoader）加载核心类

2.扩展类加载器（Extension ClassLoader）加载扩展类

3.应用程序类加载器（Application ClassLoader）加载应用classpath中的类

4.自定义类加载器，重写findClass方法。JDK9及之后扩展类加载器（Extension ClassLoader）变成了平台类加载器（PlatformClassLoader）

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

每个Java实现的类加载器中保存了一个成员变量叫"父"（Parent）类加载器。自底向上查找是否加载过，再由顶向下进行加载。避免了核心类被应用程序重写并覆盖的问题，提升了安全性。

4、怎么打破双亲委派机制？

1、重写loadClass方法，不再实现双亲委派机制。

2、JNDI、JDBC、JCE、JAXB和JBI等框架使用了SPI机制+线程上下文类加载器。

3、OSGi实现了一整套类加载机制，允许同级类加载器之间互相调用。