JVM类加载机制

JVM类加载机制

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

类从被加载到虚拟机内存中开始到卸载出内存为止，整个生命周期包括：加载，验证，准备，解析，初始化，使用和卸载7个阶段。其中验证，准备和解析3个部分成为连接。
对类初始化的5种情况，有且仅有这5种

• 遇到new，getstatic，putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发初始化。生成这4条指令最常见的场景是：使用new关键字实例化对象，读取或设置一个类的静态字段，以及调用一个类的静态方法的时候
• 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行初始化，则需要先触发初始化
• 当初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发父类初始化
• 当虚拟机启动时，用户需要指定一个要执行的父类，虚拟机会启动先初始化这个类
• 当使用JDK1.7的动态语言支持时，如果一个java…lang.invoke.MethodHandle实例最后的解析结果REF_getStatic，REF_putStatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先触发其初始化

1.类加载的过程

1.1加载

加载是类加载过程的一个阶段，在加载阶段，虚拟机需要完成以下3件事

1. 通过一个类的全限定名来获取此类的二进制字节流
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

1.2验证

验证是连接的第一步，这个阶段的目的是为了确保Class文件的字节流中包含的信息符合虚拟机的要求，并且不会危害到虚拟机自身的安全

1.2.1文件格式校验

第一阶段要校验字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理
例如：是否是以魔数oxCAFEBABE开头
这个阶段验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这个阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储。

1.2.2 元数据验证

第二阶段是对字节码进行语义进行分析，以确保其描述的信息符合Java语言的规范要求
例如：这个类是否有父类，这个类的父类是否继承了不允许被继承的类

1.2.3 字节码验证

字节码验证主要是通过数据流和控制流分析，确保程序语义是合法，符合逻辑的。这个阶段将对类的方法体进行校验分析，确保被校验类的方法在运行时不会做出危害虚拟机安全的事件
例如：确保任意时刻操作数栈的数据类型与指令代码序列都能配合工作；保证跳转指令不会跳转到方法体以外的字节码指令上…

1.2.4 符号引用验证

最后一个阶段验证发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段—解析阶段发生。符号引用可以看作是对类自身以外的信息进行匹配性校验
例如：符号引用中通过字符串描述的全限定名是否能找到对应的类

1.3 准备

准备阶段是为正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区进行分配。

1. 这个阶段进行分配内存的仅是类变量，而不包括实例变量，实例变量将在对象实例化时随对象一起分配在Java堆中。
2. 这里所说的初始化是数据结构的零值

1.4 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
直接引用和符号引用的关联

• 符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时无歧义地定位到目标即可。符号引用与虚拟机是实现的内存布局无关，引用的目标不一定已经加载到内存中
• 直接引用：直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄，直接引用和虚拟机实现的内存布局有关，如果直接引用，那引用的目标必定已经在内存中存在

解析动作主要是针对类或接口，字段，类方法，接口方法，方法类型，方法句柄和调用点限定符7类符号引用进行的。

1.5 初始化

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用可以通过自定义类加载器参与之外，其余动作都是虚拟机主导和控制的。到了初始化阶段，才真正开始执行类中定义的Java程序代码
初始化阶段是程序员通过程序制定主观计划去初始化类变量和其他资源或者说是初始化阶段是执行类构造器()方法的过程。

2 类加载器

虚拟机团队把类加载阶段中“通过一个类的全限定名来获取描述此类的二进制字节流”的这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称为类加载器

2.1 类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每个类加载器都拥有一个独立的类空间名称。

2.2 双亲委派模型

双亲委派模型的工作过程：如果一个类加载器收到类加载请求，它首先不会自己去尝试加载这个类，而是把请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此如果所有的类加载器请求最终都是应该传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。

• 启动类加载器：这个加载器负责将存在<JAVA_HOME>\lib目录中，或被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。
• 扩展类加载器：这个加载器由ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器
• 应用程序类加载器：这个类加载器由AppClassLoader实现，这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值。它负责加载用户类路径上所指定的类库，开发者可以直接使用这个类加载器

2.3 破坏双亲委派模型

双亲委派模型出现过三次较大规模“被破坏”情况

• 第一次是双亲委派模型第一次被破坏是在双亲委派模型之前出现，双亲委派机制是在JDK1.2以后才被引入的，而类加载器和抽象类ClassLoader则在1.0时代出现的，面对已经存在的用户自定义类加载器的实现代码。Java设计者引入双亲委派模型时不得不进行一些妥协，先前兼容。因此在JDK1.2之后ClassLoader中添加了一个Protecte方法findClass()，在此之前，用户去继承ClassLoader的唯一目的是重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有构造方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass
  JDK1.2以后不在建议用户直接去覆盖loadClass()方法，而是应当把自己的类加载逻辑写到findClass()中，loadClass()加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载是符合双亲委派模型的。

• 第二次是由于模型自身缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类统一问题，但是会出下基础类又要回调回用户的代码的问题，为了解决这个问题，Java涉及团队只好引入了一个不太优雅的设计：线程上下文类加载器。这个类加载器可以通过Thread类的setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

• 第三次是由于对程序动态性的追求而导致的，这里所说的动态性是指：代码热替换，模块热部署等。OSGi实现热模块化部署的关键是它自定义的类加载器机制的实现。每一个模块都有一个自己的类加载器，当需要更换一个Bundle时，就把Bundle连同类加载器也一起换掉实现代码的热替换。在OSGi环境下，类加载器不在使用双亲委派模型中的树状结构，而是进一步发展未更加复杂的网状结构。