双亲委派模式要求
要求除了顶层的启动类加载器外,其他类加载器必须有自己的父类加载器
这里的父子关系一般不以继承的关系来实现,都使用组合关系来复用父加载器的代码
工作过程
1.当一个类加载器收到了类加载的请求,它首先不会自己去尝试加载这个类
2.而是把这个请求委派给父类加载器去完成,每一层都是这样,所以加载请求最终都会传到顶层的启动类加载器中
3.只有当父类加载器无法完成加载(它的搜索范围内没有找到所需的类)时,才会交给子加载器去加载
优点
java类随着类加载器具备了带有优先级的层级关系
安全性,核心API中定义的类型不会被随意替换
例如java.lang.Object,它存放在rt.jar中,无论哪个类加载器加载该类,最终都是委派给了顶层的启动类加载器,从而保证Object类在程序的各种类加载器环境中都是同一个类,如果没有该模型限制,用户自己创建了一个java.lang.Object类,会导致程序出现多个Object,程序会变得混乱
实现原理
1.首先检查该类是否被加载过,若没有,则调用父类加载器的loadClass()
2.若父类加载器为空,则默认使用启动类加载器为父加载器
3.如果父类加载失败,则抛出ClassNotFundException异常,再调用自己的findClass()方法进行加载
破坏双亲委派模型
1.JDK1.2中开始引入双亲委派模型,为了兼容jdk1.0,在java.lang.ClassLoader中添加了一个protected方法findClass(),在此之前用户去继承ClassLoader会重写loadClass()方法,导致没有调用双亲委派模型的逻辑,后期虚拟机不建议用户再去覆盖loadClass()方法,而是把自己的类加载逻辑写到findClass()方法中
2.由于基础类又要调用回用户的代码的场景,典型的例子是JNDI服务
JNDI本身放在rt.jar中由启动类加载器加载,但是JNDI又会调用应用程序ClassPath中的代码,但启动类加载器不可能认识这些代码,所以引入一个设计:线程上下文类加载器,JNDI服务使用该加载器去加载所需要的代码,也就是父类加载器去请求子类加载器去完成类加载的动作,违反了双亲委派模型的层次结构来逆向使用类加载器
3.OSGi实现模块化热部署
在OSGi环境下,它自定义的类加载器机制的实现,不再是双亲委派模型的树状结构,而是更为复杂的网状
