Java类加载
在Java中，一个类如果要想正确运行，就必须通过JVM编译，然后将其载入内存中才能使用，这里的载入内存中，实际上就是：类在JVM中以java.lang.Class类型的对象存在。说到Class类型，了解反射的都比较清楚，这是反射中常用的一个类型，获取Class对象一般使用两种方式：通过类的具体对象的getClass方法(obj.getClass())、通过类的class属性获取(Object.class)。
Java中的类加载实际上都是通过字节流来来实现的，字节流的来源可以有多种方式，可以从文件中获取，也可以通过网络获取，虽然来源不同，但是只要最终是字节流形式，就可以通过JVM来解析并加载。在此先说明一下：类在加载过程中都经历了那些步骤。
类的生命周期
类从被虚拟机加载，直到最后被卸载出内存，这一整个过程成为类的生命周期，大致可以分为七个阶段：
这里需要注意：除去解析这个步骤，其余步骤的顺序都是确定的，解析阶段规则有点不同，在有些情况下，解析可以在初始化之后再进行，这也是Java语言的运行时绑定的一个基础保障。
这里先说说初始化，在虚拟机规范中，严格规定了初始化所必须具备的条件，即：如果满足必备条件，将必须执行初始化操作。共有5中情况（能够到初始化这一步，也就说明前面都已经验证通过了）：
遇到new、getstatic、putstatic或invokestatic这四条指令代码，如果对应类还没有初始化，则必须进行初始化，对应与Java中常用的场景就是：实例化一个对象(new)、读取或设置一个静态字段(getstatic、putstatic；这里需要额外说明：final修饰的常量不包括在内，因为它属于在编译器就已经把它放到了静态常量池中了)、调用一个方法的时候(invokestatic)。
在使用reflect包下的方法时，对类进行反射调用的时候，如果没有初始化，先触发其初始化
当初始化某一个类的时候，它的父类还没有进行初始化，那么就先初始化它的父类
虚拟机启动时，我们指定的那个包含main方法的类（执行主类）会先被初始化
JDK1.7的动态语言支持部分，在使用java.lang.invoke.MethodHandler实例解析最后结果中的方法句柄，如果方法句柄所对应的类没有被初始化，则需要先触发其初始化。
类加载
类的加载过程可以分为加载、验证、准备、解析和初始化这五个步骤。也就是上图中除去使用和卸载两个步骤之外的过程。
加载
加载过程是类加载过程的一个部分，换句话说：ClassLoading过程包括加载过程，但不仅仅只有加载过程，在加载阶段，虚拟机需要完成3个步骤：
通过一个类的全限定名来获取此类的二进制字节流。
将此字节流所代表的静态存储结构转换成方法区中的运行时数据结构
在内存中生成一个Class对象，在方法区中作为这个类访问入口。
通过第一步可以知道，这里并没有准确定义二进制流具体要从哪里获取，怎样获取。因此可以发挥的空间就比较大了，例如：可以通过压缩包中读取（zip、jar、war等等）、可以从网络中获取、运行时动态计算（动态代理）、其他文件生成（JSP）等等，方法多样，可以根据具体应用场景来自由选择。
验证
这一步是至关重要的一部，目的就是为了确保二进制字节流中包含的信息是不是与当前虚拟机的要求相符合，同时会不会对虚拟机有危险。验证阶段的严谨性直接决定了虚拟机的强壮性，严谨的验证过程可以保证虚拟机能够抵御各种恶意代码的攻击。这一过程如果不通过，会抛出java.lang.VerifyError。主要分为四个步骤：
文件格式验证：就是验证字节流是否符合规范，如：是否以魔数0xCAFEBABE开头、主次版本号是否在虚拟机的处理范围之内...等等
元数据验证：这段主要是对字节流中的信息进行语义分析，保证符合Java的语言规范，如：验证是否有父类（除Object之外，所有类都应当有父类）、是否存在继承了final修饰的类...等等
字节码验证：这块比较复杂，目的就是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的，在元数据校验的基础上，会对方法体进行校验分析，保证方法在运行时不会对虚拟机有危害。
符号引用验证：这个步骤发生在虚拟机将符号引用转化为直接引用过程中，这个转化动作发生在上图类的生命周期所示的【连接】步骤的第三个阶段--【解析】阶段发生。可以看做是类对自身以外的信息进行匹配校验。
准备
这个步骤是正式为类变量分配内存并且设置初始值的阶段，这些变量使用的内存都将在方法区中进行分配。注意这里说的变量仅仅是static修饰的变量，也就是跟类相关的变量，实例变量是在类进行实例化的时候，在Java堆中进行分配的。另外这里说的初始化并不是我们程序中定义的那些初始化的值，它仅仅只是根据数据类型设置该类型的零值。例如i程序中定义了变量：
public static int value = 123;
那么这里在初始化的时候，value的值此时是0，而value赋值123的操作是在程序被编译之后进行的，123的赋值操作将会在后面【初始化】那一步进行的。下面给出一些基本数据类型对应的零值：
| 数据类型 | 零值 | 数据类型 | 零值 |
|---|---|---|---|
| int | 0 | boolean | false |
| long | 0L | float | 0.0f |
| short | (short)0 | double | 0.0d |
| char | '\u0000' | reference | null |
| byte | (byte)0 |
上面的零值是通常情况下的赋值，但是还有一些特殊情况，例如用final修饰的变量，它所修饰的变量在编译阶段都会生成ConstantValue属性，并且将该属性的值指向程序所设置的值，如上面例子中的value，如果加上final，ConstantValue就会指向123，因此在准备阶段，虚拟机就会根据该属性指向的值设置对应字段的值。
解析
这个阶段是虚拟机将常量池中的符号引用转换为直接引用的过程，那么符号引用和直接引用到底是什么概念？
符号引用（Symbolic Reference）：它只是一种用来表示某种目标的一种标记，通过它能够让虚拟机定位到它所代指的目标即可，它可以是任何形式的字面量，它与虚拟机的内存布局无关，只是一种概念上的存在，它所代指的目标不要求是否已经在内存中存在，不同虚拟机虽然内存布局不一样，但是所接受的符号引用是一致的，所以说它是通用的。
直接引用（Direct Reference）：它可以是一个能够直接指向目标的指针、相对偏移量或者一个能间接访问到目标的句柄。它与具体的内存布局相关，它所指向的目标都已经是存在与内存中，是真实存在的。
解析主要包括：类或接口的解析、字段解析、类方法解析、接口方法解析。这里不再分析具体各个解析的概念，想要了解详情，可以查阅《深入理解Java虚拟机 第2版》的第七章第三小节解析部分。
初始化
到了这一步，才开始执行类中定义的Java程序代码，在前面已经有过一步初始化步骤，在这一步，将会根据Java程序的主观意愿去初始化变量和其他资源。初始化阶段是执行类构造器<cinit>()方法的过程。这里有一种情况需要说明：Java在定义静态语句块的时候，静态语句块中只能访问到定义在该静态语句块之前的变量，对于定义在它之后的变量，可以赋值，但是不能访问，例如：
public class Test {
static {
i = 0;//可以编译通过，正常赋值
System.out.println(i);//编译不通过，提示“非法向前引用(Illegal forward reference)”
}
static int i = 1;
}
而且<cinit>()方法执行之前，父类的<cinit>()方法必须已经执行完毕了，所以说最先执行的<cinit>()方法一定是Object类的，并且父类的静态语句要先于子类的静态语句执行。
类加载器
类加载器作用是实现类的加载动作，同时它也是区分类与类之间唯一性的重要依据。在Java中对于任意一个类，都需要由加载器和类的本身一同确定类在Java虚拟机中的唯一性。每一个类加载器都有一个独立的命名空间。换句话说：如果要比较两个类是不是“相等”，首先得基于是同一个加载器加载出来的，否则两个类肯定是“不相等”的。即：同一份字节码文件，被不同的加载器加载，那这两个类仍然是“不相等”的。
双亲委派模型
在虚拟机中，存在两大类加载器：根加载器（BootStrap ClassLoader）和其他以Java实现的加载器。除根加载器之外，其余的加载器都继承自抽象类ClassLoader，并且由Java代码实现。
根加载器：是C++实现的，它主要是用于加载JAVA_Home\lib目录中的类，或者被-Xbootclasspath参数指定的路径。这里虚拟机识别的方式是按照名字识别的，换句话说：它识别的那些类都是已经定义好的，如果是不符合这些命名的，即使放进加载路径中，也不会加载。
扩展类加载器（Extension ClassLoader）：主要是加载JAVA_HOME\lib\ext路径下的类。
应用程序加载类（Application ClassLoader）：加载类路径上指定的类库，如果程序中没有自定的加载器，这个就是默认的加载器，用户编写的代码，一般都是通过它来加载。
上面的三类加载器，是分层级的，最底层是应用程序加载器，上面一层是扩展类加载器，最顶层的是根加载器。双亲委派模型就是依据此结构建立的，它具体工作过程是：如果一个加载器收到了类加载的请求，加载器并不会直接进行加载，而是把这个请求委派个父类加载器来完成，只有父类加载器无法完成的时候，才到子类加载器中加载。另外需要明确一点：这里虽然说是“父子”关系，但是实际上并不是继承关系，而是通过组合方式实现的。在获取类加载器的时候，可以通过getParent方法来获取对应加载器的父类加载器。Application ClassLoader的父类加载器是Extension ClassLoader；Extension ClassLoader的父类加载器是BootStrap ClassLoader。但是如果我们通过Extension ClassLoader的getParent方法获取父类加载器的时候，得到的会是null，这是因为根加载器是C++实现的，它是本地语言实现的。
双亲委派模型有一个好处，就是Java类随着加载器的不同，有了优先级划分，同时对于Java程序的安全性和稳定性有了保障。试想：如果没有双亲委派，随便一个类都可以指定类加载器进行加载，那如果用户自定义了一个Object类，指定根加载器加载，这就破坏了Java内部的继承结构，Java内部，所有的类都是直接或间接继承自Object，这样出现了多个Object类，Java体系内部，一些很基础的行为就无法保证了（例如：hash，toString，equals等等这些行为）。这样系统内部就会一片混乱。而有了双亲委派，就能够保证越基础的类，由越高级的类加载器去完成，例如：用户尝试编写一个与rt.jar类库中某个类重名的类，可以发现，虽然可以编译，但是永远不会被加载运行，因为在到根加载器验证的时候就无法通过。
双亲委派模型在Java的ClassLoader.java的源码中就可以看到，可以查看该类中的loadClass方法：
protected Class<?> loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// 首先，验证类是不是已经被加载过了
Class<?> c = findLoadedClass(name);
if (c == null) {
long t0 = System.nanoTime();
try {
if (parent != null) {
c = parent.loadClass(name, false);
} else {
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
// 如果父类加载器中没有找到该类，就抛出ClassNotFoundException
}
if (c == null) {
//此时仍然没有找到，就调用本身的findClass方法
long t1 = System.nanoTime();
c = findClass(name);
//下面这些步骤就是定义类加载器，并且记录状态的，暂时无视它
PerfCounter.getParentDelegationTime().addTime(t1 - t0);
PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}
可以看到，代码逻辑很清晰：
先根据findLoadedClass确定是不是已经加载过
如果没有，就委派父类加载器进行查找加载
如果父类加载器没有加载成功，就抛出ClassNotFoundException，并且调用本加载器的findClass方法进行加载
破坏双亲委派模型
需要明白的是双亲委派模型不是一个强制性的约束，它只是一种推荐模式，Java中大都遵循这种模型，但是也会有例外，目前为止，双亲委派模型经历过三次较大规模的“被破坏”情况。其实与其说是“被破坏”，我更愿意称它为“被改造”。因为带来这些“破坏”的根本原因，主要还是因为双亲委派在有些特殊应用场景无法满足的问题。
第一次被破坏是JDK1.2之前，因为双亲委派模型是在JDK1.2之后才发布的，ClassLoader在JDK1.0就已经存在了，因此在1.2版本发布后，需要兼容以前的代码，1.2以后的ClassLoader添加一个protected方法findClass。这么做的原因就是在于1.2以前，用户继承ClassLoader的唯一目的就是重写loadClass方法，那么虚拟机在调用类加载器的时候会调用加载器的私有方法loadClassInternal方法，该方法就一个逻辑：调用自己写的loadClass方法，在1.2以后，不提倡覆盖loadClass方法，建议重写findClass方法，这样在父类的loadClass加载失败之后，会直接调用自身实现的findClass方法来加载。以此保证新写出来的类加载器是符合双亲委派模型的。
第二次被破坏是模型本身缺陷造成的，因为该模型虽然可以让越基础的类由越高级的加载器完成加载，但是也限制了上层加载器中加载的类不能调用用户的代码，典型的例子就是JNDI服务，它在服务启动的时候，需要调用各个厂商实现的不同接口，而该服务本身是放在rt.jar中的，为了解决这个问题，引入了线程上下文类加载器，它可以通过Thread类的setContextClassLoader方法来设置，若线程创建时没有指定，就直接从父类中继承一个，如果程序的全局环境都没有设置，就采用默认的应用程序类加载器，有了个这种加载器，JNDI通过该线程去加载所需要的SPI代码，即：父类加载器请求子类加载器去完成类的加载，实际上就是双亲委派的逆向过程。常说的JNDI、JDBC等采用的都是这种方式。
第三次“被破坏”是用户对程序动态性追求而导致的。这里的动态性实际就是指：代码热替换、模块热部署等这些“热点”概念。就是希望在程序运行的时候在不需要重启应用程序的情况下，动态替换程序中的类。这里就不得不提OSGi，它是Sun公司提出的JSR-294、JSR-277规范与JCP组织的模块化规范斗争中的产物，最终Sun落败给JSR-294规范（即：OSGi R4.2），OSGi实现热部署的关键就是：它有自定义的类加载器机制实现，每个模块在OSGi中都是一个Bundle，它都有一个自己的类加载器，当需要更换模块的时候，就将该Bundle连同所带的类加载器一起换掉，从而达到热部署的效果。而且在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构。
