虚拟机类加载机制

四、虚拟机类加载机制

1、概述

• 虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载

2、类加载的时机

2.1、生命周期

• 类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括了：

  • 加载
  • 验证
  • 准备
  • 解析
  • 初始化
  • 使用
  • 卸载

• 加载、验证、准备、初始化和卸载顺序是确定的，但是解析阶段则不一定。

• 类的初始化（没有初始化）

  • 有道new、getstatic、putstatic或invokestic这4条字节码指令时
  • 父类没有进行初始化
  • 使用反射包的方法调用
  • 虚拟机启动是，用户需要指定一个要执行的主类（包含main）方法的那个类

• 上面四种场景都是主动引用，其余的方式都是被动引用，不会触发初始化。

  • 通过子类引用父类的静态字段，不会导致子类初始化
  • 通过数组定义来引用类，不会触发此类的初始化
  • 常量在编译阶段会存入调用类的常量池中，本质上没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

• 接口在初始化的时候不要求父类初始化，只有使用到父接口的时候才会触发初始化

3、类加载的过程

3.1、加载

• 在加载阶段，虚拟机需要完成以下三件事情
  • 通过一个类的全限定名来获取定义此类的二进制字节流
    • 从zip中获取
    • 从网络中获取
    • 在运行时计算生成（如动态代理）
    • 由其他文件生成（JSP应用）
    • 从数据库中读取等的
  • 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
  • 在Java堆中生成一个代表这个类的Class对象，作为方法区这些数据的访问入口。
• 加载阶段是开发期间可控性最强的阶段，因为加载阶段既可以使用默认的类加载器，也可以使用自定义的类加载器完成
• 加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的。加载未完成，连接可能已经开始，但是这两个阶段开始时间依然保持着固定的先后顺序。

3.2、验证

• 验证是连接的第一步，目的就是为了确保Class文件的字节流中包含的信息是否符合当前虚拟机的要求。

3.2.1、文件格式验证

• 是否以魔数开头

• 主次版本是否在当前虚拟机处理范围内

• 常量中是否有不被支持的常量类型等

3.2.2、元数据验证

• 是否有父类
• 是否继承了不被允许的类
• 类的字段，方法是否与父类产生了矛盾等

3.2.3、字节码验证

• 最复杂的一个阶段，主要工作是进行数据楼和控制流分析
  • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，如：在操作栈中防止一个Int类型的数据，使用时却按long类型来加载入本地变量表中。
  • 保证跳转指令不会跳转到方法体意外的字节码指令上
  • 保证方法体中的类型转换是有效的，如：吧一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋给子类数据类型或者是毫不相干的数据类型，则是危险和不合法的。

3,2,4、符号引用验证

• 最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化是在解析中发生
  • 符号引用中通过字符串描述得全限定名是否能找到对应的类
  • 在指定类中是否存在方法的字段描述符及简单名称锁描述得方法和字段
  • 符号引用中的类、字段和方法的访问性是否可被当前类访问。
• 该阶段不是必要的阶段，可以使用-Xverify:none参数来关闭

3.3、准备

• 正式将类变量分配内存并设置类变量初始值阶段，这些内存都将在方法区中进行分配
• 这时候进行内存分配的是类变量（被static修饰的变量），不包括实例变量。实例变量将会在对象实例化时随着对象一起分配在Java堆中。
• 通常情况下初始值是零值，相对一下会是设置的值。public static final int value = 123编译的时候会将value生成ConstantValue，在准备阶段设置为123

3.4、解析

• 是虚拟机将常量池内的符号引用替换成直接引用的过程

• 符号引用

  • 以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可
  • 符号引用于虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中

• 直接引用

  • 可以使直接指向目标的指针、相对便宜量或是一个能简介定位到目标的句柄
  • 与虚拟机实现的内存布局相关的，用同一个符号在不同寻积极实例上翻译出来的直接引用一般不会相同。如果有了直接引用，拿引用的目标必定已经在内存中存在

• 虚拟机未规定解析阶段发生的具体时间，只是现在引用字节码指令之前，先对它们所使用的符号引用进行解析。

• 解析动作主要针对类或者接口、字段、类方法四类符号引用进行。

• 类或者接口的解析

  • 假设类D，要把从未解析过的符号引用N解析为一个类或者接口C的直接引用。
    • 如果C不是一个数组。会把代表N的全限定名专递给D的类加载器去加载这个类C。而这个过程中如果在进行加载过程就出现异常，这个解析过程就会失败
    • 如果C是数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似[Ljava.lang.Integer的形式，那将会按照第一点的规则加载数据元素类型。
    • 如果上面的步骤没有出现异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了。但在解析完成之前还要进行符号引用验证，确认C是否具备对D的访问权限。

• 字段解析

  • 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束
  • 如果C实现了接口，则从上往下搜索各个接口和它的父接口，如果接口中包含了匹配的字段，则返回直接引用
  • 如果C不是Object类的话，将会从上往下搜索其父类，如果在父类中查找到，则返回直接引用
  • 查找失败NoSuchFieldError异常
  • 如果查找到并返回，则将会对其进行权限验证。如果没有权限，则抛出IllegalAccessError异常。

• 类方法解析

  • 与字段解析的步骤一样，显示自己类，父类，父接口，如果找到，则返回直接引用，如果没有，则抛出NoSuchMethodError

• 接口方法解析

  • 第一步依然是需要先解析出接口方法表的class_index项中索引的方法所属的类或者接口的符号引用
    • 与类方法解析相反。如果在接口方法表中发现class_index中索引C是个类而不是接口，那就直接抛出IncompatibleClassChangeError异常
      • 否则将在本类、父类、接口中查找匹配，如果找到则直接返回直接引用，如果查找没有，则抛出NoSuchMethodError

3.5、初始化

• 初始化阶段是执行类构造器<clinit>()方法的过程。
• <clinit>()是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的。
• 在执行子类的<clinit>()之前，父类的已经执行完成。
• <clinit>()方法对于类或接口来说不是必须的，如果一个类中没有静态语句块也没有对变量的赋值操作，那么可以不生成
• 接口不能使用静态语句块，但是与类不同的是，执行接口的<clinit>()时，不需要先执行父类的，接口在执行初始化时也不会执行。
• 在多线程中，如果去初始化一个类，只有一个线程去执行该类的<clinit>()方法，其他方法都会阻塞等待

4、类加载器

4.1类与类加载器

• 把类的加载阶段中的 通过一个类的全限定名来获取描述此类的二进制字节流这个动作放到Java虚拟机外部去实现，实现这个动作的代码模块被称为“类加载器”。
• 类加载不仅仅是为了加载类，还有为了确定类本身的唯一性，比较两个类是否相等，要在是同一个类加载器加载才有意义
• 这里所指的相等包括
  • 类的Class对象的equals()方法。
  • isAssignableFrom()方法。
  • isInstance()的返回结果方法。
  • instanceof关键字做对象所属关系判定等情况。

4.2、双亲委派模型

• 绝大部分Java程序都会使用三种系统提供的类加载器
  • 启动类加载器
    • 负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数指定的目录中的类加载到虚拟机内存中
    • 无法被Java程序直接引用、
  • 扩展类加载器
    • 负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量多指定的路径中的所有类库
    • 开发者可以直接使用扩展类加载器
  • 应用程序类加载器
    • 负责加载用户类路径上所指定的类库
    • 如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器、
• 双亲委派模型，除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。父子关系一般不是用继承来实现，是用组合关系来福永父加载器的代码。
• 双亲委派工作过程
  • 当类加载器收到类加载的请求，回西安吧这个请求委派到父类加载器去完成，只有当父类加载器无法完成的时候，本类加载器才会尝试去加载、

4.3、破坏双亲委派模型

• 曾经有三次破坏双亲委派模型，所以在OSGI环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构，当收到类加载请求时。OSGI将按照下面顺序进行类搜索

  • 将以Java。* 开头的类，委派给父类加载器加载
  • 否则，将委派列表名单内的类，委派给父类加载器加载
  • 否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器
  • 否则，查找当前Bundle的Class Path，使用自己的类加载器加载。
  • 否则，查找类是否是在自己的Fragment Bundle中，如果在，则委派给该类的类加载器
  • 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载
  • 否则，类查找失败。
  • 上面的查找顺序，只有前面两点符合双清委派机制，其余的类查找都是在平级的类加载器中进行的。

• 否则，查找类是否是在自己的Fragment Bundle中，如果在，则委派给该类的类加载器

• 否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载

• 否则，类查找失败。

• 上面的查找顺序，只有前面两点符合双清委派机制，其余的类查找都是在平级的类加载器中进行的。