双亲委派机制
双亲委派优势
- 避免类的重复加载，确保一个类的全局唯一性
- 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)，存在于不同域中的类文件就具有了当前域的全部权限
