Java类加载机制&双亲委派机制
关键知识点提炼：
- 类的唯一性：类的实例= 类加载器 ➕全限定类名 （扩展pandora容器隔离原理-类加载器隔离）
- 类加载过程：家(加)宴(验)准备了西(析)式菜。 加载-验证-准备-解析-初始化
- 双亲委派机制&其解决的问题：Java类随着它的加载器一起具备了一种带有优先级的层次关系（当一个类加载的过程中，它首先不会去加载，而是委托给自己的父类去加载，父类又委托给自己的父类），通过这种层次模型，可以避免类的重复加载，也可以避免核心类被不同的类加载器加载到内存中造成冲突和混乱，从而保证了Java核心库的安全。
- 反双亲委派机制：每个中间件先从自己的classpath 路径下加载类，加载不到时才委派给父加载器加载，保证加载到的三方jar中的类是自己应用lib目录下依赖的版本，解决不同中间件依赖同一个库的不同版本冲突问题（pandora容器隔离原理)
- classloader的应用场景：1.解决依赖冲突 2.热加载/热部署 3.jar包的加密
类加载过程
1. 类加载阶段分为加载、连接、初始化三个阶段，而加载阶段需要通过类的全限定名来获取定义了此类的二进制字节流。Java特意把这一步抽出来用类加载器来实现。把这一步骤抽离出来使得应用程序可以按需自定义类加载器。并且得益于类加载器，OSGI、热部署等领域才得以在JAVA中得到应用。
在Java中任意一个类都是由这个类本身和加载这个类的类加载器来确定这个类在JVM中的唯一性。也就是你用你A类加载器加载的com.aa.ClassA和你A类加载器加载的com.aa.ClassA它们是不同的，也就是用instanceof这种对比都是不同的。所以即使都来自于同一个class文件但是由不同类加载器加载的那就是两个独立的类。
从类加载到虚拟机到卸载出虚拟机的这一整个生命周期总共可以分为7个步骤，分别为加载、验证、准备、解析、初始化、使用和卸载，其中验证、准备和解析又称为连接阶段。
加载是“类加载”的第一个阶段，就是将需要用到的类对应的.class字节码文件加载到虚拟机内存，并在方法区中生成一个java.lang.Class对象，作为程序访问这个类的各种数据的访问入口。
public class Test {
public static void main(String[] args) {
User user = new User();
}
}
看一下上面这段代码，经过编译会生成两个字节码文件Test.class和User.class，接着会将包含main方法的这个类加载到虚拟机内存中开始执行，当执行到User user = new User()，发现需要用到User类，就会将User.class加载到内存中。所以简单的说，当需要用到哪个类时，就回去加载哪个类，Java的自带的核心类会在虚拟机启动时就会加载，包括包含main方法的启动类。
第二阶段验证，从字面上就可以看出这个阶段是来校验加载进来的.class文件中的内容是否符合规范，毕竟编译成.class文件后还是可以人为的对这个文件进行修改，那如果改的乱七八糟，压根不符合虚拟机的规范，那虚拟机就没法执行了。
准备阶段引用《深入理解Java虚拟机》中的一句话：准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这也比较好理解，看下面一段代码：
public class Test {
public static int value = 10;
}
当需要用到这个类时，会先将这个类加载到内存中，并验证字节码文件的合法性。验证通过后就会进行准备工作了，会为这个类中的类变量分配内存空间，就是上面的value变量，并给一个初始值。
注意，仅包括类变量，不包括实例变量和局部变量等，并且只是给一个初始值，int型的初始值是0，所以准备过后，value的值是0，而不是10，而真正赋值为10是在初始化阶段。我还在其它资料上看到，这一阶段也会给这个类分配内存空间，先给类分配内存，在给它里面的类变量分配内存。
解析阶段是将常量池中的符号引用替换为直接引用的过程。
初始化阶段是类加载中核心的一步了，还是以上面的代码为例，准备阶段我们已经为value变量分配了内存空间并给了初始值，现在就是真正给value赋值的时候，把10赋给了value。如果类中还含有静态代码块，也会在这一阶段执行。这里还要一点要注意，初始化类的时候，如果父类还没加载和初始化，也会触发父类的加载和初始化。
使用就没什么好说了，初始化完就可以开始使用这个对象了。
卸载是类的生命周期中的最后一阶段，即将方法区中无用的类回收，而类需要同时满足下面3个条件才算无用的类：
-
该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例。
-
加载该类的ClassLoader已经被回收。
-
该类对应的
java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
同时满足上述3个条件的类即可回收，但不一定就会回收，可通过参数配置。
加载流程：
双亲委派机制：
classloader的双亲委托机制是指多个类加载器之间存在父子关系的时候，某个class类具体由哪个加载器进行加载的问题。其具体的过程表现为：当一个类加载的过程中，它首先不会去加载，而是委托给自己的父类去加载，父类又委托给自己的父类。因此所有的类加载都会委托给顶层的父类，即Bootstrap Classloader进行加载，然后父类自己无法完成这个加载请求，子加载器才会尝试自己去加载。
使用双亲委派模型好处：
Java类随着它的加载器一起具备了一种带有优先级的层次关系，就拿java.lang.Object来说，你加载它经过一层层委托最终是由Bootstrap ClassLoader来加载的，也就是最终都是由Bootstrap ClassLoader去找java.lang.Object加载到JVM中。
通过这种层次模型，可以避免类的重复加载，也可以避免核心类被不同的类加载器加载到内存中造成冲突和混乱，从而保证了Java核心库的安全。
整个java虚拟机的类加载层次关系：
1、启动类加载器(Bootstrap ClassLoader),它是属于虚拟机自身的一部分，用C++实现的，主要负责加载
2、扩展类加载器(Extension ClassLoader),它是Java实现的，独立于虚拟机，主要负责加载
3、应用程序类加载器(Application ClassLoader),它是Java实现的，独立于虚拟机。主要负责加载用户类路径(classPath)上的类库，它负责加载用户路径(ClassPath)上所指定的类库。我们自己编写的代码以及使用的第三方的jar包都是由它来加载的。如果我们没有实现自定义的类加载器那这玩意就是我们程序中的默认加载器。
双亲委派的意思是如果一个类加载器需要加载类，那么首先它会把这个类请求委派给父类加载器去完成，每一层都是如此。一直递归到顶层，当父加载器无法完成这个请求时，子类才会尝试去加载。这里的双亲其实就指的是父类，没有mother。父类也不是我们平日所说的那种继承关系，只是调用逻辑是这样。
核心源码：
classloader应用场景
1. 依赖冲突解决
基于maven的pom进制可以方便的进行依赖管理，但是由于maven依赖的传递性，会导致我们的依赖错综复杂，这样就会导致引入类冲突的问题。最典型的就是NoSuchMethodError错误
- 问题描述：
某个业务引用了消息中间件(例如metaq)和微服务中间件(例如dubbo)，这两个中间件也同时引用了fastjson-2.0和fastjson-3.0版本，而业务自己本身也引用了fastjson-1.0版本。这三个版本表现不同之处在于classA类中方法数目不相同，我们根据maven依赖处理的机制，引用路径最短的fastjson-1.0会真正作为应用最终的依赖，其它两个版本的fastjson则会被忽略，那么中间件在调用method2()方法的时候，则会抛出方法找不到异常。或许你会说，将所有依赖fastjson的版本都升级到3.0不是就能解解决问题吗？确实这样能够解决问题，但是在实际操作中不太现实，首先，中间件团队和业务团队之间并不是一个团队，并不能做到高效协同，其次是中间件的稳定性是需要保障的，不可能因为包冲突问题，就升级版本，更何况一个中间件依赖的包可能有上百个，如果纯粹依赖包升级来解决，不仅稳定性难以保障，排包耗费的时间恐怕就让人窒息了。
- 解决方法：
那如何解决包冲突的问题呢？答案就是pandora(潘多拉)，通过自定义类加载器，为每个中间件自定义一个加载器，这些加载器之间的关系是平行的，彼此没有依赖关系。这样每个中间件的classloader就可以加载各自版本的fastjson。因为一个类的全限定名以及加载该类的加载器两者共同形成了这个类在JVM中的惟一标识，这也是阿里pandora实现依赖隔离的基础。
但是根据双亲委托模型，App Classloader分别继承了Custom Classloader.那么业务包中的fastjson的class在加载的时候，会先委托到Custom ClassLoader。这样不就会导致自身依赖的fastjson版本被忽略吗？确实如此，所以潘多拉又是如何做的呢？
潘多拉实现方式：
首先每个中间件对应的ModuleClassLoader在加载中间对应的class文件的同时，根据中间件配置的export.index负责将要需要透出的class(主要是中间件api接口的相关类)索引到exportedClassHashMap中，然后应用程序的类加载器会持有这个exportedClassHashMap，因此应用程序代码在loadClass的时候，会优先判断exportedClassHashMap是否存在当前类，如果存在，则直接返回，如果不存在，则再使用传统的双亲委托机制来进行类加载。这样中间件MoudleClassloader不仅实现了中间件的加载，也实现了中间件关键服务类的透出。
应用程序加载过程：
2. 热加载
在开发项目的时候，我们需要频繁的重启应用进行程序调试，但是java项目的启动少则几十秒，多则几分钟。如此慢的启动速度极大地影响了程序开发的效率，那是否可以快速的进行启动，进而能够快速的进行开发验证呢？答案也是肯定的，通过classloader我们可以完成对变更内容的加载，然后快速的启动。
常用的热加载方案有好几个，接下来我们介绍下spring官方推荐的热加载方案，即spring boot devtools。
首先我们需要思考下，为什么重新启动一个应用会比较慢，那是因为在启动应用的时候，JVM虚拟机需要将所有的应用程序重新装载到整个虚拟机。可想而知，一个复杂的应用程序所包含的jar包可能有上百兆，每次微小的改动都是全量加载，那自然是很慢了。那么我们是否可以做到，当我们修改了某个文件后，在JVM中替换到这个文件相关的部分而不全量的重新加载呢？而spring boot devtools正是基于这个思路进行处理的。
通常一个项目的代码由以上四部分组成，即基础类、扩展类、二方包/三方包、以及我们自己编写的业务代码组成。上面的一排是我们通常的类加载结构，其中业务代码和二方包/三方包是由应用加载器加载的。而实际开发和调试的过程中，主要变化的是业务代码，并且业务代码相对二方包/三方包的内容来说会更少一些。因此我们可以将业务代码单独通过一个自定义的加载器Custom Classloader来进行加载，当监控发现业务代码发生改变后，我们重新加载启动，老的业务代码的相关类则由虚拟机的垃圾回收机制来自动回收。其工程流程大概如下
RestartClassLoader为自定义的类加载器，其核心是loadClass的加载方式，我们发现其通过修改了双亲委托机制，默认优先从自己加载，如果自己没有加载到，从从parent进行加载。这样保证了业务代码可以优先被RestartClassLoader加载。进而通过重新加载RestartClassLoader即可完成应用代码部分的重新加载。
3. 热部署
热部署本质其实与热加载并没有太大的区别，通常我们说热加载是指在开发环境中进行的classloader加载，而热部署则更多是指在线上环境使用classloader的加载机制完成业务的部署。所以这二者使用的技术并没有本质的区别。那热部署除了与热加载具有发布更快之外，还有更多的更大的优势就是具有更细的发布粒度。我们可以想像以下的一个业务场景。
假设某个营销投放平台涉及到4个业务方的开发，需要对会场业务进行投放。而这四个业务方的代码全部都在一个应用里面。因此某个业务方有代码变更则需要对整个应用进行发布，同时其它业务方也需要跟着回归。因此每个微小的发动，则需要走整个应用的全量发布。这种方式带来的稳定性风险估且不说，整个发布迭代的效率也可想而知了。这在整个互联网里，时间和效率就是金钱的理念下，显然是无法接受的。
那么我们完全可以通过类加载机制，将每个业务方通过一个classloader来加载。基于类的隔离机制，可以保障各个业务方的代码不会相互影响，同时也可以做到各个业务方进行独立的发布。其实在移动客户端，每个应用模块也可以基于类加载，实现插件化发布。本质上也是一个原理。
在阿里内部像阿拉丁投放平台，以及crossbow容器化平台，本质都是使用classloader的热加载技术，实现业务细粒度的开发部署以及多应用的合并部署。
4. 加密保护
众所周期，基于java开发编译产生的jar包是由.class字节码组成，由于字节码的文件格式是有明确规范的。因此对于字节码进行反编译，就很容易知道其源码实现了。因此大致会存在如下两个方面的诉求。例如在服务端，我们向别人提供三方包实现的时候，不希望别人知道核心代码实现，我们可以考虑对jar包进行加密，在客户端则会比较普遍，那就是我们打包好的apk的安装包，不希望被人家反编译而被人家翻个底朝天，我们也可以对apk进行加密。
jar包加密的本质，还是对字节码文件进行操作。但是JVM虚拟机加载class的规范是统一的，因此我们在最终加载class文件的时候，还是需要满足其class文件的格式规范，否则虚拟机是不能正常加载的。因此我们可以在打包的时候对class进行正向的加密操作，然后，在加载class文件之前通过自定义classloader先进行反向的解密操作，然后再按照标准的class文件标准进行加载，这样就完成了class文件正常的加载。因此这个加密的jar包只有能够实现解密方法的classloader才能正常加载。
加密过程：
这样整个jar包的安全性就有一定程度的提高，至于更高安全的保障则取决于加密算法的安全性了以及如何保障加密算法的密钥不被泄露的问题了。这有种套娃的感觉，所谓安全基本都是相对的。并且这些方法也不是绝对的，例如可以通过对classloader进行插码，对解密后的class文件进行存储；另外大多数JVM本身并不安全，还可以修改JVM，从ClassLoader之外获取解密后的代码并保存到磁盘，从而绕过上述加密所做的一切工作，当然这些操作的成本就比单纯的class反编译就高很多了。所以说安全保障只要做到使对方破解的成本高于收益即是安全，所以一定程度的安全性，足以减少很多低成本的攻击了。