双亲委派底层运行过程
双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在 java.lang.ClassLoader的loadClass()方法之中，代码简单，逻辑清晰易懂:先检查类是否已经被加载过，若没有加载则调用父加载器的loadClass0方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass0)方法进行加载。
双亲委派模型主要是由ClassLoader#loadClass实现的，我们只需要自定义类加载器，并且重写其中的 loadClass方法，即可破坏双亲委派模型。
打破双亲委派机制有三种方法
本质上只有第一种算是真正的打破了双亲委派机制：
自定义类加载器并且重写loadClass方法。Tomcat通过这种方式实现应用之间类隔离，《面试篇》中分享它的做法。
线程上下文类加载器。利用上下文类加载器加载类，比如JDBC和JNDI等。
Osgi框架的类加载器。历史上Osgi框架实现了一套新的类加载器机制，允许同级之间委托进行类的加载，目前很少使用。
打破双亲委派的例子
向前兼容
由于双亲委派模型是在JDK1.2之后才被引入的，而类加载器和抽象类java.lang.ClassLoader则是JDK1.0时候就已经存在，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型时不得不做出一些妥协。
为了向前兼容，JDK1.2之后的java.lang.ClassLoader添加了一个新的proceted方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的就是重写loadClass(方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal()，而这个方法的唯一逻辑就是去调用自己的loadClass()。
JDK1.2之后已不再提倡用户再去覆盖loadClass0方法，应当把自己的类加载逻辑写到findClass(方法中，在 loadClass()方法的逻辑里，如果父类加载器加载失败，则会调用自己的findClass(方法来完成加载，这样就可以保证新写出来的类加载器是符合双亲委派模型的。
SPI实现
双亲委派模型很好地解决了各个类加载器的基础类统一问题(越基础的类由越上层的加载器进行加载)，基础类之所以被称为“基础”，是因为它们总是作为被调用的API。但是，如果基础类又要调用用户的代码，那该怎么办呢。
这并非是不可能的事情，一个典型的例子便是JNDI服务，它的代码由启动类加载器去加载(在JDK1.3时放进
rt.jar)，但JNDI的目的就是对资源进行集中管理和查找，它需要调用独立厂商实现部部署在应用程序的classpath下的JNDI接口提供者(SPI,Service Provider Interface)的代码，但启动类加载器不可能“认识”这些代码。
为了解决这个困境，Java设计团队只好引入了一个不太优雅的设计:线程上下文类加载器(Thread Context ClassLoader)。这个类加载器可以通过java.lang.Thread类的setContextClassLoader(方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个;如果在应用程序的全局范围内都没有设置过，那么这个类加载器默认就是应用程序类加载器。
有了线程上下文类加载器，JNDI服务使用这个线程上下文类加载器去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载动作，这种行为实际上就是打坡了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型，但这也是无可奈何的事情。
Java中所有涉及SPI的加载动作基本上都采用这种方式，例如JNDI,JDBC,JCE,JAXB和JBI等。
