这篇“Java类加载器与双亲委派机制如何应用”文章的知识点大部分人都不太理解，所以小编给大家总结了以下内容，内容详细，步骤清晰，具有一定的借鉴价值，希望大家阅读完这篇文章能有所收获，下面我们一起来看看这篇“Java类加载器与双亲委派机制如何应用”文章吧。
引子
大家想必都有过平时开发springboot 项目的时候稍微改动一点代码，就得重启，就很烦
网上一般介绍 2种方式
spring-boot-devtools,或者通过
JRebel插件 来实现"热部署"
热部署就是当应用正在运行时，修改应用不需要重启应用。
其中
spring-boot-devtools其实是自动重启，主要是节省了我们手动点击重启的时间，不算真正意义上的热部署。JRebel插件啥都好，就是需要收费
但如果平时我们在调试debug的情况下，只是在方法块内代码修改了一下，我们还得重启项目，就很浪费时间。这个时候我们其实可以直接build ，不重启项目，即可 实现热部署。
我们先来写一个例子演示一下：
@RestController
public class TestController {
@RequestMapping(value = "/test",method = {RequestMethod.GET, RequestMethod.POST})
public void testclass() {
String name = "zj";
int weight = 100;
System.out.println("name:"+ name);
System.out.println("weight: "+weight);
}
}结果：
name:zj weight: 100
修改代码，然后直接build项目，不重启项目，我们再请求这个测试接口：
String name = "ming"; int weight = 300;
神奇的一幕出现了，结果为：
name:ming weight: 300
当我们修改.java文件，只需重新生成对应的.class文件，就能影响到程序运行结果， 无需重启，Why? 背后JVM的操作原理且看本文娓娓道来。
了解.class文件
首先我们得先了解一下 什么是.class文件
举个简单的例子，创建一个Person类：
public class Person {
/**
* 状态 or 属性
*/
String name;//姓名
String sex;//性别
int height;//身高
int weight;//体重
/**
* 行为
*/
public void sleep(){
System.out.println(this.name+"--"+ "睡觉");
}
public void eat(){
System.out.println("吃饭");
}
public void Dance(){
System.out.println("跳舞");
}
}我们执行javac命令，生成Person.class文件
然后我们通过
vim 16进制打开它
#打开file文件 vim Person.class #在命令模式下输入.. 以16进制显示 :%!xxd #在命令模式下输入.. 切换回默认显示 :%!xxd -r
不同的操作系统，不同的 CPU 具有不同的指令集，JAVA能做到平台无关性，依靠的就是 Java 虚拟机。.java源码是给人类读的，而.class字节码是给JVM虚拟机读的，计算机只能识别 0 和 1组成的二进制文件，所以虚拟机就是我们编写的代码和计算机之间的桥梁。
虚拟机将我们编写的 .java 源程序文件编译为 字节码 格式的 .class 文件，字节码是各种虚拟机与所有平台统一使用的程序存储格式，class文件主要用于解决平台无关性的中间文件
类加载的过程
在之前的一篇文章谈谈JAVA中对象和类、this、super和static关键字中，我们知晓 Java 是如何创建对象的
Person zhang = new Person();
虽然我们写的时候是简单的一句，但是JVM内部的实现过程却是复杂的：
将硬盘上指定位置的Person.class文件加载进内存
执行main方法时，在栈内存中开辟了main方法的空间（压栈-进栈），然后在main方法的栈区分配了一个变量zhang。
执行new，在堆内存中开辟一个 实体类的 空间，分配了一个内存首地址值
调用该实体类对应的构造函数，进行初始化（如果没有构造函数，Java会补上一个默认构造函数）。
将实体类的 首地址赋值给zhang，变量zhang就引用了该实体。（指向了该对象）
类加载过程
其中 上图步骤1 Classloader(类加载器) 将class文件加载到内存中具体分为3个步骤：加载、连接、初始化
类的生命周期一般有如下图有7个阶段，其中阶段1-5为类加载过程，验证、准备、解析统称为连接
类的生命周期
1.加载
加载阶段：指的是将类对应的.class文件中的二进制字节流读入到内存中，将这个字节流转化为方法区的运行时数据结构，然后在堆区创建一个java.lang.Class 对象，作为对方法区中这些数据的访问入口
相对于类加载的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是我们最可以控制的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义类加载器来完成加载。这个我们文章后面再详细讲
2.验证
验证阶段：校验字节码文件正确性。这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
这部分对开发者而言是无法干预的，以下内容了解即可
验证阶段大致会完成4个阶段的检验动作：
文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以
0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
符号引用验证：确保解析动作能正确执行。
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用
-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
3.准备
准备阶段：为类变量(static 修饰的变量)分配内存，并将其初始化为默认值
注意此阶段仅仅是为类变量 即静态变量分配内存，并将其初始化为默认值
举个例子，在这个准备阶段：
static int value = 3;//类变量 初始化，设为默认值 0，不是 3哦 ！！！ int num = 4;//类成员变量，在这个阶段不初始化；在 new类，调用对应类的构造函数才进行初始化 final static valFin = 5;//这个比较特殊，在这个阶段也不会分配内存！！！
注意:
valFin是被
final static修饰的常量在 **编译 **的时候已分配好了，所以在准备阶段 此时的值为5，所以在这个阶段也不会初始化！
4.解析
解析阶段：是虚拟机将常量池内的
符号引用替换为
直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
这个阶段了解一下即可
5.初始化
直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。
初始化阶段 是类加载过程的最后一个步骤，之前介绍的几个类加载的动作里，除了在
加载阶段用户应用程序可以通过
自定义类加载器的方式局部参与外，其余动作都完全由Java虚拟机来主导控 制。
Java程序对类的使用方式可分为两种：
主动使用与
被动使用。一般来说只有当对类的首次主动使用的时候才会导致类的初始化，所以主动使用又叫做类加载过程中“初始化”开始的时机。
类实例初始化方式，主要是以下几种：
1、创建类的实例，也就是new的方式
2、访问某个类或接口的静态变量，或者对该静态变量赋值
3、调用类的静态方法
4、反射（如
Class.forName("com.test.Person")）5、初始化某个类的子类，则其父类也会被初始化
6、Java虚拟机启动时被标明为启动类的类（JavaTest），还有就是Main方法的类会 首先被初始化
这边就不展开说了，大家记住即可
6.使用
当JVM完成初始化阶段之后，JVM便开始从入口方法开始执行用户的程序代码
7.卸载
当用户程序代码执行完毕后，JVM便开始销毁创建的Class对象，最后负责运行的JVM也退出内存
在如下几种情况下，Java虚拟机将结束生命周期
执行了System.exit()方法
程序正常执行结束
程序在执行过程中遇到了异常或错误而异常终止
由于操作系统出现错误而导致Java虚拟机进程终止
类加载器 与 双亲委派机制
上文类加载过程中，是需要类加载器的参与，类加载器在Java中非常重要，它使得 Java 类可以被动态加载到 Java 虚拟机中并执行
那什么是类加载器？通过一个类的全限定名来获取描述此类的二进制字节流到JVM中，然后转换为一个与目标类对应的java.lang.Class对象实例
Java虚拟机支持类加载器的种类：主要包括3中：引导类加载器（Bootstrap ClassLoader）、扩展类加载器（Extension ClassLoader）、应用类加载器（系统类加载器，AppClassLoader)，另外我们还可以自定义加载器-用户自定义类加载器
引导类加载器（Bootstrap ClassLoader）：
BootStrapClassLoader是由c++实现的。引导类加载器加载java运行过程中的核心类库
JRE＼lib＼rt.jar，sunrsasign.jar， charsets.jar， jce.jar， jsse.jar， plugin.jar以及存放 在
JRE＼classes里的类，也就是JDK提供的类等常见的比如：
Object、Stirng、List等
扩展类加载器（Extension ClassLoader）：它用来加载
/jre/lib/ext目录以及
java.ext.dirs系统变量指定的类路径下的类。
应用类加载器（AppClassLoader)：它主要加载应用程序ClassPath下的类（包含jar包中的类）。它是java应用程序默认的类加载器。其实就是加载我们一般开发使用的类
用户自定义类加载器：用户根据自定义需求，自由的定制加载的逻辑，只需继承应用类加载器AppClassLoader，负责加载用户自定义路径下的class字节码文件
线程上下文类加载器：除了以上列举的三种类加载器，其实还有一种比较特殊的类型就是
线程上下文类加载器。ThreadContextClassLoader可以是上述类加载器的任意一种，这个我们下文再细说
我们来看一个例子：
public class TestClassLoader {
public static void main(String[] args) throws ClassNotFoundException {
ClassLoader classLoader = TestClassLoader.class.getClassLoader();
System.out.println(classLoader);
System.out.println(classLoader.getParent());//获取其父类加载器
System.out.println(classLoader.getParent().getParent());//获取父类的父类加载器
}
}结果：
sun.misc.Launcher
ExtClassLoader@5caf905d null
结果显示分别打印应用类加载器、扩展类加载器和引导类加载器
由于 引导类加载器 是由c++实现的，所以并不存在一个Java的类，因此会打印出null
我们还可以看到结果里面打印了
sun.misc.Launcher，这个是什么东东？
其实Launcher是JRE中用于启动程序入口main()的类，我们看下Launcher的源码：
public class Launcher {
private static Launcher launcher = new Launcher();
private static String bootClassPath =
System.getProperty("sun.boot.class.path");
public static Launcher getLauncher() {
return launcher;
}
private ClassLoader loader;
public Launcher() {
// Create the extension class loader
ClassLoader extcl;
try {
extcl = ExtClassLoader.getExtClassLoader(); //加载扩展类类加载器
} catch (IOException e) {
throw new InternalError(
"Could not create extension class loader", e);
}
// Now create the class loader to use to launch the application
try {
loader = AppClassLoader.getAppClassLoader(extcl);//加载应用程序类加载器,并设置parent为extClassLoader
} catch (IOException e) {
throw new InternalError(
"Could not create application class loader", e);
}
Thread.currentThread().setContextClassLoader(loader); //设置AppClassLoader为线程上下文类加载器
}
/*
* Returns the class loader used to launch the main application.
*/
public ClassLoader getClassLoader() {
return loader;
}
/*
* The class loader used for loading installed extensions.
*/
static class ExtClassLoader extends URLClassLoader {}
/**
* The class loader used for loading from java.class.path.
* runs in a restricted security context.
*/
static class AppClassLoader extends URLClassLoader {}其中
loader = AppClassLoader.getAppClassLoader(extcl);的核心方法源码如下：
private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;//设置parent
if (ParallelLoaders.isRegistered(this.getClass())) {
parallelLockMap = new ConcurrentHashMap<>();
package2certs = new ConcurrentHashMap<>();
assertionLock = new Object();
} else {
// no finer-grained lock; lock on the classloader instance
parallelLockMap = null;
package2certs = new Hashtable<>();
assertionLock = this;
}
}通过以上源码我们可以知晓：
Launcher的
ClassLoader是
BootstrapClassLoader，在Launcher创建的同时，还会同时创建ExtClassLoader，AppClassLoader（并设置其parent为extClassLoader）。其中代码中 "sun.boot.class.path"是
BootstrapClassLoader加载的jar包路径。
这几种类加载器 都遵循 双亲委派机制
双亲委派机制说的其实就是，当一个类加载器收到一个类加载请求时，会去判断有没有加载过，如果加载过直接返回，否则该类加载器会把请求先委派给父类加载器。每个类加载器都是如此，只有在父类加载器在自己的搜索范围内找不到指定类时，子类加载器才会尝试自己去加载。
双亲委派模式优势：
避免类的重复加载， 当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次, 这样保证了每个类只被加载一次。
保护程序安全，防止核心API被随意篡改，比如 java核心api中定义类型不会被随意替换
我们这里看一个例子：
我们新建一个自己的类“String”放在src/java/lang目录下
public class String {
static {
System.out.println("自定义 String类");
}
}新建StringTest类：
public class StringTest {
public static void main(String[] args) {
String str=new java.lang.String();
System.out.println("start test-------");
}
}结果：
start test-------
可以看出，程序并没有运行我们自定义的“String”类，而是直接返回了String.class。像String,Integer等类 是JAVA中的核心类，是不允许随意篡改的！
ClassLoader
ClassLoader是一个抽象类，负责加载类，像
ExtClassLoader，AppClassLoader都是由该类派生出来，实现不同的类装载机制。这块的源码太多了，就不贴了
我们来看下 它的核心方法
loadClass()，传入需要加载的类名，它会帮你加载:
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就是BootstrapClassLoader，使用 启动类类加载器
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
long t1 = System.nanoTime();
// 如果还是没有加载成功，调用findClass(),让当前类加载器加载
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;
}
}
// 继承的子类得重写该方法
protected Class<?> findClass(String name) throws ClassNotFoundException {
throw new ClassNotFoundException(name);
}loadClass()源码 展示了，一般加载.class文件大致流程：
先去缓存中 检查是否已经加载该类，有就直接返回，避免重复加载；没有就下一步
遵循 双亲委派机制，来加载.class文件
上面两步都失败了，调用findClass()方法，让当前类加载器加载
注意：由于
ClassLoader类是抽象类，而抽象类是无法通过new创建对象的，所以它最核心的
findClass()方法，没有具体实现，只抛了一个异常，而且是protected的，这是应用了
模板方法模式，具体的findClass()方法丢给子类实现, 所以继承的子类得重写该方法。
自定义类加载器
编写一个自定义的类加载器
那我们仿照
ExtClassLoader，AppClassLoader来实现一个自定义的类加载器，我们同样是继承
ClassLoader类
编写一个测试类TestPerson
public class TestPerson {
String name = "xiao ming";
public void print(){
System.out.println("hello my name is: "+ name);
}
}接着 编写一个自定义类加载器MyTestClassLoader：
public class MyTestClassLoader extends ClassLoader {
final String classNameSpecify = "TestPerson";
public MyTestClassLoader() {
}
public MyTestClassLoader(ClassLoader parent)
{
super(parent);
}
protected Class<?> findClass(String name) throws ClassNotFoundException
{
File file = getClassFile(name);
try
{
byte[] bytes = getClassBytes(file);
Class<?> c = this.defineClass(name, bytes, 0, bytes.length);
return c;
}
catch (Exception e)
{
e.printStackTrace();
}
return super.findClass(name);
}
private File getClassFile(String name)
{
File file = new File("D:ideaProjectssrcmainjavacomzjideaprojects est2"+ classNameSpecify+ ".class");
return file;
}
private byte[] getClassBytes(File file) throws Exception
{
// 这里要读入.class的字节，因此要使用字节流
FileInputStream fis = new FileInputStream(file);
FileChannel fc = fis.getChannel();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
WritableByteChannel wbc = Channels.newChannel(baos);
ByteBuffer by = ByteBuffer.allocate(1024);
while (true)
{
int i = fc.read(by);
if (i == 0 || i == -1)
break;
by.flip();
wbc.write(by);
by.clear();
}
fis.close();
return baos.toByteArray();
}
//我们这边要打破双亲委派模型，重写整个loadClass方法
@Override
public Class<?> loadClass(String name) throws ClassNotFoundException {
Class<?> c = findLoadedClass(name);
if (c == null && name.contains(classNameSpecify)){//指定的类，不走双亲委派机制，自定义加载
c = findClass(name);
if (c != null){
return c;
}
}
return super.loadClass(name);
}
}最后在编写一个测试controller:
@RestController
public class TestClassController {
@RequestMapping(value = "testClass",method = {RequestMethod.GET, RequestMethod.POST})
public void testClassLoader() throws ClassNotFoundException, InstantiationException, IllegalAccessException, NoSuchMethodException, InvocationTargetException {
MyTestClassLoader myTestClassLoader = new MyTestClassLoader();
Class<?> c1 = Class.forName("com.zj.ideaprojects.test2.TestPerson", true, myTestClassLoader);
Object obj = c1.newInstance();
System.out.println("当前类加载器："+obj.getClass().getClassLoader());
obj.getClass().getMethod("print").invoke(obj);
}
}先找到TestPerson所在的目录， 执行命令：
javac TestPerson，生成TestPerson.class
这里没有使用idea的build,是因为我们代码的class读取路径 是写死了的，不走默认CLASSPATH
D:ideaProjectssrcmainjavacomzjideaprojects est2TestPerson.class
我们然后用postman调用testClassLoader()测试接口
结果：
当前类加载器：com.zj.ideaprojects.test2.MyTestClassLoader@1d75e392
hello my name is: xiao ming
然后修改TestPerson，将name 改为 “xiao niu”
public class TestPerson {
String name = "xiao niu";
public void print(){
System.out.println("hello my name is: "+ name);
}
}然后在当前目录 重新编译, 执行命令：
javac TestPerson，会在当前目录重新生成TestPerson.class 不重启项目，直接用postman 直接调这个测试接口 结果：
当前类加载器：com.zj.ideaprojects.test2.MyTestClassLoader@7091bd27
hello my name is: xiao niu
这样就实现了“热部署”！！！
为什么我们这边要打破双亲委派机制
如果不打破的话,结果 当前类加载器会显示"sun.misc.Launcher$AppClassLoader"，原因是由于idea启动项目的时候会自动帮我们编译，将class放到 CLASSPATH路径下。其实可以把默认路径下的.class删除也行。这里也是为了展示如何打破双亲委派机制，才如此实现的。
官方推荐我们自定义类加载器时，遵循双亲委派机制。但是凡事得看实际需求嘛
自定义类加载器时，如何打破双亲委派机制
通过上面的例子我们可以看出：
1、如果不想打破双亲委派机制，我们自定义类加载器，那么只需要重写findClass方法即可
2、如果想打破双亲委派机制，我们自定义类加载器，那么还得重写整个loadClass方法
SPI机制 与 线程上下文类加载器
如果你阅读到这里，你会发现双亲委派机制的各种好处，但万物都不是绝对正确的，我们需要一分为二地看待问题。
在某些场景下双亲委派制过于局限，所以有时候必须打破双亲委派机制来达到目的。比如 ：SPI机制、线程上下文类加载器
1.SPI(Service Provider Interface)服务提供接口。它是jdk内置的一种服务发现机制，将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要，其核心思想就是 让服务定义与实现分离、解耦。
SPI机制图
2.线程上下文类加载器（context class loader）是可以破坏Java类加载委托机制，使程序可以逆向使用类加载器，使得java类加载体系显得更灵活。
Java 应用运行的初始线程的上下文类加载器是应用类加载器，在线程中运行的代码可以通过此类加载器来加载类和资源。Java.lang.Thread中的方法
getContextClassLoader()和 setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过
setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文类加载器。
SPI机制在框架的设计上应用广泛，下面举几个常用的例子：
JDBC
平时获取jdbc,我们可以这样：
Connection connection =DriverManager.getConnection("jdbc://localhost:3306");我们读
DriverManager的源码发现：其实就是查询classPath下，所有META-INF下给定Class名的文件，并将其内容返回，使用迭代器遍历，这里遍历的内部使用
Class.forName加载了类。
其中有一处非常重要
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);我们看下它的实现：
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();//important !
return ServiceLoader.load(service, cl);
}我们可以看出JDBC，
DriverManager类和
ServiceLoader类都是属于核心库
rt.jar的，它们的类加载器是Bootstrap ClassLoader类加载器。而具体的数据库驱动相关功能却是第三方提供的，第三方的类不能被引导类加载器（Bootst