一、类加载的时机
如果类没有进行过初始化，则需要先触发其初始化，虚拟机规范则是严格规定了有且只有五种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）
1.创建类的实例（new 的方式），访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法（类.xxx调用）
2.反射的方式
3.初始化某个类的子类，则其父类也会被初始化
4.Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
5.当使用JDK1.7的动态语言支持时
二、类的生命周期以及类加载的全过程
包括七个阶段：加载（loading）、验证（Verification）、准备（preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）、和卸载（Unloading）
其中验证、准备、解析三个部分统称为连接（Linking）
如图所示：
解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）
1.加载
◆通过一个类的全限定类名来获取定义此类的二进制字节流
◆将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构
◆在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口
2.验证
◆这一阶段的目的是为了确保class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全
3.准备
准备阶段是正式为类变量分配内存并设置类变量初始化的阶段，这些变量所使用的内存都将在方法区中进行分配
假设一个类变量的定义为：
public static int value = 123;
那变量value在准备阶段过后的初始值为0而不是123，因为这时候未开始执行任何Java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行
4.解析
迅疾将常量池内的符号引用替换为直接引用的过程
◆符号引用：符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中
◆直接引用：直接引用是和虚拟机实现的内存布局相关的，如果有了直接引用，那引用的目标必定已经在内存中存在
5.初始化
在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序猿通过制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是执行类构造器clinit>()方法的过程
◆clinit（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问
public class Test{
static{
i = 0;//给变量赋值可以正常通过编译
System.out.println(i)//这句编译器会提示“非法向前引用”
}
static int i = 1;
◆clinit（）方法与类的构造函数（或者说实例构造器init（）方法）不同，它不需要显式的调用父类构造器，虚拟机会保证在子类的init（）方法执行之前，父类的clinit（）方法已经执行完毕，因此在虚拟机中第一个被执行的clinit（）方法的类肯定是java.lang.Object
◆clinit（）方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成clinit（）方法
◆接口中定义的变量使用时，接口才会初始化：接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成clinit（）方法，但接口与类不同的是，执行接口的clinit（）方法，不需要先执行父接口的clinit（）方法，只有当父接口中定义的变量使用时，父接口才会初始化，另外，接口的实现类在初始化时也一样不会执行接口的clinit（）方法
◆虚拟机会保证一个类的clinit()方法完毕，如果在一个类的clinit（）方法中有耗时很长的操作，就可能造成多个进程堵塞，在实际应用中这种阻塞往往是很隐蔽的
三、类加载器及其说明
类加载器可分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器，他们的关系如下图所示：
1.启动类加载器
这个类加载器负责将存放在JAVA_HOME\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar.名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中，启动类加载器无法被java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null指定父类加载器即可
public class MyClassLoader extends ClassLoader{
protected MyClassLoader(ClassLoader parent) {
super(parent);
}
// 使用ClassLoader父类的构造方法：根据ClassLoader中loadClass可以知道，设置父类加载器为null会使用Bootstrap ClassLoader来加载
protected MyClassLoader() {
this(null);
}
}
2.扩展类加载器（Extension ClassLoader）
这个加载器由sun.misc.Launcher $ExtClassLoader实现，它负责加载＜JAVA_HOME＞\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。
3.应用程序类加载器（Application ClassLoader）
这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
四、类加载机制—-双亲委派机制
1.双亲委派模型的工作过程是：
如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。
2.使用双亲委派模型来组织类加载器之间的关系的好处：
就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。
例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。
双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass () 方法之中，逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。
3.说明：
类加载器给用户提供最⼤大的帮助为：可以通过动态的路径进行类的加载操作。
比较两个类相等的前提：必须是由同一个类加载器加载的前提下才有意义。否则，即使两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类注定不相等。
四、类加载面试相关问题
1.怎么理解类加载？—开放性问题（先回答整体，如果面试官对某个细节感兴趣，他会主动问）
（1）类加载的阶段：加载、验证、准备、解析、初始化
（2）类加载器：
自定义类加载器—>AppClassLoader（应用、系统类加载器）—>ExtClassLoader（扩展类加载器）—>BootstrapClaaLoader（启动类加载器）
（3）类加载机制：双亲委派机制
2.可能问到的其他问题：
（1）是否能自定义一个人Object/String类，使用自定义类加载器加载，换个问法：java.lang.Object如果自己写一个，会不会存在安全问题？
（2）如果类加载器不同，类对象是否相同
扩展阅读：《深入java虚拟机》
9.2.1Tomcat：正统的类加载器架构
9.2.2OSGI：灵活的类加载架构