JVM类加载机制
Java虚拟机把描述类的数据从Class文件加载到内存， 并对数据进行校验、 转换解析和初始化， 最终形成可以被虚拟机直接使用的Java类型， 这个过程被称作虚拟机的类加载机制。
1. 类加载的时机
一个类型从被加载到虚拟机内存中开始， 到卸载出内存为止， 它的整个生命周期将会经历加载（Loading） 、 验证（Verification） 、 准备（Preparation） 、 解析（Resolution） 、 初始化（Initialization） 、 使用（Using） 和卸载（Unloading） 七个阶段， 其中验证、 准备、 解析三个部分统称为连接（Linking） 。 这七个阶段的发生顺序如下图所示。
加载、 验证、 准备、 初始化和卸载这五个阶段的顺序是确定的， 类型的加载过程必须按照这种顺序按部就班地开始， 而解析阶段则不一定： 它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定特性（也称为动态绑定或晚期绑定） 。 请注意， 这里写的是按部就班地“开始”， 而不是按部就班地“进行”或按部就班地“完成”， 强调这点是因为这些阶段通常都是互相交叉地混合进行的， 会在一个阶段执行的过程中调用、 激活另一个阶段。
关于在什么情况下需要开始类加载过程的第一个阶段“加载”， 《Java虚拟机规范》 中并没有进行强制约束， 这点可以交给虚拟机的具体实现来自由把握。 但是对于初始化阶段， 《Java虚拟机规范》则是严格规定了有且只有六种情况必须立即对类进行“初始化”（而加载、 验证、 准备自然需要在此之前开始） ：
- 遇到
new、getstatic、putstatic或invokestatic这四条字节码指令时， 如果类型没有进行过初始化， 则需要先触发其初始化阶段。 能够生成这四条指令的典型Java代码场景有：- 使用new关键字实例化对象的时候
- 读取或设置一个类型的静态字段（被final修饰、 已在编译期把结果放入常量池的静态字段除外）的时候
- 调用一个类型的静态方法的时候
- 使用
java.lang.reflect包的方法对类型进行反射调用的时候， 如果类型没有进行过初始化， 则需要先触发其初始化 - 当初始化类的时候， 如果发现其父类还没有进行过初始化， 则需要先触发其父类的初始化
- 当虚拟机启动时， 用户需要指定一个要执行的主类（ 包含main()方法的那个类） ， 虚拟机会先初始化这个主类
- 当使用JDK 7新加入的动态语言支持时， 如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、 REF_putStatic、 REF_invokeStatic、 REF_newInvokeSpecial四种类型的方法句柄， 并且这个方法句柄对应的类没有进行过初始化， 则需要先触发其初始化。
- 当一个接口中定义了JDK 8新加入的默认方法（ 被default关键字修饰的接口方法） 时， 如果有这个接口的实现类发生了初始化， 那该接口要在其之前被初始化
接口的加载过程与类加载过程稍有不同，针对接口需要做一些特殊说明：接口也有初始化过程，这点与类是一致的， 编译器也会为接口生成“<clinit>()”类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是前面讲述的六种“有且仅有”需要触发初始化场景中的第三种：当一个类在初始化时， 要求其父类全部都已经初始化过了， 但是一个接口在初始化时， 并不要求其父接口全部都完成了初始化， 只有在真正使用到父接口的时候（如引用接口中定义的常量） 才会初始化。
概括得说，类初始化是【懒惰的】
- main 方法所在的类，总会被首先初始化
- 首次访问这个类的静态变量或静态方法时
- 子类初始化，如果父类还没初始化，会引发
- 子类访问父类的静态变量，只会触发父类的初始化
- Class.forName
- new 会导致初始化
不会导致类初始化的情况：
- 访问类的 static final 静态常量（基本类型和字符串）不会触发初始化
- 类对象.class 不会触发初始化
- 创建该类的数组不会触发初始化
- 类加载器的 loadClass 方法
测试代码：
class A {
static int a = 0;
static {
System.out.println("a init");
}
}
class B extends A {
final static double b = 5.0;
static boolean c = false;
static {
System.out.println("b init");
}
}
验证（测试时请先全部注释，每次只执行其中一个）
public class Load {
// main方法的所在类总会被先初始化
static {
System.out.println("main init");
}
public static void main(String[] args) throws ClassNotFoundException {
// 1. 静态常量（基本类型和字符串）不会触发初始化
System.out.println(B.b);
// 2. 类对象.class 不会触发初始化
System.out.println(B.class);
// 3. 创建该类的数组不会触发初始化
System.out.println(new B[0]);
// 4. 不会初始化类 B，但会加载 B、A
ClassLoader cl = Thread.currentThread().getContextClassLoader();
cl.loadClass("cn.itcast.jvm.t3.B");
// 5. 不会初始化类 B，但会加载 B、A
ClassLoader c2 = Thread.currentThread().getContextClassLoader();
Class.forName("cn.itcast.jvm.t3.B", false, c2);
// 1. 首次访问这个类的静态变量或静态方法时
System.out.println(A.a);
// 2. 子类初始化，如果父类还没初始化，会引发
System.out.println(B.c);
// 3. 子类访问父类静态变量，只触发父类初始化
System.out.println(B.a);
// 4. 会初始化类 B，并先初始化类 A
Class.forName("cn.itcast.jvm.t3.B");
}
}
2. 类加载的过程
JVM将类的加载分为3个步骤：
1、装载（Load）
2、链接（Link）
3、初始化（Initialize）
其中 链接（Link）又分3个步骤，如下图所示：
2.1 装载(Load)
“加载”（Loading） 阶段是整个“类加载”（Class Loading） 过程中的一个阶段， 希望读者没有混淆这两个看起来很相似的名词。 在加载阶段， Java虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表这个类的java.lang.Class对象， 作为方法区这个类的各种数据的访问入口
加载 .class 文件的方式：
- 本地系统获取
- 网络获取，Web Applet
- zip压缩包获取，jar，war
- 运行时计算生成，动态代理
- 有其他文件生成，jsp
- 专有数据库提取.class文件，比较少见
- 加密文件中获取，防止Class文件被反编译的保护措施
2.2 链接(Link)
(1) 验证(Varify)
验证是连接阶段的第一步， 这一阶段的目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》 的全部约束要求， 保证这些信息被当作代码运行后不会危害虚拟机自身的安全。
从整体上看， 验证阶段大致上会完成下面四个阶段的检验动作： 文件格式验证、 元数据验证、 字节码验证和符号引用验证
-
文件格式验证
- 是否以魔数
0xCAFEBABE开头。 - 主、次版本号是否在当前Java虚拟机接受范围之内。
- 常量池的常量中是否有不被支持的常量类型（检查常量tag标志） 。
- 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量。
- CONSTANT_Utf8_info型的常量中是否有不符合UTF-8编码的数据。
- Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。
- ……
- 是否以魔数
-
元数据验证
- 这个类是否有父类（除了java.lang.Object之外， 所有的类都应当有父类） 。
- 这个类的父类是否继承了不允许被继承的类（被final修饰的类） 。
- 如果这个类不是抽象类， 是否实现了其父类或接口之中要求实现的所有方法。
- 类中的字段、 方法是否与父类产生矛盾（例如覆盖了父类的final字段， 或者出现不符合规则的方法重载， 例如方法参数都一致， 但返回值类型却不同等）
- ……
-
字节码验证
-
通过数据流分析和控制流分析，确定程序语义是合法的，符合逻辑的。
-
对类的方法体，进行校验分析，保证在运行时不会做出危害虚拟机的行为
-
保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，不会出现类似于在操作数栈放了一个int类型的数据，使用时却按照long类型加载到本地变量表中的情况。
-
保障任何跳转指令都不会跳转到方法体之外的字节码指令上。
-
-
符号引用验证
- 通过字符串描述的全限定名是否能找到对应的类
- 符号引用中的类、字段、方法的可访问性是否可被当前类访问
(2) 准备(Prepare)
准备阶段是正式为类中定义的变量（即静态变量， 被static修饰的变量） 分配内存并设置类变量初始值的阶段。
关于准备阶段，还有两个容易产生混淆的概念笔者需要着重强调，首先是这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值， 假设一个类变量的定义为：
public static int value = 123;
那变量value在准备阶段过后的初始值为0而不是123， 因为这时尚未开始执行任何Java方法， 而把value赋值为123的putstatic指令是程序被编译后， 存放于类构造器<clinit>()方法之中， 所以把value赋值为123的动作要到类的初始化阶段才会被执行。 表7-1列出了Java中所有基本数据类型的零值。
上面提到在“通常情况”下初始值是零值， 那言外之意是相对的会有某些“特殊情况”： 如果类字段的字段属性表中存在ConstantValue属性， 那在准备阶段变量值就会被初始化为ConstantValue属性所指定的初始值， 假设上面类变量value的定义修改为：
public static final int value = 123;
编译时Javac将会为value生成ConstantValue属性， 在准备阶段虚拟机就会根据Con-stantValue的设置将value赋值为123。
总结：
- 为类变量分配内存，并且设置该类变量的初始值，即零值
- 不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显示初始化
- 不会为实例变量分配初始化，类变量会分配在方法区中，实例变量会随着对象一起分配到Java堆中
(3) 解析(Resolve)
解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程
事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
符号引用就是一组符号来描述引用的目标。符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中
直接引用就是直接指向目标的指针，相对偏移量或一个间接定位到目标的句柄
解析动作主要针对类，或接口，字段，类方法，接口方法，方法类型等。对应常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info
2.3 初始化(Initialization)
类的初始化阶段是类加载过程的最后一个步骤， 之前介绍的几个类加载的动作里， 除了在加载阶段用户应用程序可以通过自定义类加载器的方式局部参与外， 其余动作都完全由Java虚拟机来主导控制。 直到初始化阶段， Java虚拟机才真正开始执行类中编写的Java程序代码， 将主导权移交给应用程序
- 静态代码块、static 修饰的变量赋值、static final 修饰的引用类型变量赋值，会被合并成一个
<cinit>方法，在初始化时被调用 - static final 修饰的基本类型变量赋值，在链接阶段就已完成
静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如下程序：
public class Test {
static {
// 给变量赋值可以正常编译通过
i = 0;
// 这句编译器会提示"非法向前引用"
System.out.println(i);
}
static int i = 1;
}
<clinit>() 不需要显式调用父类（接口除外，接口不需要调用父接口的初始化方法，只有使用到父接口中的静态变量时才需要调用）的初始化方法 <clinit>()，虚拟机会保证在子类的 <clinit>() 方法执行之前，父类的 <clinit>() 方法已经执行完毕，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
<clinit>() 方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成 <clinit>() 方法。
虚拟机会保证一个类的 <clinit>() 方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的 <clinit>() 方法，其他线程都需要阻塞等待，直到活动线程执行 <clinit>() 方法完毕。
总结：
-
初始化阶段是执行类构造器方法<clinit>()的过程
-
此方法不需要定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来
-
非法的前向引用问题
-
如果没有类变量和静态代码块，也不会有clinit
-
-
构造器方法中指令按照语句在源文中出现的顺序执行
-
<clinit>()不同于类的构造器（关联：构造器是虚拟机视角下的<init>()）
-
若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕
-
虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁
3. 类加载器
Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现， 以便让应用程序自己决定如何去获取所需的类。 实现这个动作的代码被称为“类加载器”（Class Loader） 。
将 class 文件二进制数据放入方法区内，然后在堆内（heap）创建一个 java.lang.Class 对象，Class 对象封装了类在方法区内的数据结构，并且向开发者提供了访问方法区内的数据结构的接口。
目前类加载器却在类层次划分、OSGi、热部署、代码加密等领域非常重要，我们运行任何一个 Java 程序都会涉及到类加载器。
| 名称 | 加载哪的类 | 说明 |
|---|---|---|
| Bootstrap ClassLoader | JAVA_HOME/jre/lib | 无法直接访问 |
| Extension ClassLoader | JAVA_HOME/jre/lib/ext | 上级为 Bootstrap，显示为 null |
| Application ClassLoader | classpath | 上级为 Extension |
| 自定义类加载器 | 自定义 | 上级为 Application |
启动类加载器
- C/C++语言实现，嵌套JVM内部
- 用来加载Java核心类库，rt.jar,resources.jar,sun.boot.class.path路径下的内容
- 并不继承java.lang.ClassLoader，没有父加载器
- 加载扩展类和应用程序类加载器，并指定为他们的父类加载器
- 出于安全考虑，Bootstrap启动类加载器只加载包名为java\javax\sun等开头的类
扩展类加载器
- Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
- 派生于ClassLoader类
- 父类加载器为启动类加载器(非继承关系)
- 从java.ext.dirs系统属性所指定的目录中加载类库，或从jre/lib/ext子目录下加载类库
应用程序类加载器（系统类加载器）
- Java语言编写，由sun.misc.Launcher$AppClassLoader实现
- 派生于ClassLoader类
- 父类加载器为扩展类加载器
- 负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
- 该类加载器是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
- 通过ClassLoader#getSystemClassLoader（）方法可以后去到改类加载器
用户自定义类加载器
为什么要用自定义类加载器?
-
隔离加载类
例如使中间件的Jar包与应用程序Jar包不冲突
-
修改类加载的方式
启动类加载器必须使用，其他可以根据需要自定义加载
-
扩展加载源
-
防止源码泄露
对字节码进行加密，自定义类加载器实现解密
实现步骤
- 继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器
- 1.2之前，继承并重写loadClass方法，
- 1.2之后，建议把自定义的类加载逻辑写在findClass()方法中
- 如果没有太过复杂的需求，可以直接继承URLClassLoader类，可以避免自己编写findClass（）方法，及其获取字节码流的方式，使自定义类加载器编写更加简洁
public class ClassLoaderTest {
public static void main(String[] args) {
//获取系统类加载器
ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
System.out.println(systemClassLoader);
//获取其上层，扩展类加载器
ClassLoader extClassLoader = systemClassLoader.getParent();
System.out.println(extClassLoader);
//获取其上层：
ClassLoader bootstrapClassLoader = extClassLoader.getParent();
System.out.println(bootstrapClassLoader);
//对于用户自定义类来说
ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
System.out.println(classLoader);
}
}
/*
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$ExtClassLoader@14ae5a5
null
sun.misc.Launcher$AppClassLoader@18b4aac2
*/
类的唯一性和类加载器
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。
即使两个类来源于同一个 Class 文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类也不相等。
这里所指的“相等”，包括代表类的 Class 对象的 equals() 方法、 isAssignableFrom() 方法、isInstance() 方法的返回结果，也包括使用 instanceof 关键字做对象所属关系判定等情况。
双亲委派模型
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
这里类加载器之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。
Bootstrap 类加载器是用 C++ 实现的，是虚拟机自身的一部分，如果获取它的对象，将会返回 null；扩展类加载器和应用类加载器是独立于虚拟机外部，为 Java 语言实现的，均继承自抽象类 java.lang.ClassLoader ，开发者可直接使用这两个类加载器。
Application 类加载器对象可以由 ClassLoader.getSystemClassLoader() 方法的返回，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
双亲委派模型对于保证 Java 程序的稳定运作很重要，例如类 java.lang.Object，它存放在 rt.jar 之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此 Object 类在程序的各种类加载器环境中都是同一个类。
双亲委派模型的加载类逻辑可参考如下代码：
// 代码摘自《深入理解Java虚拟机》
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
// 首先，检查请求的类是否已经被加载过了
Class c = findLoadedClass(name);
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器抛出ClassNotFoundException
// 说明父类加载器无法完成加载请求
}
if (c == null) {
// 在父类加载器无法加载的时候
// 再调用本身的findClass方法来进行类加载
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
优势:
- 避免类的重复加载
- 保护程序安全，防止核心API被篡改
沙箱安全机制: 保证对Java核心源代码的保护
参考：
《深入理解Java虚拟机(第三版)》
2602
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
