虚拟机类加载机制（Java）

类加载机制：虚拟机把class文件加载到内存，并且对数据进行校验、转换解析和初始化，经过这些步骤最终形成可以被虚拟机直接使用的Java类型。

类加载的时机

类从加载到虚拟机内存中到最终卸载出内存，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用 （Using）和卸载（Unloading）7个阶段。

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这
种顺序，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为
了支持Java语言的运行时绑定

如果类没有初始化，必须先对其初始化，对于类的初始化阶段，虚拟机规范中严格说明了有且只有5种情况必须对类进行初始化
1、使用new关键字实例化对象的时候、访问类或者接口的静态变量，对其变量赋值，调用类的静态方法（类.XX）
2、反射的方式
3、当初始化一个类的时候，父类如果没初始化，则父类也会进行初始化
4、当虚拟机启动时被标明启动的类,利用java.exe命令来运行某个主类（包含main方法）
5、当使用JDK1.7的动态语言支持时

类加载过程

加载
在这个阶段虚拟机需要完成三件事：
1）通过一个类的全限定名来获取此类的二进制字节流
2）将这个字节流所代表的静态的存储结构转化为方法区的运行时数据结构
2）在内存中生成一个Class对象，存在于方法区中（java中一切皆对象 ），这个对象作为程序访问方法区中这些数据类型的外部接口
验证
这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备
这个阶段是正式为类变量分配内存并且设置类变量初始化的阶段这些变量所使用的内存都将在方法区中进行分配
我们需要注意的是仅仅是初始化并不是赋值，这里的初始化“通常情况”就是数据类型的0值，但是如果这个类变量被final所修饰，那就会直接赋值
解析
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程
符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中
直接引用：直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。
初始化
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程
<clinit>()是由编译器自动收集类中的所有的类变量的赋值动作和静态代码块中的语句合成而成的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不可以访问（class对象的初始化方法，字节码层面）

public class Test{
    static{
        i=0; //给变量赋值可以正常编译通过
        System.out.print(i); //这句编译器会提示"非法向前引用"
    }
    static int i=1；
}

<clinit>()方法与类的构造函数（或者说实例构造器()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的()方法已经执行完毕。因此在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。
但是倘若一个类中没有静态代码块和赋值操作，那也就不会存在<clinit>()方法
还要注意的就是接口，接口中不能使用静态代码块，但是可以有变量初始化的赋值操作，因此编译器可以为这个接口生成<clinit>()方法。但是与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，只有当接口中的变量被使用的时候，父接口才会进行初始化。同样的道理，接口的实现类也是如此。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。

类加载器

类加载器可以分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器

启动类加载器：启动类加载器无法被Java程序直接引用，倘若需要启动类加载器来进行加载，则直接指定parent为null，这时就将这个类委派给启动类加载器来加载
扩展类加载器：开发者可以直接使用扩展类加载器。
应用程序类加载器它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派模型：如果一个类加载器收到类加载的请求的时候，自己不会去加载这个类，而是把他委派给他的父类加载器，让父类的加载器去加载，每一层加载器都是这样，总体来说，所有的类加载请求最终都被传送给启动类加载器，只有当父类反馈自己无法加载这个类的时候，子加载器才会尝试自己去加载。
实现双亲委派的代码都集中在loadClass（）方法之中，基本逻辑：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器，否则就是默认的类加载器。如果父类加载失败，抛ClassNotFoundException异常后，则会自己调用自己的findClass（）方法进行加载。

如果我们自定义了自己的类加载器，强行用defineClass（）方法去加载一个以“java.”开头的类也不会成功。如果尝试这样做的话，将会收到一个由虚拟机自己抛出“java.lang.SecurityException：Prohibitedpackage name：java.lang”异常

比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等，也就是说生成的class类对象就不同。