本文转载自微信公众号「稀饭下雪」，作者帅气的小饭饭。转载本文请联系稀饭下雪公众号。
熟悉双亲委派模型吗?
熟悉，这题我会。
机会来了，我八股文大神可是专门修炼过这个的。
我们为啥不能在Java工程中定义同名的String的Java文件?
(⊙o⊙)…
这.....
多线程加载类的时候为什么没有线程问题?
卧槽 ....
首先，在讲解这道题之前，先来划重点
类加载时机与过程
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接(Linking)
加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定(也称为动态绑定或晚期绑定)
加载
在加载阶段(可以参考java.lang.ClassLoader的loadClass()方法)，虚拟机需要完成以下3件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流(并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等);
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构;
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口;
验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段大致会完成4个阶段的检验动作：
- 文件格式验证;
- 元数据验证;
- 字节码验证;
- 符号引用验证;
准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量(被static修饰的变量)，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值「通常情况」下是数据类型的零值，
例如：public static int a = 1
这个时候变量a在准备阶段过后的初始值为0，而不是1，因为这个时候尚未开始执行任何java方法，而把a赋值为1的指令是程序被编译后，存放于类构造器()方法中，所以把a赋值为1的动作将在初始化阶段才执行。
而当：public static final int a = 2
这种情况又不同了，当类字段的属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标志位final之后，a的值再准备阶段便被初始化为2，而不再是1 了。
划重点：这里其实也好理解，final标志的常量意味着是不变的，那么在准备阶段直接赋值了就可以了，没必要多此一举，先赋初始值，再在初始化的时候额外再做一次。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
初始化
在介绍初始化时，要先介绍两个方法：
在编译生成class文件时，会自动产生两个方法，一个是类的初始化方法, 另一个是实例的初始化方法
类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备阶段、变量已经被赋值过一次系统要求的初始值，而在初始化阶段，则根据开发人员通过程序去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器
「总结一大波美女：其实也这个过程不用记，靠理解最好了，你想想看哦，你要把一个类加载到虚拟机，是不是要有一个加载的过程，这个过程就是将你的class对应的二进制字节流加载到虚拟机中，加载完虚拟机是不是要校验下，规则的你给的东西有没有毒?验证完了，是不是要帮我们把一些类变量设置下初始值?设置完了还有一些对象标志啊什么的，是不是也要帮忙解析成直接引用，最后是不是还要走下我们类的初始化方法。」
双亲委派模型
所谓双亲委派是指每次收到类加载请求时，先将请求委派给父类加载器完成(所有加载请求最终会委派到顶层的Bootstrap ClassLoader加载器中)，如果父类加载器无法完成这个加载(该加载器的「搜索范围」中没有找到对应的类)，子类尝试自己加载， 如果都没加载到，则会抛出 ClassNotFoundException 异常， 看到这里其实就解释了文章开头提出的第一个问题，父加载器已经加载了JDK 中的 String.class 文件，所以我们不能定义同名的 String java 文件。
这么做的好处是什么?
因为这样可以避免重复加载，当父亲已经加载了该类的时候，就没有必要 ClassLoader 再加载一次。考虑到安全因素，我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String 已经在启动时就被引导类加载器(Bootstrcp ClassLoader)加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变 JDK 中 ClassLoader 搜索类的默认算法。
我们发现除了启动类加载器(BootStrap ClassLoader)，每个类都有其"父类"加载器，这种组合关系是通过组合模式来决定的，而不是继承关系。
三种类加载器分别职责是啥?
- 「Bootstrap ClassLoader」:这个加载器不是一个Java类，而是由底层的c++实现，负责在虚拟机启动时加载Jdk核心类库(如：rt.jar、resources.jar、charsets.jar等)以及加载后两个类加载器。这个ClassLoader完全是JVM自己控制的，需要加载哪个类，怎么加载都是由JVM自己控制，别人也访问不到这个类
- 「Extension ClassLoader」:是一个普通的Java类，继承自ClassLoader类，负责加载{JAVA_HOME}/jre/lib/ext/目录下的所有jar包。
- 「App ClassLoader」：是Extension ClassLoader的子对象，负责加载应用程序classpath目录下的所有jar和class文件。
通常用这两种方式来动态加载一个 java 类，「Class.forName()」 与 「ClassLoader.loadClass()」 ，但是两个方法之间也是有一些细微的差别，具体看上一篇文章：Object详谈
双亲委派模型源码解析
来看看核心loadClass的方法
可以看到方法有同步块(synchronized), 这样就算多线程情况也不会出现重复加载的情况。
JAVA热部署实现
什么是热部署(hotswap)?
Java 类是通过 Java 虚拟机加载的，某个类的 class 文件在被 classloader 加载后，会生成对应的 Class 对象，之后就可以创建该类的实例，而热部署是在不重启 Java 虚拟机的这一前提下，自动侦测到 class 文件的变化，更新运行时 class 的行为。
而实际上，对于同一个全限定名的java类，只能被加载一次，而且无法被卸载。
那么竟然类无法被卸载，那么能不能把她妈给换了?也就是类加载器，答案是可以的，我们可以自定义类的加载器，并重写ClassLoader的findClass方法，然后热部署步骤就是：
- 销毁自定义ClassLoader(被该加载器加载的class也会自动卸载);
- 更新class
- 使用新的ClassLoader去加载class
最终落地到实现，其实就是将ClassLoader给覆盖掉，怎么覆盖，重新new一个同样的ClassLoader就可以了。
「总结一大波：我们虽然不能对被加载的class动手动脚，但是却可以对ClassLoader动手脚，搞掉它，然后使用新的ClassLoader加载class就可以了。」
那么什么时候回收掉老的类呢?毕竟替换了，就存在新旧问题了，也就存在内存泄露问题了。
通常情况下，在JSP，OSGI及其他一些支持热替换的库，都是需要进行类的卸载回收的，否则类在替换后，老的类就没用了但是还在内存中，就会造成内存泄漏。
类的卸载需要满足以下三个条件:
- 该类所有的实例都已经被GC，也就是JVM中不存在该Class的任何实例。
- 加载该类的ClassLoader已经被GC。
- 该类的java.lang.Class 对象没有在任何地方被引用，如不能在任何地方通过反射访问该类的方法。
所以在自定义类加载器时，就要注意这一点，如果你是希望其使用完成后就被卸载，那么就需要特别留意类加载器及类的作用域了。
原文链接：https://mp.weixin.qq.com/s/JT4Vh_tXzNAQdLSAosy2cQ
