1、类加载机制
我们来了解一下虚拟机如何加载Class文件。
虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被直接使用的java类型，这就是虚拟机的类加载机制。
类的生命周期包括加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、卸载（Unloading）等七个阶段，其中验证、准备和解析三个部分统称为连接（Linking）。而类的加载指的就是从加载到初始化这五个阶段。
这七个阶段的顺序除了解析阶段和使用阶段外，其它几个阶段的开始顺序是确定的，必须按这种顺序按部就班的开始，但不要求按这种顺序按部就班的完成，这些阶段通常是互相交叉地混合式进行的，通常会在一个阶段执行的过程中调用或激活另外一个阶段。解析阶段在某些情况下可以在初始化阶段之后再开始，以支持java的运行时绑定（RTTI），而使用阶段则是按类文件内容的定义的不同而在不同的阶段进行。
虚拟机规范对于何时进行加载这一阶段并没有强制约束，但对于初始化阶段，虚拟机规范是严格规定了有且只有四种情况必须立即对类进行初始化：
a、遇到new,getstatic,putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指定的场景是：使用new关键字实例化对象，读取或设置一个类的静态字段以及调用一个类的静态方法的时候。当然，被final修饰并在编译期就把结果放入常量池的静态字段不属于这些场景，这类静态字段的值在编译期时就会被编译器优化而直接放入常量池，其引用直接指向其在常量池的入口。
b、使用java.lang.reflect包的方法对类进行反射调用时，如果类没有进行过初始化，则需要先触发其初始化。
c、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
d、当虚拟机启动时，用户需要指定一个要执行的主类（包含main（）方法的类），虚拟机会先初始化这个主类。
以上四种场景中的行为称为对一个类进行主动引用，除此之外所有引用类的方式都不会触发初始化，称为被动引用。
接口的加载过程与类加载过程最主要的区别在于第三点，即当初始化一个接口时，并不需要先初始化其父接口，而是只有真正使用到父接口中的字段的时候才会初始化。
以下对类加载的各个阶段进行简单的说明。
加载阶段，虚拟机需要完成三件事：通过一个类的全限定名来获取定义此类的二进制字节流，将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构，在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。
验证阶段，不同虚拟机会进行不同类验证的实现，但大致都会完成以下四个阶段的检验过程：文件格式验证（验证字节流是否符合Class文件格式的规范，并能被当前版本的虚拟机处理），元数据验证（对字节码描述信息进行语义分析，保证其描述信息符合java语言规范），字节码验证（对类方法体进行数据流和控制流分析，保证类的方法在运行时不会做出危害虚拟机的行为）和符号引用验证（发生在将符号引用转化为直接引用的时候，在解析阶段中发生）。
准备阶段，正式为类成员变量（注意，不是实例成员变量，实例变量会在对象实例化时随着对象一起分配在java堆上）分配内存并设置类变量初始值（通常情况下是数据类型的零值，不进行赋值操作）的阶段，这些内存都将在方法区中进行分配。
例：public static int value=123;则在准备阶段过后，value的初始值为0而不是123，赋值指令是在初始化阶段通过构造方法来执行的。
解析阶段，虚拟机将常量池内的符号引用替换为直接引用的过程。符号引用与内存布局无关，而直接引用的目标必定已经在内存中存在。解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行。
初始化阶段，真正开始执行类中定义的java程序代码（字节码），是执行类构造器<clinit>()方法的过程。
<clinit>()方法的一些特点：
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static｛｝）中的语句合并产生的，编译器收集顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量。
<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显式地调用父类构造器，虚拟机会在子类的<clinit>()方法执行之前完成父类<clinit>()方法的执行。
由于父类的<clinit>() 方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作
<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，则编译器可以不为这个类生成<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法，不同于类的地方是执行接口的<clinit>()方法时不坱要先执行父类的<clinit>()方法。
虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，则只有一个线程去执行这个类的<clinit>()方法，其它线程阻塞等待，直到活动线程执行<clinit>()方法完毕。
了解完各个类加载机制的阶段后，我们需要进一步了解类加载器这个概念。类加载器只用于实现类的加载动作，即实现通过一个类的全限定名来获取描述此类的二进制字节流。但对于类来说，要判断两个类是否相等（instanceof，equal），其前提是两个类是由同一个类加载器所加载，否则，无论两个类是否来源于同一个Class文件，这两个类都必定不等，亦即是说，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机的唯一性。
在Java开发人员看来，类加载器可划分为以下三类系统提供的类加载器：启动类加载器（Boostrap ClassLoader，负责将存放在<JAVA_HOME>lib目录中的类库加载到虚拟机内存中，其无法被Java程序直接引用），扩展类加载器（Extension ClassLoader，由sun.misc.Launcher$ExtClassLoader实现，负责加载<JAVA_HOME>libext目录中的类库，可被开发者直接使用），应用程序类加载器（由sun.misc.Launcher$AppClassLoader来实现，负责加载用户类路径（ClassPath）上指定的类库，可被开发者直接使用，且为默认的类加载器）。
java中采用双亲委派模型（Parents Delegation Model）来实现类的加载模式。双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，此处的父子关系不以继承来实现，而是采用组合来利用父加载器。
双亲委派模型的工作过程：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会自己去加载。其模型如下图所示：
2、类的加载顺序
类的加载分为六步：
(1) 类型为Dog的一个对象首次创建时，或者Dog类的static方法／static字段首次访问时，Java解释器必须找到Dog.class（在事先设好的类路径里搜索）。
(2) 找到Dog.class后（它会创建一个Class对象，这将在后面学到），它的所有static初始化模块都会运行。因此，static初始化仅发生一次——在Class对象首次载入的时候。
(3) 创建一个new Dog()时，Dog对象的构建进程首先会在内存堆（Heap）里为一个Dog对象分配足够多的存储空间。
(4) 这种存储空间会清为零，将Dog中的所有基本类型设为它们的默认值（零用于数字，以及boolean和char的等价设定）。
(5) 进行字段定义时发生的所有初始化都会执行。
(6) 执行构建器。
下面我们来讲讲每一步的理解：
第一步：
这句阐述的是jvm何时以及怎样加载某个类。很显然，根据这句话的表述，我们可以看出：当用new关键字来首次创建某对象，或者直接访问静态的类方法或类字段时，jvm开始打算加载某个类（这里的类就是那个Dog类，强烈要求下个版本换为Duck！）。然后jvm便通过默认或用户自己设置的classpath来找到那个同名的class文件，紧接着便发生了加载。
第二步：
加载的结果就是在jvm中产生了一个包含了该类所有信息的Class对象。紧接着就对静态的模块进行了初始化。这里就是在说，你做的所有关于静态模块的初始化工作都在这里第一次，也是最后一次完成了——不论你是用的“static int duck = 250”的形式，还是用的静态代码块的形式。
ps：
静态代码块初始化
static int duck ; static { duck = 250; }
第三、四步：
这两句话是前两句话的注解：1.Java内对象是在堆内存里产生的。2.而且在分配了供这个对象使用的内存后，这段内存里的每个存储单元都会被jvm清零（所达到的效果就是基本类型被置为0 或 0.0 或 false ，引用则被置为null）
要提醒的是，这两句里的动作都在一二句之前完成。否则会出现可笑的情形：不管你咋初始化，你最后都会郁闷的发现被归零了。
第五步：
这句最没营养了，就是个强调。
第六步：
在继承中的初始化，当你调用一个父类的子类，或许就是调用了这个子类的构建函数，jvm总会调用父类的构建函数来实现完整的初始化。也就是说，调用这个子类，jvm会有规律的找他的父类。如若这个父类又是某个父类的子类，则jvm还会继续向上找寻父类，直到最终父类——Object类。然后又在依次向下，调用各父类的构建方法来初始化它的直接子类——直到最终子类。这样一来，啥模块的初始化都不会落下了。