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