玩转类加载与类加载器

类生命周期 7 个阶段

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7 个阶段。其中验证、准备、解析 3 个部分统称为连接。

阶段顺序

加载、校验、准备、初始化和卸载这五个阶段的顺序是确定的，但是对于“解析”阶段则不一定，它在某些情况下可以在初始化之后再开始，这样做是 为了支持 java 的运行时绑定特征（也称为动态绑定或晚期绑定）。

加载的时机

加载阶段虚拟机需要完成以下 3 件事情：
1）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

验证

是连接阶段的第一步，这一阶段的目的是为了确保 Class 文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。但从整体 上看，验证阶段大致上会完成下面 4 个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、 但却不是必须要执行的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证， 其后就对程序运行期没有任何影响了。如果程序运行的全部代码(包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码)都已经被反复 使用和验证过，在生产环境的实施阶段就可以考虑使用-Xverify:none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类中定义的变量（被 static 修饰的变量）分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。 这个阶段中有两个容易产生混淆的概念需要强调一下： 首先，这时候进行内存分配的仅包括类变量（被 static 修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。 其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：
public static int value=123； 那变量 value 在准备阶段过后的初始值为 0 而不是 123，因为这时候尚未开始执行任何 Java 方法，而把 value 赋值为 123 是后续的初始化环节。

解析

解析阶段是 JVM 将常量池内的符号引用替换为直接引用的过程。

初始化

1）遇到 new、getstatic、putstatic 或 invokestatic 这 4 条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这 4 条指令的最常见的 Java 代码场景是： 
使用 new 关键字实例化对象的时候。 
读取或设置一个类的静态字段（被 final 修饰、已在编译期把结果放入常量池的静态字段除外）的时候 
调用一个类的静态方法的时候。
2）使用 java.lang.reflect 包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
4）当虚拟机启动时，用户需要指定一个要执行的主类（包含 main（）方法的那个类），虚拟机会先初始化这个主类。
5）当使用 JDK1.7 的动态语言支持时，如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic 的方法 句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化。
6）当一个接口中定义了 JDK1.8 新加入的默认方法（被 default 关键字修饰的接口方法）时，如果这个接口的实现类发生了初始化，那该接口要在其之前 被初始化。

JDK 提供的三层类加载器

BootstrapClassLoader
这是加载器中的扛把子，任何类的加载行为，都要经它过问。它的作用是加载核心类库，也就是 rt.jar、resources.jar、charsets.jar 等

ExtentionClassLoader
扩展类加载器，主要用于加载 lib/ext 目录下的 jar 包和 .class 文件

ApplicationClassLoader
这是我们写的 Java 类的默认加载器，有时候也叫作 SystemClassLoader。一般用来加载 classpath 下的其他所有 jar 包和 .class 文件。

打破双亲委派机制

Tomcat 类加载机制

对于一些需要加载的非基础类，会由一个叫作 WebAppClassLoader 的类加载器优先加载。等它加载不到的时候，再交给上层的 ClassLoader 进行加载。 这个加载器用来隔绝不同应用的 .class 文件，比如你的两个应用，可能会依赖同一个第三方的不同版本，它们是相互没有影响的。

如何在同一个 JVM 里，运行着不兼容的两个版本，当然是需要自定义加载器才能完成的事。 那么 tomcat 是怎么打破双亲委派机制的呢？可以看图中的 WebAppClassLoader，它加载自己目录下的 .class 文件，并不会传递给父类的加载器。

SPI

线程的上下文类加载器