双亲委派机制
工作原理
- 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类加载器去执行；
- 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
- 如果父类的加载器可以完成类的加载任务，就成功返回。倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。
由于父类委托机制，当用户加载器需要加载某些类时，会把请求转给父类加载器，委托帮忙加载。首先最顶层的类加载器加载，加载不到就转交给子类加载器，如果最终到达加载器树的底层，还没有找到，就抛出异常ClassNotEoundException。
本质上是规定了类加载的顺序是：启动类加载器先加载，若加载不到，由扩展类加载器加载，若还加载不到，才会由系统类加载器或自定义的类加载器进行加载。
实现源码分析
双亲委派机制在java.lang.ClassLoader.loadClass(String,boolean)接口中体现。该接口的逻辑如下：
- 先在当前加载器的缓存中查找有无目标类，如果有，直接返回；
- 判断当前加载器的父加载器是否为空，如果不为空，则调用 parent.loadClass(name, false) 接口进行加载；
- 反之，如果当前加载器的父类加载器为空，则调用 findBootstrapClassOrNull(name) 接口，让引导类加载器进行加载；
- 如果通过以上3条路径都没能成功加载，则调用findClass(name)接口进行加载。该接口最终会调用 java.lang.ClassLoader 接口的 defineClass 系列的 native 接口加载目标Java类。
双亲委派的模型就隐藏在这第2和第3步中。
双亲委派机制优势
- 避免类的重复加载，确保一个类的全局唯一性（当父ClassLoader已经加载了该类的时候，就没有必要子ClassLoader再加载一次）
- 保护程序安全，防止核心API被随意篡改。
例，自定义类：java.lang.String、java.lang.SelfStart
双亲委派机制的弊端
检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。
破坏双亲委派机制举例
- 线程上下文类加载器(ClassLoader.getSystemClassLoader( ))
- 用户对程序动态性的追求。如:代码热替换(Hot Swap)、模块热部署(Hot Deployment)
小结
由于Java虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如在Tomcat中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是Servlet规范推荐的一种做法。
沙箱安全机制
Java安全模型的核心就是Java沙箱(sandbox)，什么是沙箱？
沙箱是一个限制程序运行的环境。沙箱机制就是将Java代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源访问，通过这样的措施来保证对代码的有效隔离，防止对本地系统造成破坏。沙箱主要限制系统资源访问，那系统资源包括什么？ CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
所有的Java程序运行都可以指定沙箱，可以定制安全策略。
在Java中将执行程序分成本地代码和远程代码两种，本地代码默认视为可信任的，而远程代码则被看作是不受信的。对于授信的本地代码，可以访问一本地资源。而对于非授信的远程代码在早期的Java实现中，安全依赖于沙箱(Sandbox)机制。