笔记：JVM - 类加载

public class Singleton{
  
    private Singleton(){}
  
    private static class SingletonHolder{
        private static Singleton INSTANCE = new Singleton();
    }
     
    public static Singleton getInstance(){
        return SingletonHolder.INSTANCE;
    }
}

类加载到方法区后，JVM 内部会使用 C++ 编写的 instanceKlass 来描述 Java 类，其字段有：

• _java_mirror：该 Java 类的镜像，即 Xxx.class ；而 Xxx 类对象的对象头又会有一个 klassPointer 指向它对应的 instanceKlass 。
• _super/_fields/_methods/_constants/_class_loader/_vtable/_itable：表示该类的父类/字段/方法/常量池/类加载器/虚方法表/接口方法表。

格式检查：检查魔数、版本、元素长度等。格式验证和加载一起执行，其它验证阶段在方法区中执行；

语义检查：检查该类的父类是否真实存在，是否继承/重写了 final ，非抽象类是否重写了所有抽象方法，是否有不兼容的方法（比如有多个同名同参、返回值不同的方法，这在字节码中是允许的，但 JVM 不允许；又比如出现了 abstract final 的方法）等；

字节码验证：最复杂的验证工作。检查字节码指令是否可以正确执行，比如：是否会跳转到一条不存在的指令，函数调用是否传递了正确类型的参数，变量赋值时是否给了正确的类型等。栈映射帧（StackMapTable，也是方法的 Code 属性的属性）在该阶段创建，用于检测在特定字节码处，其局部变量表和操作数栈是否有正确的数据类型，注意只是尽可能地检查出可以预知的明显的问题；

符号引用验证：检查符号引用所对应的类和方法是否真实存在（相关异常：NoClassDefFoundError 和 NoSuchMethodError），并且该有权限访问它们。要到解析阶段才会进行，因为解析阶段要将符号引用转成直接引用。

注意，static final 的基本数据类型变量在编译成字节码后会有一个 ConstantValue 属性，也就是说，它的值在编译时已经确定了；因此，在准备阶段会直接将常量值赋给该变量。static final String s = "x"; 也是同理的。但是，static final String s = new String("x"); 则需要延后到初始化阶段才能完成最终赋值；因为准备阶段无法进行 new 操作，所以只能在 <clinit>() 方法内 new String("x"); 后才把该对象地址赋给变量 s 。

如果直接引用存在，那么可以确定它对应的类/方法/字段在系统中存在。

JVM 规范没有规定解析阶段的执行时机。在 Hotspot VM 中，解析阶段在初始化阶段完成之后才会执行。

假设静态代码块在前，静态变量 num 的声明语句在后，那么可以在静态代码块中给 num 赋值，但不可以调用这个静态变量（非法前向引用）。

class Demo{
 
    public static int i1 = 1;                            //初始化阶段的<clinit>()方法中赋值
    public static final int i2 = 2;                      //链接的准备阶段中赋值
    public static final int i3 = new Random().nextInt(3);//初始化阶段的<clinit>()方法中赋值
 
    public static Integer i4 = Integer.valueOf(4);       //初始化阶段的<clinit>()方法中赋值
    public static final Integer i5 = Integer.valueOf(5); //初始化阶段的<clinit>()方法中赋值
 
    public static final String s1 = "static";            //链接的准备阶段中赋值
    public static final String s2 = new String("static");//初始化阶段的<clinit>()方法中赋值
 
}
 
/**
 * 总结1：对于static变量：
 * 1. 不是final的静态变量肯定是在初始化阶段显式赋值。
 * 2. 如果是final的，且是直接用字面量赋值，则在准备阶段显示赋值。
 * 3. 如果是final的，且不是直接用字面量赋值，则在初始化阶段显示赋值。
 *
 * 总结2：只有static final的、直接用字面量赋值（即不涉及方法或构造器调用）的才是在准备阶段显式赋值。
 */

如果 <clinit>() 方法耗时较长，则可能会导致多个线程阻塞，引发死锁；这种死锁是很难发现的，因为这些线程没有相应的锁信息。

比如：线程 1 加载类 A ，在 A 的初始化方法中先休息一段时间，再去加载类 B ；而线程 2 在线程 1 休息期间加载了类 B ，然后在 B 的初始化方法中又要去加载类 A ，就会导致死锁。

接口没有静态代码块，那如何验证使用接口的静态字段时会初始化该接口呢？可以在接口中再定义一个如下变量：

public static final Object obj = new Object(){ { System.out.println("init!");} }; 

这里使用了匿名内部类，显然 obj 对象只有在接口被初始化时才会创建，而创建 obj 对象时会执行构造代码块，就会有输出了。

只有自定义的类加载器加载的类在简单的上下文环境中才可能被卸载，而且一般还需要借助于强制调用 JVM 的垃圾收集才能做到。因此，类被卸载的可能性是很小的，至少卸载的时刻是不确定的，不要建立在某个类被卸载的前提下去实现某些功能。

可以通过 -Xbootclasspath/a:path 参数让 Bootstrap 再去 path 路径下加载类；相当于指定 path 目录也是核心类库的目录。

//获取加载某个类的类加载器，如果该类是扩展包的，则获取到扩展类加载器
Xxx.class.getClassloader();
 
//获取当前线程上下文的类加载器，默认是系统类加载器
Thread.currentThread().getContextClassLoader();
 
//获取系统类加载器，再调用其getParent()方法即可获得扩展类加载器
ClassLoader.getSystemClassLoader();

//加载名称为name的类，返回该类的Class对象，找不到则抛出异常
//该方法实现了双亲委派机制，所以如果自定义的类加载器要遵循双亲委派机制，就不要重写该方法
public Class<?> loadClass(Stirng name) throws ClassNoFoundException;
 
//查找名称为name的类，返回该类的Class对象，找不到则抛出异常
//是protected的，Java鼓励我们重写该方法；如果自定义的类加载器要遵循双亲委派机制，就重写该方法
//一般配合defineClass()方法使用，由此方法将二进制流封装成Class对象
protected Class<?> findClass(String name) throws ClassNoFoundException;
 
//负责将byte数组中从off开始、长度为len的部分封装成Class对象
//这个二进制流可以来自本地文件，也可以来自网络
protected final Class<?> defineClass(String name, byte[] b, int off, int len);
 
//解析（连接阶段的解析）指定的类
protected final void resolveClass(Class<?> c);
 
//查找名称为name的已经被加载的类，找不到则返回空
protected final Class<?> findLoadedClass(String name);

自定义的 ClassLoader 重写 loadClass() 方法时会破坏双亲委派机制，但这样依旧无法篡改核心的 API（比如让这个类加载器去加载自定义的 java.lang.Object 类，最终加载的还是 Java 的 Object 类），因为任何类加载器最终都必须调用 final 的 defineClass() 方法，而该方法一定会执行 preDefineClass() 接口，该接口提供了对核心 API 的保护。

自己定义一个 java.lang.String 类时加载的还是核心类库中的 String 类，在运行自定义的 java.lang.String 类中的 main() 方法时会报错说系统的 String 类没有 main() 方法；自己定义一个 java.lang.MyClass 类时会抛出 SecurityException ，因为 java.lang 包不能随便使用。

Tomcat 的默认类加载器会先自己加载类，加载失败才让父加载器加载，这也是 Servlet 规范推荐的一种做法。

简易实现热替换：假设 Hot 类的 hot() 方法可能在程序运行时需要修改；那么写程序时，在每次需要调用 Hot#hot() 方法时，先创建一个自定义类加载器，让这个全新的类加载器去加载该类，从而产生一个全新的 Hot 类的 Class 对象，然后利用这个 Class 对象，通过反射创建实例、获取 hot() 方法的 Method 对象，然后通过 method.invoke(hot); 来调用 hot() 方法。

线程启动后，JVM 默认会把系统类加载器赋给它；从而可以通过调用当前线程的 getContextClassLoader() 方法来获取线程上下文类加载器。

JDBC 的 DriverManager 是核心类库中的，由启动类加载器加载；但是 DriverManager 的静态代码块中需要加载驱动类，而驱动类肯定不是核心类库中的；因此，此时是通过 ServiceLoader 以及系统类加载器来加载驱动类的（ServiceLoader 底层是通过线程上下文类加载器，即系统类加载器来加载的），这就违反了双亲委派机制。

ServiceLoader 是 Service Provider Interface（SPI）的一个实现，用于解耦；它约定，在 Jar 包的 META-INF/services 包下，接口全限定名称作为文件名称，该接口的实现类的全限定名称作为文件的内容（可以有多个实现类，每个实现类的全限定名称占一行）；这样，它就可以通过 META-INF/services 包下的文件，去加载指定接口的实现类。

使用 JDBC 时，即使没有加载驱动类，JDBC 也可以正常使用，就是因为 ServiceLoader 会自动去加载驱动类。

进行类型转换时，两个类必须是被同一个类加载器加载的，否则会有异常；如果有另一个类加载器加载了这其中一个类，这时候就要特别注意。