历史上三次“打破”双亲委派机制

---

前言

双亲委派机制三次被打破，每一次都会有新的优化方式

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、第一次打破

第一次被打破是在Java的原始版本，那时候用户自定义类加载器已经存在，双亲委派机制为了兼容这些代码，但又无法保证loadClass不被子类重写，所以提供了findClass的方法。用户加载类的时候就去重写这个方法。如此一来，类加载的时候还是会调用加载器的loadClass向上请求，只有当父类加载器请求失败的时候，才会回来调用该类加载器被用户重写的findClass方法。

众所周知，双亲委派机制是通过调用类加载器的loadClass去实现的，一旦被重写，逻辑不符合双亲委派的逻辑，那么双亲委派机制就被打破了。

二、第二次打破

第二次打破则是由于JNDI服务（JDBC/JCE/JAXB/JBI），JNDI的目的就是对资源进行查找和集中管理，该类由启动类加载器去加载，但是却需要调用其他厂商部署在类路径下的JNDI服务提供者接口，由于父亲不认识儿子，启动类加载器是不认识这些接口的，那怎么办呢？

线程上下文类加载器：提供父类加载器访问子类加载器的行为。

这样一来就打通了父类到子类加载器的通道，如何去规范这种行为呢？

使用services配置信息，以责任链模式进行辅助。有兴趣的可以深入去了解一下具体信息。

三、第三次打破

第三次打破是热部署、热替换引起的。

Java热部署模块的规范化模块是OSGi提供的，热部署实现的关键就是OSGi自定义了类加载器，它为每个模块都配了一个类加载器。当需要动态地更换一个模块的时候，就把模块连通这个模块的类加载器一起替换，从而实现了热替换。

这种情况下，类加载器再也不是树状结构了，而是网状。

---

总结

就如《深入理解JVM》一书中的结尾所说，这里的打破双亲委派机制并不是一种贬义词，带有明确目的和充分理由的创新是被允许的。