二、类加载的时机
1.虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析以及初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
2.有且仅有5种情况必须对类进行“初始化”（加载、验证、准备阶段在此之前就要完成）：
在遇到new、getstatic、putstatic、或invokestatic这4条字节码指令时，如果此时类未进行初始化， 那就需先触发其初始化。
对应的Java代码场景是：使用new关键字实例化对象、读取或者设置一个静态字段（被final修饰，在编译时期把结果放入常量池中的静态字段除外）的值以及调用类的静态方法时；
使用java.lang.reflect包的方法对类进行反射调用时，如果类没有进行过初始化，那就需先触发其初始化；
当初始化一个类时，如果发现其父类尚未初始化，则需先触发其父类的初始化；
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类；
当使用动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行过初始化，则需要先进行初始化。
三、类加载的过程
1.加载
）通过一个类的全限定名来获取定义此类的二进制字节流。
2）将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3）在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类各种数据的访问入口。
2. 验证
文件格式验证、元数据验证、字节码验证和符号引用验证。
1）文件格式验证：这一阶段要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。
是否以魔术0xCAFEBABE开头；
主次版本号是否是在当前虚拟机处理范围之内；
常量池的常量中是否有不被支持的常量类型（检查常量tag标志）；
2）元数据验证：这一阶段主要是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。
这个类是否有父类；
这个类的父类是否继承了不允许被继承的类（被final修饰的类）；
如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法；
类中的字段、方法是否与父类产生矛盾（如覆盖了父类的final字段，不符合规则的重载）；
3）字节码验证：
保证跳转指令不会跳转到方法体之外的字节码指令上；
保证方法体中的类型转换是有效的，例如将子类对象赋给父类对象是安全的，但是把父类对象赋值给子类数据类型，甚至是和它毫无继承关系的一个数据类型，则是危险和不安全的；
保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现在操作数栈中放置了一个int类型数据，使用时却按long类型来加载人本地变量表中。
4）符号引用验证
符号引用中通过字符串描述的全限定名是否能找到相应的类；
在指定类中是否存在符合方法的字段描述符以及简单名称所描述方法和字段；
符号引用中的类、字段、方法的访问性（private、public、protected、default）是否可以被当前类访问；
5.准备
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。
6.解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。
在Class文件中符号引用以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。
对于同一个符号引用可能会出现多次解析请求，虚拟机可能会对第一次解析的结果进行缓存。
解析动作主要针对：类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。
7.初始化
(1)()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序所决定。)
(2)()方法与类的构造函数不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的()方法执行之前，父类的()方法已经执行完毕，因此在虚拟机中第一个执行的()方法的类一定是java.lang.Object。
(3)由于父类的()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
(4)()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块也没有对变量的赋值操作，那么编译器可以不为这个类生成()方法。
(5)接口中不能使用静态语句块，但仍然有变量赋值的初始化操作，因此接口也会生成()方法。但是接口与类不同，执行接口的()方法不需要先执行父接口的()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也不会执行接口的()方法。
(6)虚拟机会保证一个类的()方法在多线程环境中被正确地加锁和同步。如果有多个线程去同时初始化一个类，那么只会有一个线程去执行这个类的()方法，其它线程都需要阻塞等待，直到活动线程执行()方法完毕。如果在一个类的()方法中有耗时很长的操作，那么就可能造成多个进程阻塞。
类加载器
类加载器最初为了Java Applet来设计，目前在类层次划分，OSGi，热部署，代码加密等领域应用广泛。
类与类加载器
对于任一类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性。如果不注意Class的唯一性标识，可能会导致Class对象的equals, isAssignableFrom方法，isInstance等方法返回结果与预期不同。
双亲委派模型
站在Java虚拟机的角度讲，只存在两种不同的类加载器：一种是启动类的加载器（Bootstrap ClassLoader）这个类加载器使用C++实现，是虚拟机自身的一部分。另一种是所有其他类的加载器，这些来加载器都由Java语言实现，独立于虚拟机外部，并且全部继承自java.lang.ClassLoader
绝大部分Java程序会使用到以下三种类加载器
Bootstrap ClassLoader：这个类加载器负责将存放在\lib目录中或者被-Xbootclasspath参数指定的路径中的，并且是虚拟机识别的（仅按照文件名识别）类库加载到虚拟机中，此加载器无法被Java程序直接引用。
Extension ClassLoader：这个类加载器由sum.misc.Launcher$ExtClassLoader实现，它负责加载\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。
Application ClassLoader:这个加载器由sun.misc.Launcher$AppClassLoader来实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也成为系统类加载器。它负责加载用户类路径上指定的
类库，开发者可以使用这个类加载器。一般情况下这个基于是程序中默认的类加载器。
类加载器之间的这种层次关系，成为类加载器的双亲委派模型。双亲委派模型要求除了Bootstrap ClassLoader其余的类加载器都应当有自己的父类加载器。这些类加载器之间一般不使用继承而是使用组合来复用类加载器代码。一般的做法是只有父类加载器无法完成加载动作的时候，子类加载器才会真正的去加载某个类。这样保证了Java继承体系的正常运作。