JVM笔记 -- 类加载机制
类的生命周期
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接。在一般情况下，它们开始的顺序如上图所示。当然，在某些特定情况下，为了支持Java语言的动态绑定的特性，解析阶段可以在初始化阶段之后开始。（注：是按序开始，它们的执行通常都是互相交叉地混合进行的）
加载
- 通过一个类的权限定名来获取定义此类的二进制字节流。
- 将这个字节流所代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
- 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
需要注意的是，数组类是由 Java 虚拟机直接生成的，没有加载这个步骤。(单指数组对象，而不是数组对象中存的其他类型的对象）。
连接
验证
验证是连接的一部分，其目的是确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。这阶段大致上会完成下面4个阶段的校验动作：
- 文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前虚拟机处理。
- 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。
- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑。
- 符号引用验证：确保解析动作能正常执行（发生于解析阶段虚拟机将符号引用转为直接引用时）
准备
准备阶段是在方法区为类变量（static修饰的变量）分配内存并设置类变量初始值的阶段。需要注意的是，这里说的类变量并不包括引用对象，指的是基本类型的变量及引用变量。
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
- 符号引用（Symbolic References）：以一组符号来描述所引用的目标，符号可以是任何形式的字面量。在运行阶段，这个符号引用一般都能够无歧义地定位到具体目标上。举例来说，对于一个方法调用，编译器会生成一个包含目标方法所在类的名字、目标方法的名字、接收参数类型以及返回值类型的符号引用，来指代所要调用的方法。
- 直接引用（Direct Refences）：可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经存在于内存中，即如果符号引用指向一个未被加载的类，或者未被加载类的字段或方法，那么解析将触发这个类的加载
初始化
初始化是为标记为常量值（static final）的字段赋值，以及执行 < clinit > 方法的过程。Java 虚拟机会通过加锁来确保类的 < clinit > 方法仅被执行一次。
在 Java 代码中，如果要初始化一个静态字段，我们可以在声明时直接赋值，也可以在静态代码块中对其赋值。
如果直接赋值的静态字段被 final 所修饰，并且它的类型是基本类型或字符串时，那么该字段便会被 Java 编译器标记成常量值（ConstantValue），其初始化直接由 Java 虚拟机完成。除此之外的直接赋值操作，以及所有静态代码块中的代码，则会被 Java 编译器置于同一方法中，并把它命名为 < clinit >。
类加载器
类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用远远不限于加载阶段。对于任意一个类来说，它的唯一性是由它本身及加载它的类加载器确定的。换句话来说就是，即使有两个类是由同一个Class文件分别被同一个虚拟机中的不同类加载器加载的，那么这两个类必定也不相等。
虚拟机提供的类加载器可以划分为3种，它们的层级结构如上图所示
- 启动类加载器（Bootstrap ClassLoader）：由C++语言实现的，负责加载最为基础、重要的类，比如存放在 JRE 的 lib 目录下 jar 包中的类（以及由虚拟机参数 -Xbootclasspath 指定的类）。启动类加载器无法被Java程序直接引用，用户在编写自定义加载器时，如果需要把加载请求委派给启动类加载器，那直接使用null代替即可。
- 扩展类加载器（Extension ClassLoader）：启动类加载器的子类加载器，它负责加载相对次要、但又通用的类，比如存放在 JRE 的 lib/ext 目录下 jar 包中的类（以及由系统变量 java.ext.dirs 指定的类）。
- 应用程序加载器（Application ClassLoader）：扩展类加载器的子类加载器，它负责加载应用程序路径下的类。（这里的应用程序路径，便是指虚拟机参数 -cp/-classpath、系统变量 java.class.path 或环境变量 CLASSPATH 所指定的路径。）如果应用程序没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
自定义累加载器
自定义类加载器需要继承ClassLoader类，重写findClass方法
import java.io.InputStream;
public class MyClassLoader extends ClassLoader
{
public MyClassLoader() { }
public MyClassLoader(ClassLoader parent) {
super(parent);
}
@Override
protected Class findClass(String name) throws ClassNotFoundException {
//1. 覆盖findClass，来找到.class文件，并且返回Class对象
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream is = getClass().getResourceAsStream(fileName);
if (is == null) {
//2. 如果没找到，return null
return null;
}
byte[] b = new byte[is.available()];
is.read(b);
//3. 讲字节数组转换成了Class对象
return defineClass(name, b, 0, b.length);
}
catch (Exception e) {
e.printStackTrace();
}
return null;
}
public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
// 不设置父加载器，默认为应用程序类加载器
MyClassLoader mcl = new MyClassLoader();
System.out.println("MyClassLoader父类加载器：" + mcl.getParent().getClass());
Class c1 = Class.forName("test.classloader.Test", true, mcl);
Object obj = c1.newInstance();
System.out.println("加载实例的加载器：" + obj.getClass().getClassLoader());
System.out.println(obj instanceof Test);
System.out.println("=============================");
// 设置父加载器为扩展类加载器
MyClassLoader mc2 = new MyClassLoader(ClassLoader.getSystemClassLoader().getParent());
System.out.println("MyClassLoader父类加载器：" + mc2.getParent().getClass());
Class c2 = Class.forName("test.classloader.Test", true, mc2);
Object obj2 = c2.newInstance();
System.out.println("加载实例的加载器：" + obj2.getClass().getClassLoader());
System.out.println(obj2 instanceof Test);
}
}输出为
MyClassLoader父类加载器：class sun.misc.Launcher$AppClassLoader
加载实例的加载器：sun.misc.Launcher$AppClassLoader@7d4991ad
true
=============================
MyClassLoader父类加载器：class sun.misc.Launcher$ExtClassLoader
加载实例的加载器：test.classloader.MyClassLoader@135fbaa4
false
在这里先看设置父加载器为扩展类加载类的，输出的加载器类为MyClassLoader，说明我们定义的类加载器确实是生效了。至于其他的输出就要了解下类加载的双亲委派机制了。
双亲委派模型
类加载器的双亲委派模型定义类加载器间的层级关系。它要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。而这些类加载器间的父子关系一般不会以继承的关系来实现，而是使用组合关系来复用弗雷加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到了类的加载请求，他首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层级的加载器都是如此，因此请求最终会到启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时（它的搜索范围中没有找到所需的类），子加载器才会尝试去自己加载。其源码如下
protected Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，检查类是否加载过
Class c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
// 如果没被加载，且不是启动类加载器，调用父类加载器加载
c = parent.loadClass(name, false);
} else {
// parent为null,即代表是启动类加载器，就用BootstrapClassLoader去加载
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// ClassNotFoundException thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// 如果父类加载器没找到，调用当前加载器findClass
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}知道了双亲委派模型是怎么工作的，我们再回过头来看看那段代码。
// 不设置父加载器，默认为应用程序类加载器
MyClassLoader mcl = new MyClassLoader();
System.out.println("MyClassLoader父类加载器：" + mcl.getParent().getClass());
Class c1 = Class.forName("test.classloader.Test", true, mcl);
Object obj = c1.newInstance();
System.out.println("加载实例的加载器：" + obj.getClass().getClassLoader());
System.out.println(obj instanceof Test);
System.out.println("=============================");
// 设置父加载器为扩展类加载器
MyClassLoader mc2 = new MyClassLoader(ClassLoader.getSystemClassLoader().getParent());
System.out.println("MyClassLoader父类加载器：" + mc2.getParent().getClass());
Class c2 = Class.forName("test.classloader.Test", true, mc2);
Object obj2 = c2.newInstance();
System.out.println("加载实例的加载器：" + obj2.getClass().getClassLoader());
System.out.println(obj2 instanceof Test);MyClassLoader父类加载器：class sun.misc.Launcher$AppClassLoader
加载实例的加载器：sun.misc.Launcher$AppClassLoader@7d4991ad
true
=============================
MyClassLoader父类加载器：class sun.misc.Launcher$ExtClassLoader
加载实例的加载器：test.classloader.MyClassLoader@135fbaa4
false
当不设置父类加载器时，默认的父加载器为应用程序加载器类。之前文中也有提到，应用程序加载器是负责加载应用程序路径下的类的，所以当自定义类加载器收到加载请求时，请求一路往上传，传到启动类加载器。然后由于启动类加载器找不到Test类，请求回到扩展类，扩展类又回到应用程序加载器，由于应用程序加载类能找到Test类，所以应用程序加载类就直接把类加载了，自定义的findClass方法没有执行。
再来看父加载器为扩展类加载器的情况。加载请求也是一路往上传，最后到扩展类时由于也找不到该类，加载请求就传到自定义类加载器加载了。至于最后返回的false，是因为虚拟机中存在了两个Test类，一个是由应用程序加载器加载的，另一个是由自定义加载器加载的，虽然都来自于同一个Class文件，但依然是两个独立的类，做对象所属类型检查时结果自然为false。
双亲委派模型的破坏
双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。而想要破坏双亲委派模型也很简单，上文中也能看到，双亲委派模型的实现依靠的是loadClass方法，因此只需要重写该方法，即可破坏双亲委派模型。
参考
深入理解Java虚拟机
JVM系列之类加载流程-自定义类加载器
深入拆解 Java 虚拟机