要了解双亲委派机制得先了解个概念：
类加载器：“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块成为“类加载器”。
通俗的讲，虚拟机是根据类的全限定名来加载类的，那么有个问题，如果同时存在两个或多个全限定名完全一致的情况下。该如何选择加载哪个类。这就是双亲委派机制要做的工作。
在这里强加个知识点：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有真正的意义，否则，即使这两个类来源于同一个class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那这两个类就必定不相等。
回到双亲委派的问题上，接下来了解下类加载器的种类：
1-启动类加载器，负责加载%JAVA_HOME%in目录下的所有jar包，或者是-Xbootclasspath参数指定的路径；
2-扩展类加载器：负责加载%JAVA_HOME%inext目录下的所有jar包，或者是java.ext.dirs参数指定的路径；
3-应用程序类加载器：负责加载用户类路径上所指定的类库，如果应用程序中没有自定义加载器，那么次加载器就为默认加载器。
加载器之间的层次关系：
双亲委派机制得工作过程：
1-类加载器收到类加载的请求；
2-把这个请求委托给父加载器去完成，一直向上委托，直到启动类加载器；
3-启动器加载器检查能不能加载（使用findClass()方法），能就加载（结束）；否则，抛出异常，通知子加载器进行加载。
4-重复步骤三；
以上就是双亲委派机制的原理。
接下来举个例子：
大家所熟知的Object类，直接告诉大家，Object默认情况下是启动类加载器进行加载的。假设我也自定义一个Object，并且制定加载器为自定义加载器。现在你会发现自定义的Object可以正常编译，但是永远无法被加载运行。
这是因为申请自定义Object加载时，总是启动类加载器，而不是自定义加载器，也不会是其他的加载器。
人和事物都有缺陷，双亲委派机制也不例外，三次得到破坏：
1-jdk1.2之间，用户直接去调用loadClass()方法；不能保证双亲委派机制的基本规则。后改成findClass()方法。
2-双亲委派机制的自我缺陷，使用了线程上下文类加载器。这种行为打破了双亲委派机制模型的层次关系来逆向使用类加载器，实际上违背了双亲委派机制的一般性原则。
3-用户对程序动态性的追求而导致的。例如鼠标，键盘灯热部署。
参考文献：深入JVM虚拟机 周志明