三次被破坏的java双亲委派机制

破坏双亲委派机制

第一次

因为双亲委派机制是在jdk1.2提出来的，但是类加载器的概念和抽象类java.lang.ClassLoader则是在java的第一个版本就已经经存在了，面对已经存在的用户自定义的类加载器的代码。
为什么不直接对loadClass进行final修饰，禁止用户重写该方法呢？因为java是向下兼容的，java设计者在引入双亲委派机制的时候没有办法只好做出妥协，为了兼容这些已有的代码，无法再以技术手段避免loadClass()被子类覆盖的可能性，只能在JDK1.2之后的java.lang.ClassLoader中添加了一个新的protected方法findClass()，引导用户编写的类加载逻辑时尽可能去重写该方法，而不是在loadClass中编写代码。

第二次

根据代码测试知道JDBC的DriverManager的加载器是启动类加载器，但是具体的实现类是交给各大公司去实现的（mysql，oracl等）,需要调用由其他厂商实现并部署在应用程序的ClassPath下的JDBC服务提供者接口（Service Provider Interface - SPI）的代码，现在问题来了，启动类加载器绝不可能认识，记载这些代码的，怎么办？引入了一个不太优雅的做法：线程上下文类加载器，有了这个加载器，程序就可以做一些“舞弊”的事情了，JDBC服务器使用这个加载器去加载所需的SPI服务代码，这是一种父类加载器去请求子类加载器完成类加载的行为。这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器的，已经违背了双亲委派模型的一般性原则。在JDK6中，提供了java.util.ServiceLoader类，才算是给SPI找到了一个比较合理的解决方案。

第三次

由于用户对程序动态性的追求而导致的：代码热替换，模块热部署等。