一、类与类加载器
类加载器：实现加载阶段的第一步，通过一个类的全限定名来将这个类的二进制字节流加载进jvm。
类与类加载器：任意一个类唯一性都是由它本身和加载它的类加载器确定，两个类是否相等在它们是由同一个类加载器加载的前提下。
jvm虚拟机中包括两种类加载器：一种是启动类加载器（Bootstrap ClassLoader），它是使用C++实现；另一种是其他所有用java实现的类加载器。
从java程序角度：
1）启动类加载器：负责加载
2）扩展类加载器：负责加载
3）应用程序类加载器（系统类加载器）：它是Classloader中的getSystemClassloader()方法的返回值。负责加载用户类路径上所指定的类库，如果应用程序中没有自定义类加载器，这个就为程序中默认的类加载器。
免费在线视频教学：java视频教程
二、双亲委派模型
除了顶层的启动类加载器，其余所有类加载器都有自己的父类加载器。父子关系不以继承实现，而是以组合关系来复用父类加载器。
工作过程： 类加载器接到类加载请求–>将请求委派给父类加载器（直到最顶层启动类加载器）–>父类尝试加载，加载失败反馈给子类加载器–>子类加载器尝试加载
双亲委派模型的好处：保证java底层API的稳定，避免加载和基本类重名（Object）的自定义类导致出现多个不同的重名的类（Object），从而造成java基础行为的混乱。
双亲委派模型源码：
方法加同步锁保证线程安全，首先检查该类是否被加载过，如果没有加载则调用父类加载器的loadClass()方法，若父类加载器为空说明是启动类加载器，则调用启动类加载器。
如果父类加载失败会抛出ClassNotFoundException，在调用自己的findClass()方法进行加载。
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) {
//如果父类不为空则调用父类加载器的loadClass方法
c = parent.loadClass(name, false);
} else {
//没有父类则默认调用启动类加载器加载
c = findBootstrapClassOrNull(name);
}
} catch (ClassNotFoundException e) {
//如果父类加载器找不到这个类则抛出ClassNotFoundException
}
if (c == null) {
// 父类加载器失败时调用自身的findClass方法加载
long t1 = System.nanoTime();
c = findClass(name);
//记录
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}三、破坏双亲委派模型
1.第一次破坏
双亲委派模型出现在JDK1.2之后，而类加载器和抽象类java.lang.ClassLoader已经存在。
因此为了向前兼容，JDK1.2之后在ClassLoader中添加了一个新的protected方法findClass。用户把自己的类加载逻辑写在findClass方法中，而不是重写loadClass方法，从而保证自定义的类加载符合双亲委派模型。
2.第二次破坏
模型自身有缺陷。双亲委派可以确保各个类加载器的基础类的统一，这是在用户代码调用基础类的情况下，如果出现基础类回调用户代码那就不适用了。比如涉及到SPI的场景去加载所需要的SPI代码。
SPI机制的介绍参考其他文章。
为了解决这个问题，引入了线程上下文加载器（Thread Context ClassLoader），这个类加载器就可以通过java.lang.Thread类中的setContextClassLoader()方法进行设置，如果创建线程时未设置将会从父线程中继承一个，如果全局都没有则默认就是应用程序类加载器，利用这个加载器可以完成父类加载器请求子类加载器加载的动作。
3.第三次破坏
由于对程序动态性追求导致，如热部署，热替换等。
比如模块化标准OSGi R4.2中将双亲委派的树形结构变成了更复杂的网状结构。
java文章教程推荐：java入门教程
