JVM类加载机制
JVM类加载机制
1、类的加载含义
虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
类加载最终生成的是位于堆区中的 Class对象， Class对象封装了类在方法区内的数据结构，并且向Java程序员提供了访问方法区内的数据结构的接口。
在Java语言里面，类型的加载、连接和初始化过程都是在程序运行期间完成的，这种策略虽然会令加载时稍微增加一些性能开销，但是会为Java应用程序提供高度的灵活性，Java天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
例如：
- 面向接口编程时，可以等到运行时再指定其实际的实现类；
- 应用程序可以在运行时从网络或其他地方加载一个二进制流作为程序代码的一部分；
2、类的加载过程
类从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段。其中验证、准备、解析3个阶段统称为连接（Linking），这7个阶段的发生顺序如图1所示：
图1.类的生命周期
其中类加载的过程包括了加载、验证、准备、解析、初始化五个阶段。在这五个阶段中，加载、验证、准备和初始化这四个阶段发生的顺序是确定的，而解析阶段则不一定，它在某些情况下可以在初始化阶段之后开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。另外注意这里的几个阶段是按顺序开始，而不是按顺序进行或完成，因为这些阶段通常都是互相交叉地混合进行的，通常在一个阶段执行的过程中调用或激活另一个阶段。
2.1.加载
“加载”是“类加载”（Class Loading）过程的一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
- 通过一个类的全限定名来获取其定义的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在Java堆中生成一个代表这个类的 java.lang.Class对象，作为对方法区中这些数据的访问入口。
加载类的方式：
- 从本地系统中直接加载
- 从网络中读取，如Applet
- 从zip，jar，war等压缩文件中加载.class文件
- 从专有数据库中读取.class文件
- 由其他文件生成，如通过JSP文件生成Class类
- 运行时计算生成，如动态代理技术
加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载（即重写一个类加载器的loadClass()方法）。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，然后在Java堆中也创建一个 java.lang.Class类的对象（对于HotSpot虚拟机，Class对象存放在方法区中），这样便可以通过该对象访问方法区中的数据。
加载阶段和连接阶段的部分内容是交叉进行的，加载尚未完成，连接阶段可能已经开始，但这两个阶段的开始时间仍然保持着固定的先后顺序。
关于数组类：
数组类本身由java虚拟器直接创建，数组类的元素类型最终靠类加载器去创建。
2.2.验证
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
虚拟机如果不检车加载类时输入的字节流，对其完全信任的话，很可能因为载入有害的字节流而导致系统崩溃，所以验证是虚拟机对自身的一种保护。
验证阶段大致上分为以下4个检验动作：
（1）文件格式验证
验证字节流是否符合Class文件格式的规范；
- 是否以 0xCAFEBABE开头
- 主次版本号是否在当前虚拟机的处理范围之内
- 常量池中的常量是否有不被支持的类型，等等
（2）元数据验证
对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；
- 这个类是否有父类（除了java.lang.Object之外，所有的类都有父类）
- 这个类的父类是否继承了不允许被继承的类（被final修饰的类）
- 类中的字段、方法是否与父类产生了矛盾，等等
（3）字节码验证
通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的；
- 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
- 保证跳转指令不会跳转到方法体以外的字节码指令上
- 保证方法体中的类型转换是有效的，等等
（4）符号引用验证
该校验发生在虚拟机将符号引用转化为直接引用的时候——解析阶段中发生，可以看做是对类自身以外的信息进行匹配性校验，目的是为了确保解析动作能正常执行；
- 符号引用中通过字符串描述的全限定名是否能找到对应的类
- 引用类中是否存在被描述的方法和字段
- 引用中的类、字段、方法是否能被当前类访问，等等
验证阶段很重要，但不一定必要（对程序运行期没有影响）；如果不需要验证，那么可以考虑采用 -Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
2.3.准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量使用的内存都将在方法区中分配。
需要注意的是：
- 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中
- 这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值
- 如果类字段的字段属性表中存在 ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值
例1：public static int value=3
变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的 public static指令是在程序编译后，存放于类构造器
例2：public static final int value=3
编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据 ConstantValue的设置将value赋值为3。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中
2.4.解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
符号引用：以一组符号来描述引用的目标，符号可以是任何形式的字面量，只要使用时能准确无歧义的定位到目标即可。
直接引用：直接引用可以使直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。
解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
2.5.初始化
在初始化阶段，才开始真正执行类中定义的代码。在准备阶段，变量已经赋值过一次系统要求的初始值，而在初始化阶段，则根据程序中的设计进行初始化类变量和其他资源。
初始化阶段实际上是执行类构造器
()方法是由编译器自动收集类中的所有变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序由语句在源文件的顺序决定。 ()方法与类的构造方法不同，它不要显示地调用父类构造器，虚拟机会保证子类的 ()方法方法执行之前先执行父类的 ()方法。 ()方法对于类或者接口来说不是必需的，如果类中没有静态语句块和变量赋值操作，那么编译器可以不为这个类生成 ()方法。 - 执行接口的
()方法不需要先执行父接口的 ()方法，只有当父接口的变量使用时，父接口才会初始化。接口的实现类在初始化时也不会执行接口的 ()方法。 - 虚拟机会保证一个类的
()方法在多线程环境下中被正确的加锁、同步。
类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：
- 创建类的实例，也就是new的方式
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（如 Class.forName(“com.shengsiyuan.Test”)）
- 初始化某个类的子类，则其父类也会被初始化
- Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类
2.6.结束生命周期
在如下几种情况下，Java虚拟机将结束生命周期
- 执行了 System.exit()方法
- 程序正常执行结束
- 程序在执行过程中遇到了异常或错误而异常终止
- 由于操作系统出现错误而导致Java虚拟机进程终止
3、类加载器
类加载器主要实现在类加载阶段中通过一个类的全限定名来获取描述此类的二进制字节流的功能。
对于任何一个类，都需要由加载它的类加载器和它自身一同确立其在Java虚拟器中的唯一性，每个类加载器都有一个独立的类名称空间。同一个类在不同类加载器中是不相等的。这里的相等指的是equal()方法、isAssignableFrom()方法、isInstance()方法、instanceof()的返回结果。
系统提供的三种类加载器：
- 启动加载器（Bootstrap ClassLoader）：负责加载存放在
\lib目录下，或被 -Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被 BootstrapClassLoader加载）。启动类加载器是无法被Java程序直接引用的。 - 扩展类加载器（Extension ClassLoader）：该加载器由 sun.misc.Launcher$ExtClassLoader实现，它负责加载存放在
\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。 - 应用程序类加载器（Application ClassLoader）：该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：
- 在执行非置信代码之前，自动验证数字签名。
- 动态地创建符合用户特定需要的定制化构建类。
- 从特定的场所取得java class，例如数据库中和网络中。
4、双亲委派模型
（1）双亲委派模型结构
双亲委派模型不是一种强制性的约束模型，而是Java设计者推荐给开者的一种类加载器实现方式。
图2.累加载器双亲委派模型
图2中展示的类加载器之间的这种层次关系，称为类加载器的双亲委派模型（parents Delegation Model）。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的父子关系一般不会以继承的关系来实现，而是通过组合关系来复用父加载器的代码。
（2）双亲委派模型工作过程：
当类加载器收到了类加载请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一层的类加载都是如此，因此所有的加载请求最终都会传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。
（3）使用双亲委派模型的好处：
Java类随着它的类加载器一起具备了带有优先级的层次关系，可防止多个类加载器中重复加载同一个类。
（4）双亲委派模型的实现：
public Class loadClass(String name)throws ClassNotFoundException {
return loadClass(name, false);
}
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 {
//如果不存在父类加载器，就检查是否是由启动类加载器加载的类，通过调用本地方法native Class findBootstrapClass(String name)
c = findBootstrapClass0(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能
c = findClass(name);
}
}
if (resolve) {
resolveClass(c);
}
return c;
}5、自定义类加载器
通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。自定义类加载器一般都是继承自 ClassLoader类，从上面对 loadClass方法来分析来看，我们只需要重写 findClass 方法即可。下面我们通过一个示例来演示自定义类加载器的流程：
package com.neo.classloader;
import java.io.*;
public class MyClassLoader extends ClassLoader {
private String root;
protected Class findClass(String name) throws ClassNotFoundException {
byte[] classData = loadClassData(name);
if (classData == null) {
throw new ClassNotFoundException();
} else {
return defineClass(name, classData, 0, classData.length);
}
}
private byte[] loadClassData(String className) {
String fileName = root + File.separatorChar
+ className.replace('.', File.separatorChar) + ".class";
try {
InputStream ins = new FileInputStream(fileName);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int bufferSize = 1024;
byte[] buffer = new byte[bufferSize];
int length = 0;
while ((length = ins.read(buffer)) != -1) {
baos.write(buffer, 0, length);
}
return baos.toByteArray();
} catch (IOException e) {
e.printStackTrace();
}
return null;
}
public String getRoot() {
return root;
}
public void setRoot(String root) {
this.root = root;
}
public static void main(String[] args) {
MyClassLoader classLoader = new MyClassLoader();
classLoader.setRoot("E:\\temp");
Class testClass = null;
try {
testClass = classLoader.loadClass("com.neo.classloader.Test2");
Object object = testClass.newInstance();
System.out.println(object.getClass().getClassLoader());
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
}自定义类加载器的核心在于对字节码文件的获取，如果是加密的字节码则需要在该类中对文件进行解密。由于这里只是演示，我并未对class文件进行加密，因此没有解密的过程。
这里有几点需要注意：
- 这里传递的文件名需要是类的全限定性名称，即 com.paddx.test.classloading.Test格式的，因为 defineClass 方法是按这种格式进行处理的。
- 最好不要重写loadClass方法，因为这样容易破坏双亲委托模式。
- 这类Test 类本身可以被 AppClassLoader类加载，因此我们不能把 com/paddx/test/classloading/Test.class放在类路径下。否则，由于双亲委托机制的存在，会直接导致该类由 AppClassLoader加载，而不会通过我们自定义类加载器来加载。