文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
双亲委派机制
双亲委派类加载过程
当
App
尝试加载一个类时,它不会直接尝试加载这个类,首先会在自己的命名空间中查询是否已经加载过这个类,如果没有会先将这个类加载请求委派给父类加载器Ext
完成。当
Ext
尝试加载一个类时,它也不会直接尝试加载这个类,也会在自己的命名空间中查询是否已经加载过这个类,没有的话也会先将这个类加载请求委派给父类加载器Bootstrap
完成。如果
Bootstrap
加载失败,这个需要被加载的类不在Bootstrap
的加载范围内,那么Bootstrap
会重新将这个类加载请求交由子类加载器Ext
完成。如果
Ext
加载失败,这个类也不在Ext
的加载范围内,最后会重新将这个类加载请求交给子类加载器App
完成。如果
App
加载器也加载失败这个类根据全限定名无法查找到,则会抛出ClassNotFoundException
异常。
此处的父子关系并非继承关系,而是采用组合关系来实现
双亲委派机制的优势
可以避免一个类在不同层级的类加载器中重复加载,如果父类加载器已经加载过该类了,那么就不需要子类加载器再加载一次。
沙箱安全机制:
可以保障Java核心类的安全性问题,比如通过网络传输过来一个
java.lang.String
类,需要被加载时,通过这种双亲委派的方式,最终找到Bootstrap
加载器后,发现该类已经被加载,从而就不会再加载传输过来的java.lang.String
类,而是直接返回Bootstrap
加载的String.class
。这样可以有效防止Java的核心API类在运行时被篡改,从而保证所有子类共享同一基础类,减少性能开销和安全隐患问题。
双亲委派的实现原理
所有的类加载器都间接的继承自
ClassLoader
类,包括Ext、App
类加载器(Bootstrap
除外,因为它是C++实现的)。双亲委派模型的实现逻辑全在于
loadClass()
方法,而ExtClassLoader
加载器是没有重写loadClass()
方法,AppClassLoader
加载器虽然重写了loadClass()
方法,但其内部最终还是调用父类的loadClass()
方法。无论是
ExtClassLoader
还是AppClassLoader
加载器,其本身都未打破ClassLoader.loadClass()
方法中定义的双亲委派逻辑,Bootstrap、Ext、App
这些JVM自带的类加载器都默认会遵守双亲委派模型。
// sun.misc.Launcher类 → AppClassLoader内部类 → loadClass()方法public Class loadClass(String name, boolean resolve)throws ClassNotFoundException{int i = name.lastIndexOf('.');if (i != -1) {SecurityManager sm = System.getSecurityManager();if (sm != null) {sm.checkPackageAccess(name.substring(0, i));}}// 依旧调用的是父类loadClass()方法return (super.loadClass(name, resolve));}
打破双亲委派机制
需要重写loadClass方法,在
loadClass
方法中不委托给父类尝试着进行加载,直接在当前的类加载器进行加载。打破双亲委派机制的场景:
- 一个Tomcat可能部署多个应用,不同的应用可能依赖的同一个第三方类库的不同版本(会造成很多大量的文件路径相同的类),这种情况下就不能通过双亲委派机制去加载,要保证每个应用的类库是独立的,相互隔离。