虚拟机类加载机制
虚拟机把描述成类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
在Java语言里，类型的加载和连接过程都是在程序运行期，这样会在类加载时稍微增加一些开销，但却能为Java应用程序提供高度的灵活性。Java语言天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。
一、类加载时机
类从加载进内存直到卸载出内存，整个生命周期包括了：加载、验证、准备、解析、初始化、使用和卸载七个阶段。其中验证、准备、解析三个部分统称为连接。
加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，而解析阶段可以在初始化顺序之后再开始，这是为了支持Java语言的动态绑定。
对于初始化阶段，虚拟机规范了有且仅有四种情况必须对类进行初始化：
（1）、遇到new、getstatic、putstatic或者invokstatic这4条字节码指令时，如果类没有进行初始化，则需要触发其初始化。
（2）、使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
（3）、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类进行初始化。
（4）、当虚拟机启动时，会初始化有主函数的这个主类。
这四种初始化动作称为对一个类进行主动引用。除此之外所有引用类的方式，都不会触发初始化，称为被动引用。
接口的加载过程和类稍有一些不同，针对接口需要做一些特殊说明。接口也有初始化过程，这点与类是一致的，编译器会为接口生成“
二、类加载的过程
加载、验证、准备、解析、初始化这五个阶段。
2.1、加载
在加载阶段，虚拟机需要完成以下三件事情：
（1）、通过一个类的全限定名来获取定义此类的二进制字节流；
（2）、将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
（3）、在Java堆生成一个这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
虚拟机加载阶段灵活度相当大，比如“通过一个类的全限定名来获取定义此类的二进制字节流”，并没有指明二进制字节流要从一个Class文件中获取，没有指明要从哪里获取以及如何获取。在加载阶段是开发期可控性最强的，因为加载阶段既可以使用系统提供的类加载器去完成，也可以用户自定义类加载器去完成，开发人员可以通过定义自己的类加载器去控制字节流的获取方式。
加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区中，方法区的数据格式由虚拟机实行自定义，虚拟机未规定此区域的具体数据结构。然后在Java堆中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口。
加载阶段与连接阶段的部分内容（比如一部分字节码的文件格式的验证动作）是交叉进行的。加载阶段尚未完成，连接阶段可能已经开始。
2.2、验证
验证是连接阶段的第一步，这一阶段是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机本身。
Java本身相对于C/C++来说是安全的语言，使用纯粹的Java代码无法做到将一个对象转型为它并未实现的类型、跳转到不存在的代码行之类的事情，如果这样做了，编译器将拒绝编译。
但是Class文件并不是一定要求用Java源码编译而来，可以使用任何途径，包括十六进制编辑器直接编写来产生Class文件。
如果虚拟机不检查输入的字节流，对其完全信任的话，很可能载入有害的字节流而导致系统崩溃。
如果验证到的字节流不符合Class文件的存储格式，就抛出一个jaav.lang.VerifyError异常或其子类异常。不同的虚拟机对类验证的实现可能会有所不同，但大致都会完成以下四个检验阶段：
1.文件格式验证、2.元数据验证、3.字节码验证、4.符号引用验证
1、文件格式验证
验证字节流是否符合Class文件的规范，并且能被当前版本的虚拟机处理。这一阶段可能包括下面这些验证：
1、是否以魔数0xCAFEBABE开头。
2、主、次版本号是否在当前虚拟机处理范围之内。
3、常量池中的常量是否有不被支持的常量类型（检查常量tag标志）。
4、指向常量的各种索引值是否有指向不存在的常量或者不符合类型的常量。
...
该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区内，格式上符合Java类型信息的要求。这阶段的验证是基于字节流进行的，经过了这个阶段的验证后，字节流才会进入内存的方法区进行存储。后面三个验证阶段是基于方法区的存储结构进行的。
2、元数据验证
这个阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言的规范要求，这一阶段包括以下几个验证点：
1、这个类是否有父类
2、这个类的父类是否继承了不允许被继承的类（被final修饰的类）
3、如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法。
4、类中的字段、方法是否和父类产生了矛盾
3、字节码验证
字节码验证是整个验证过程最复杂的一个阶段，主要是对数据流和控制流进行分析。在元数据验证阶段对元数据信息中的数据类型做完校验后，这个阶段主要对类的方法体进行校验分析：
1、保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似的情况：
在操作数栈中放置了一个int类型的数据，使用时却按long类型加载进本地变量表。
2、保证跳转指令不会跳转到方法体以外的字节码指令上。
3、保证方法体中的类型转换是有效的。
如果一个类的字节码没有通过字节码验证，那肯定是有问题的，但是通过了，也不能说明一定安全。---不能通过程序去检查程序是否能在有限的时间之内结束。
4、符号引用验证
此阶段的校验发生在虚拟机将符号引用转化为直接引用的时候。这个转化动作是在连接的第三个阶段解析阶段进行的，符号引用验证可以看作对类自身之外的信息进行匹配性的校验：
1、符号引用中通过字符串中描述的全限定名是否能找到匹配的类。
2、在指定类中是否存在符合方法的字段描述符。
符号引用验证是为了确保解析动作能正常进行，如果无法通过符号引用验证，将抛出一个java.lang.IncompatibleClassChangeError异常的子类。
验证阶段对于虚拟机的类加载机制来说，是一个非常重要的，但不一定必要的阶段。如果运行时全部代码都已经被反复使用过，在实施阶段就可以考虑使用-Xverify:none参数来关闭大部分类验证措施，来缩小虚拟机类加载的时间。
2.3、准备（类变量）
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。
注意：这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次，这里所说的初始值通常情况是数据类型的零值，假设一个类变量定义为：public static int value = 123;
那么变量value在准备阶段之后的初始值为0而不是123，因为此时尚未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器
2.4、解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，符号引用在Class文件中以CONSTANT_Class_info、CONSTANT_Fieldref_info等类型的常量出现。
解析阶段中的直接引用和符号引用的关联：
（1）、符号引用：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时定位到目标即可。它与虚拟机实现的内存布局无关，引用的目标不一定已经加载进内存。
（2）、直接引用：直接引用可以是直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用与虚拟机实现的内存布局相关，同一个符号引用在不同虚拟机上翻译出来的直接引用一般不同，如果有了直接引用，那么引用目标必定在内存中存在。
虚拟机中并未规定解析阶段发生的具体时间，只要求在new、getstatic等13个操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。
当对一个符号引用进行多次解析时，虚拟机可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复。
无论是否真正执行了多次解析动作，虚拟机都要保证一次解析成功，那么后面的解析请求都能成功，如果第一次解析没成功，那么其他指令对这个符号的解析请求也应收到相同的异常。
虚拟机主要针对类或接口、字段、类方法、接口方法四类符号引用进行。
2.5、初始化
类初始化阶段是类加载过程的最后一步，在初始化阶段，才真正开始执行类中定义的Java程序代码。
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则是根据成员定义的规则去初始化类变量和其他资源。或者说初始化阶段是执行类构造器
三、类加载器
类加载阶段的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作是放在虚拟机外部来实现的，以便让程序自己去决定如何获取所需要的类。实现这个动作的代码模块称为“类加载器”。
站在虚拟机的角度来看，只有两种类加载器：一种是启动类加载器（Bootstrap ClassLoader），由C++语言实现，是虚拟机自身的一部分；另一种是其他的类加载器，这些都是由Java语言实现的，独立于虚拟机外部实现，并且全部继承自抽象类jjava.lang.ClassLoader。
大部分Java程序会使用以下三种类加载器：
启动类加载器（Bootstrap ClassLoader）：负责加载 JAVA_HOME/lib 目录下，或被-XbootclassPath 参数指定的路径下的类库。
拓展类加载器（Extension ClassLoader）：负责加载 JAVA_HOME/lib/ext 目录下或者被 java.ext.dirs 系统变量所指定的路径中的所有类库。
应用程序类加载器（Application ClassLoader）：是ClassLoader.getSystemClassLoasder() 方法的返回值，负责加载用户类路径上所指定的类库。
类加载器双亲委派模型
双亲委派模型要求除了启动类加载器之外，其余的类加载器都应当有自己的父类加载器，父子关系采用组合而非继承的方式实现，以复用父加载器的代码。
工作过程：一个类加载器收到了类加载的请求，他首先不会尝试自己加载这个类而是把这个请求委派给父类加载器来完成，因此所有的加载请求最终都会传送到顶层的启动加载类中。只有父类无法完成这个加载请求时，子加载器才会尝试自己去加载。
实现逻辑：先检查是否已经被加载过，若没有则调用父类的加载器的loadClass()方法，如果父类加载器为空则默认使用启动类加载器。如果父类加载失败，在抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
意义：Java类随着它的类加载器一起具备了带有优先级的层次关系。无论哪个类加载器要加载这个类最终都会传递到最顶层的启动类加载器，再向下逐层尝试，这就能保证所有相同的类在各种类加载器环境中都是同一个类，若没有类似的向上传递的过程，由各个类加载器自行去加载的话，系统中会出现多个不同的一个名称的类，各种类的行为无法保证一致，体系崩坏。它保证了Java程序运行的稳定性。