Java 虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这个过程称为虚拟机的类加载机制。与那些在编译阶段需要进行连接的语言不同，在 Java 语言里面，类型的加载、连接、初始化、过程都在运行期间完成，这种策略让 Java 语言提前编译会遇到一些困难，也会让类加载时增加一些性能开销，但带来的好处也是很明显，让 Java 语言有了很高的灵活性。如：编写一个面向接口的程序，等到运行的时候再指定其实际的实现类（内部实现类），用户可以通过 Java 预制的或自定义类加载器，让某个本地的应用程序在运行的时候从网络或者其他地方加载一个二进制流作为其程序代码的一部分（切片AOP类似）。
二、类加载的时机一个类型从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期将会经历 加载、验证、准备、解析、初始化、使用、卸载 七个阶段，其中验证、准备、解析三个部分统称为连接。
加载、验证、准备、初始化、卸载这五个部分的顺序是确定的，类型的加载必须按照这五个步骤按部就班地开始，而 解析阶段 则不一定，它在某些情况可以在初始化之后开始，为了支持 Java 的动态绑定（运行时绑定特性）。
注意这里写的顺序确定的几个部分是按部就班的开始，而不是按部就班的执行，通常这些阶段是相互交替执行，会在一个阶段去调用或者激活另一个阶段。
而什么时候去激活 加载，见 《深入理解Java虚拟机》P263
三、类加载的过程 1、加载在 加载阶段 需要完成三件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流：
注意这里没有限定一定要从哪个 class 文件获取，这给了设计者巨大的展开空间，比如：
1、从 ZIP 压缩包文件中获取，形成了现在的 JAR、EAR、WAR格式的基础
2、从网络中获取
3、运行计算中生成：最典型的例子就是动态代理技术，在 Java.lang.reflect(反射包)就是用了某种方式来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流
4、可以从加密文件中读取等等（见 《深入理解Java虚拟机》P267）
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
- 在内存中生成一个代表该类的 java.lang.Class 对象，作为方法区这个类的各种数据访问入口
2、验证
验证是 连接阶段 的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息符合《Java 虚拟机规范》的全部约束，保证这些信息不会危害虚拟机自身的安全。
3、准备准备是 连接阶段 的第二步，准备阶段是正式为类中所定义的变量（即静态变量）分配内存并设置类变量初始值的阶段，从概念上讲，这些变量所使用的内存都应该在方法区中进行分配，但必须注意方法区本身是一个逻辑意义上的区域，JDK7及之前，使用永久代来实现方法区，JDK8以后，类变量会随着 Class 对象一起存放在 Java 堆中，这时候方法区就完全是逻辑意义上的表述了。
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意:
-
这时候进行内存分配的仅包括类变量(
static)，而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。 -
这里所设置的初始值通常情况下是数据类型默认的零值(如
0、0L、null、false等)，而不是被在Java代码中被显式地赋予的值。假设一个类变量的定义为:
public static int value = 3；那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的put static指令是在程序编译后，存放于类构造器<clinit>()方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
- 对基本数据类型来说，对于类变量(static)和全局变量，如果不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来说，在使用前必须显式地为其赋值，否则编译时不通过。
- 对于同时被
static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。 - 对于引用数据类型
reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。 - 如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。
- 如果类字段的字段属性表中存在ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。假设上面的类变量value被定义为:
public static final int value = 3；编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为3。我们可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中
解析过程是 连接阶段 的最后一步， 在这个阶段 Java 虚拟机将常量池内的符号引用替换为直接引用。
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。
初始化，为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。在Java中对类变量进行初始值设定有两种方式:
- 声明类变量是指定初始值
- 使用静态代码块为类变量指定初始值
JVM初始化步骤
- 假如这个类还没有被加载和连接，则程序先加载并连接该类
- 假如该类的直接父类还没有被初始化，则先初始化其直接父类
- 假如类中有初始化语句，则系统依次执行这些初始化语句
类初始化时机: 只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种:
- 创建类的实例，也就是new的方式
- 访问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射(如Class.forName("com.pdai.jvm.Test"))
- 初始化某个类的子类，则其父类也会被初始化
- Java虚拟机启动时被标明为启动类的类(Java Test)，直接使用java.exe命令来运行某个主类
实现类加载这个动作的代码称为：类加载器
类加载器虽然只用于实现类的加载动作，但它在 Java 程序中起到的作用远超类加载阶段，对于任意一个类，都必须由 加载它的类加载器 和 这个类本身 来共同确定器在虚拟机中的唯一性。
站在虚拟机本身来说，只存在两种不同的类加载器：一种是自己本身的类加载器（这个加载器使用 C++ 实现），第二种就是其他所有的类加载器（使用 Java 实现），第二种加载器存在于虚拟机外，并且全都继承自抽象类：java.lang.ClassLoader
而站在开发者的角度来看，自 JDK 1.2以来，Java 一直保持着三层类加载器、双亲委派的类加载架构：
三层类加载器：
启动类加载器: Bootstrap ClassLoader，负责加载存放在JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被-Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库(如rt.jar，所有的java.*开头的类均被Bootstrap ClassLoader加载)。启动类加载器是无法被Java程序直接引用的。
扩展类加载器: Extension ClassLoader，该加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JDK\jre\lib\ext目录中，或者由java.ext.dirs系统变量指定的路径中的所有类库(如javax.*开头的类)，开发者可以直接使用扩展类加载器。允许用户将具有通用性的类库放置在这个目录。
应用程序类加载器: Application ClassLoader，该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径(ClassPath)所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
双亲委派机制：
除了最高层 启动类加载器，其余加载器都有自己的父类加载器，但这里的父子一般不是以继承的方法实现的，而是通常使用复用父类加载器的代码。
双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先会将请求委派给父类加载器去完成，每一层的类加载器都是如此，由此所有的加载请求都会先传送到最高层类加载器，如果父类加载器无法完成这个加载请求（搜索范围内没有找到所需要的类），子加载器才会尝试自己加载。
使用双亲委派的优点就在于 Java 中的类有了一个优先级，如：用户自己定义一个 Object 类，如果由用户自己的加载器去加载，那样显然会出现很多不一样的 Object 类，应用程序将变得混乱不堪，而利用双亲委派就解决了这个问题。
11