什么是双亲委派模型？违背双亲委派模型？
一、先从类加载器讲起
对于任意一个类，被同一个类加载器加载后都是唯一的，但如果被不同加载器加载后，就不是唯一的了。即使是源于同一个Class文件、被同一个JVM加载，只要加载类的加载器不同，那么类就不同。
下面我们写一个不同类加载器加载后的类，看一下对instanceof关键字运算有什么影响：
public class OneMoreStudy {
public static void main(String[] args) throws Exception {
ClassLoader myLoader = new ClassLoader() {
@Override
public Class loadClass(String name) throws ClassNotFoundException {
try {
String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";
InputStream inputStream = getClass().getResourceAsStream(fileName);
if (inputStream == null) {
return super.loadClass(name);
}
byte[] array = new byte[inputStream.available()];
inputStream.read(array);
return defineClass(name, array, 0, array.length);
} catch (IOException e) {
throw new ClassNotFoundException(name);
}
}
};
Object object = myLoader.loadClass("OneMoreStudy").newInstance();
System.out.println("class name: " + object.getClass().getName());
System.out.println("instanceof: " + (object instanceof OneMoreStudy));
}
}运行的结果：
class name: OneMoreStudy
instanceof: false 在运行结果中，第一行可以看出这个对象确实是OneMoreStudy类实例化出来的，但在第二行中instanceof运算结果是false，说明在JVM中存在两个OneMoreStudy类，一个是由系统应用程序类加载器加载的，另一个是由我们自定义的类加载器加载的。虽然都是来自同一个Class文件，在同一个JVM里，但是被不同的类加载器加载后，仍然是两个独立的类。
二、类加载器的划分
接下来我们理解一个类加载器的划分，除了像上面例子代码中，我们自己实现的自定义类加载器，还有3种系统提供的类加载器：
1、启动类加载器（Bootstrap ClassLoader）：它负责将存放在%JAVA_HOME%\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是JVM识别的类库加载到JVM内存中。它仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载。它是由C++语言实现的，无法被Java程序直接引用。
2、扩展类加载器（Extension ClassLoader）：它负责加载%JAVA_HOME%\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。它由sun.misc.Launcher.ExtClassLoader实现，开发者可以直接使用扩展类加载器。
3、应用程序类加载器（Application ClassLoader）：它负责加载用户类路径（ClassPath）上所指定的类库。由于它是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它由sun.misc.Launcher.AppClassLoader来实现，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
下图就是类加载器的划分与关系图：
三、什么是双亲委派模型？
任何一个类都需要由加载它的“类加载器”和这个类本身一同确立其在JVM中的唯一性。但类的加载器有很多，为了确保这个类在JVM中的唯一性，这时候就要用到双亲委派模型（Parents Delegation Model）了，双亲委派模型要求除顶层启动类加载器外其余类加载器都应该有自己的父类加载器；类加载器之间的父子关系，一般不会以继承的关系来实现，而是都使用组合关系来复用父类加载器。
简单介绍他的请求处理流程：
1、首先应用程序类加载器（Application ClassLoader）会收到一个类加载请求，他首先不会自己去尝试加载这个类，而是将这个请求委派给父类加载器扩展类加载器（Extension ClassLoader）去尝试加载。
2、当扩展类加载器（Extension ClassLoader）收到一个类加载请求时，他首先也不会自己去尝试加载这个类，而是将请求委派给父类加载器Bootstrap ClassLoader去完成。
3、如果启动类加载器（Bootstrap ClassLoader）加载失败，也就是在
4、如果扩展类加载器（Extension ClassLoader）也加载失败，就会使用应用程序类加载器（Application ClassLoader）加载。
5.如果应用程序类加载器（Application ClassLoader）也加载失败，就会使用自定义加载器去尝试加载。
6.如果均加载失败，就会抛出ClassNotFoundException异常。
简单的来说就是类加载器收到类加载的请求后，它不会首先自己去尝试加载这个类，而是把这个请求委派给父类加载器去尝试加载。每一个类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中。只有当父类加载器反馈自己无法完成这个加载请求时，子加载器才会尝试自己去加载。这样就保证了类在JVM中的唯一性，也保证了Java程序稳定运作。
四、双亲委派模型具体是如何实现的？
首先会检查请求加载的类是否已经被加载过 ---> 如果没有被加载过就会递归调用父类加载器的loadClass() ---> 父类加载器为空后就使用启动类加载器加载 ---> 如果父类加载器和启动类加载器均无法加载请求，就调用自身的加载功能。
实现双亲委派模型的代码都集中在java.lang.ClassLoader的loadClass()方法，代码如下：
protected Class loadClass(String name, boolean resolve)
throws ClassNotFoundException
{
synchronized (getClassLoadingLock(name)) {
// First, check if the class has already been loaded
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 thrown if class not found
// from the non-null parent class loader
}
if (c == null) {
// If still not found, then invoke findClass in order
// to find the class.
long t1 = System.nanoTime();
c = findClass(name);
// this is the defining class loader; record the stats
sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
sun.misc.PerfCounter.getFindClasses().increment();
}
}
if (resolve) {
resolveClass(c);
}
return c;
}
}五、破坏双亲委派模型
双亲委派模型并不是一个强制性的约束模型，而是Java设计者们推荐给开发者们的类加载器实现方式。大部分的类加载器都遵循这个模型，但也有例外的情况，比如下面这三种情况：
1、重写ClassLoader的loadClass()方法
在上面例子代码中，就是重写了ClassLoader的loadClass()方法，破坏了双亲委派模型，产生了不唯一的类。所以，不提倡开发人员覆盖loadClass()方法，而应当把自己的类加载逻辑写到findClass()方法中，在loadClass()方法的逻辑里如果父类加载失败，则会调用自己的findClass()方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型。
2、SPI（Service Provider Interface，服务提供者接口）
Java提供了很多SPI，允许第三方为这些接口提供实现，常见的SPI有JDBC、JNDI、JCE、JAXB和JBI等。
SPI的接口由Java核心库来提供，而这些SPI的实现代码则是作为Java应用所依赖的jar包被包含进类路径（ClassPath）里。SPI接口中的代码经常需要加载具体的实现类。那么问题来了，SPI的接口是Java核心库的一部分，是由启动类加载器来加载的；SPI的实现类是由系统类加载器来加载的。引导类加载器是无法找到SPI的实现类的，因为依照双亲委派模型，启动类加载器无法委派系统类加载器来加载类。
这时候就会使用线程上下文类加载器（Thread Context ClassLoader），在JVM中会把当前线程的类加载器加载不到的类交给线程上下文类加载器来加载，直接使用Thread.currentThread().getContextClassLoader()来获得，默认返回的就是应用程序类加载器，也可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。
而线程上下文类加载器破坏了双亲委派模型，也就是父类加载器请求子类加载器去完成类加载的动作，但为了实现功能，这也是一种巧妙的实现方式。
3、OSGi（Open Service Gateway Initiative，开放服务网关协议）
OSGi技术是面向Java动态化模块化系统模型，程序模块（称为Bundle）无需重新引导可以被远程安装、启动、升级和卸载。实现程序模块热部署的关键则是它自定义的类加载器机制的实现。
在OSGi中，类加载器不再是双亲委派模型中的树状结构，而是一个较为复杂的网状结构，类加载的规则简要介绍如下：
-
若类属于java.*包，则将加载请求委托给父加载器
-
若类定义在启动委托列表（org.osgi.framework.bootdelegation）中，则将加载请求委托给父加载器
-
若类属于在Import-Package中定义的包，则框架通过ClassLoader依赖关系图找到导出此包的Bundle的ClassLoader，并将加载请求委托给此ClassLoader
-
若类资源属于在Require-Bundle中定义的Bundle，则框架通过ClassLoader依赖关系图找到此Bundle的ClassLoader，将加载请求委托给此ClassLoader
-
Bundle搜索自己的类资源( 包括Bundle-Classpath里面定义的类路径和属于Bundle的Fragment的类资源）
-
若类在DynamicImport-Package中定义，则开始尝试在运行环境中寻找符合条件的Bundle
如果在经过上面一系列步骤后，仍然没有正确地加载到类资源，则会向外抛出类未发现异常。
总结
类加载器通过一个类的全限定名来转换为描述这个类的二进制字节流，可划分为启动类加载器、扩展类加载器、加载器应用程序类加载器、自定义类加载器。在双亲委托模型中，将上述各种类加载器组成一系列的父子关系，子类加载器先把类加载请求委派给父类加载器去尝试加载，父类加载器无法加载时子类加载器才自己尝试加载，这样保证了类在JVM中的唯一性。不过，也不遵循双亲委托模型的情况，比如：重写ClassLoader的loadClass()方法、SPI（服务提供者接口）、OSGi（开放服务网关协议）。
参考来源：万猫学社