什么网站做玩具的外贸,做网站小图标大全,西安网站建设现状,做网站的公司成本双亲委派机制 双亲委派优势
避免类的重复加载#xff0c;确保一个类的全局唯一性
Java类随着它的类加载器一起具备了一种带有优先级的层次关系#xff0c;通过这种层次关系可以避免类的重复加载#xff0c;当父类已经加载了该类#xff0c;就没有必要子ClassLoader再加载…双亲委派机制 双亲委派优势
避免类的重复加载确保一个类的全局唯一性
Java类随着它的类加载器一起具备了一种带有优先级的层次关系通过这种层次关系可以避免类的重复加载当父类已经加载了该类就没有必要子ClassLoader再加载一次
保护程序安全防止核心API被随意篡改
代码支持
双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现
①先在当前加载器的缓存中查找有无目标类如果有直接返回②判断当前类加载器的父类加载器是否为空如果不为空调用parent.loadClass(name,false)接口进行加载③反之如果当前加载器的父类加载器为空则调用findBootstrapClassOrNull(name)接口让引导类加载器进行加载④如果以上3条都没成功则调用findClass(name)接口进行加载该接口最终会调用java.lang.ClassLoader类的defineClass系列native方法加载目标Java类双亲委派模型隐藏在第2和3步中
思考
如果在自定义的类加载器中重写java.lang.ClassLoader.loadClass(String)或java.lang.ClassLoader.loadClass(String,boolean)方法抹去双亲委派机制仅保留上面第1和4步那是否就可以使用自定义类加载器加载核心类库不行因为JDK还为核心类库提供了一层保护机制不管是自定义类加载器还是系统类加载器或扩展类加载器最终都必须调用java.lang.ClassLoader.defineClass(String,byte[],int,int,ProtectionDomain)方法此方法会执行preDefineClass()方法该方法提供了对JDK核心类库的保护
双亲委派模式的弊端
检查类是否加载的委托过程是单向的虽然结构上清晰使各个ClassLoader的职责非常明确但会带来一个问题即顶层的ClassLoader无法访问底层ClassLoader所加载的类通常情况下启动类加载器的类为系统核心类包括一些重要的系统方法而在应用类加载器中为应用类按照这种模式应用类访问系统类没有问题但系统类访问应用类就会出现问题如在系统类中提供一个接口该接口需要在应用类中实现该接口还绑定一个工厂方法用于创建该接口的实例而接口与工厂方法在启动类加载器中此时会出现工厂方法无法创建由应用类加载器加载的应用实例的问题
结论
由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型只是建议采用在Tomcat中类加载器采用的加载机制和传统双亲委派模型有一定区别当缺省的类加载器接收到一个类加载任务时首先由它自行加载当加载失败才会将类的加载任务委派给它的超类加载器去执行这同时也是Servlet规范推荐的一种做法
沙箱安全机制
保证程序安全保证Java原生的JDK代码沙箱是一个限制程序运行的环境沙箱机制是将Java代码限定在虚拟机(JVM)特定的运行范围中并且严格限制代码对本地系统资源访问通过这样的措施来保证对代码的有限隔离防止对本地系统造成破坏沙箱主要限制系统资源访问CPU内存文件系统网络所有的Java程序都可以指定沙箱可以定制安全策略 JDK1.0时期: JDK1.1时期针对安全机制做了改进增加了安全策略允许用户指定代码对本地资源的访问权限 JDK1.2时期 JDK1.6时期
当前最新的安全机制实现引入域的概念虚拟机会把所有代码加载到不同的系统域和应用域系统域部分专门负责与关键资源进行交互而各个应用域部分则通过系统域的部分代理来对各种需要的资源进行访问。虚拟机不同的受保护域(Protected Domain)对应不一样的权限(Permission)存在于不同域中的类文件就具有了当前域的全部权限
